What is DMARC? The Email Authentication Record Explained

DMARC is a DNS TXT record that tells receiving mail servers what to do when an email fails SPF or DKIM checks. It is not a deliverability fix. It is a policy instruction. If you send cold email at volume, you need to understand what DMARC actually does, how receivers interpret it, and what happens when you set it wrong.

What DMARC Actually Does

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS record published at _dmarc.yourdomain.com that answers one question: what should a receiving server do if an email claiming to be from your domain fails authentication?

DMARC does not authenticate mail itself. It relies on two existing mechanisms: SPF (which checks the sending IP) and DKIM (which checks a cryptographic signature). DMARC adds alignment, a rule that the domain in the From header must match the domain that passed SPF or DKIM. If neither aligns, DMARC fails.

The policy you set in your DMARC record tells Gmail, Outlook, Yahoo, and other receivers whether to deliver the message anyway (p=none), quarantine it (p=quarantine), or reject it outright (p=reject).

For cold email senders, DMARC is table stakes. As of February 2024, Gmail and Yahoo require a DMARC record for any domain sending bulk mail. If you send from a domain with no DMARC record, you will land in spam or get blocked entirely. This is covered in detail in our 2026 deliverability guide.

Anatomy of a DMARC Record

A DMARC record is a single-line TXT record. Here is a real example:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r;

Each tag means something specific:

• v=DMARC1: version identifier, always DMARC1.
• p=quarantine: policy for messages that fail. Options are none, quarantine, or reject.
• rua=mailto:[email protected]: where to send aggregate reports (daily XML summaries of authentication results).
• ruf=mailto:[email protected]: where to send forensic reports (individual failure samples). Most receivers do not send these.
• pct=100: percentage of failing mail to apply the policy to. 100 means all of it. You can set this lower during testing.
• adkim=r: DKIM alignment mode. r is relaxed (subdomains allowed), s is strict (exact match only).
• aspf=r: SPF alignment mode, same logic.

The only required tags are v and p. Everything else is optional. A minimal valid record is v=DMARC1; p=none;.

Alignment: The Part That Trips People Up

DMARC passes only if the domain in the From header aligns with the domain that passed SPF or DKIM. This is the part that breaks most cold email setups.

SPF alignment checks the Return-Path domain (also called the envelope sender or MAIL FROM). If you send from [email protected] but your ESP sets the Return-Path to [email protected], SPF alignment fails even if SPF itself passes.

DKIM alignment checks the d= domain in the DKIM signature. If your ESP signs with d=esp.com but your From address is [email protected], DKIM alignment fails.

Relaxed alignment (adkim=r and aspf=r) allows subdomains. If your From domain is mail.yourdomain.com and your DKIM signature is d=yourdomain.com, relaxed alignment passes. Strict alignment requires an exact match.

Most cold email platforms handle this by letting you set a custom Return-Path and providing a DKIM key you publish in your DNS. If you do not configure both, DMARC will fail. For step-by-step DKIM setup, see our DKIM configuration guide.

Policy Levels and What They Mean for Sending

p=none is monitor mode. Receivers check DMARC but do nothing if it fails. You still get aggregate reports. This is the safest starting point. It will not hurt deliverability, but it also will not protect your domain from spoofing.

p=quarantine tells receivers to treat failing mail as suspicious. In practice, this means spam folder. Some receivers are more aggressive than others. Outlook tends to quarantine hard. Gmail sometimes delivers anyway if other signals are strong.

p=reject tells receivers to bounce the message entirely. No delivery, no spam folder. This is the strongest protection against spoofing, but it will also reject legitimate mail if your authentication is misconfigured.

For cold email, p=none is the standard recommendation. It satisfies the Gmail and Yahoo requirement without risking false positives. If you send from multiple subdomains or use a third-party ESP, p=quarantine or p=reject can break legitimate sends if alignment is not perfect.

You can set a subdomain policy with sp=. For example, p=reject; sp=none; rejects failing mail from your root domain but monitors subdomains. This is useful if you send marketing from mail.yourdomain.com but want strict protection on your root domain.

Aggregate Reports: What You Actually Get

If you set rua=mailto:[email protected], receivers will send you daily XML files summarizing authentication results. These reports tell you:

• Which IPs sent mail claiming to be from your domain.
• How many messages passed or failed SPF, DKIM, and DMARC.
• What policy the receiver applied (none, quarantine, reject).
• Which receiver sent the report (Google, Microsoft, Yahoo, etc.).

The reports are verbose and hard to read raw. Most people use a DMARC report parser like Postmark, Dmarcian, or Valimail. These tools turn the XML into a dashboard showing pass rates, sources, and failures.

Aggregate reports are useful for two things: spotting unauthorized senders using your domain, and debugging authentication failures. If you see a spike in DMARC failures from a legitimate source, you know something is misconfigured.

Forensic reports (ruf=) are supposed to send individual samples of failing messages, but most receivers do not send them due to privacy concerns. Do not rely on forensic reports for debugging.

Common DMARC Failures and How to Fix Them

Failure: SPF passes but alignment fails. This happens when your Return-Path domain does not match your From domain. Fix: configure a custom Return-Path at your ESP or sending platform. Most platforms let you set this in DNS with a CNAME or MX record.

Failure: DKIM passes but alignment fails. Your ESP is signing with their own domain instead of yours. Fix: generate a DKIM key for your domain and publish the public key in your DNS. Your ESP should provide instructions for this.

Failure: both SPF and DKIM fail. Either your DNS records are missing, or the sending IP is not authorized. Fix: verify your SPF record includes the sending IP or ESP, and verify your DKIM selector is published correctly.

Failure: forwarded mail fails DMARC. When someone forwards your email, the From address stays the same but the sending IP changes. SPF fails because the forwarding server is not in your SPF record. DKIM usually survives forwarding if the forwarder does not modify the message. There is no perfect fix for this. Some senders use p=none to avoid breaking forwarded mail.

Failure: subdomain has no DMARC record. If you send from mail.yourdomain.com and only have a DMARC record at _dmarc.yourdomain.com, receivers will use the root domain policy. If you want different policies for subdomains, publish a separate DMARC record at _dmarc.mail.yourdomain.com.

DMARC for High-Volume Cold Email

If you send cold email at scale, DMARC is not optional. Gmail and Yahoo will reject or spam mail from domains without a DMARC record. But DMARC alone does not fix deliverability. It is a policy, not a reputation signal.

The real work is in the authentication stack underneath: SPF records that include all your sending IPs, DKIM keys that align with your From domain, and a Return-Path that matches. If any of these are misconfigured, DMARC will fail and your mail will not land.

Most cold email platforms handle this for you, but you still need to publish the DNS records they provide. If you use multiple sending domains or rotate mailboxes, you need a DMARC record for each domain. If you use subdomains for different campaigns, decide whether you want a subdomain policy or separate records.

For a full breakdown of how SPF, DKIM, and DMARC work together in 2026, see our complete authentication guide.

How SpamCipher Handles DMARC

SpamCipher is built for unlimited cold email sending at high volume. DMARC is part of the owned deliverability pipeline that makes the 90%+ inbox placement promise work.

When you connect a sending domain to SpamCipher, the platform generates the SPF, DKIM, and DMARC records you need and walks you through publishing them. If you bring your own infrastructure, SpamCipher verifies that your authentication is configured correctly before you send. If you use the done-for-you option, SpamCipher provisions and manages the DNS records for you.

Every mailbox in the SpamCipher rotation is warmed on a real seed network with proper DMARC alignment before it sends a single cold email. The platform monitors DMARC pass rates in real time and flags misconfigurations before they hurt deliverability.

Because sending, warm-up, verification, and inbox placement all run on the same pipeline, you do not need to stitch together separate tools for authentication. DMARC is one piece of a system that handles the entire send flow, from DNS to inbox.

Frequently asked questions