What DMARC actually does

SPF and DKIM each authenticate something your recipient never sees. SPF checks the envelope sender, which is usually a bounce address at your provider's domain. DKIM checks a signing domain declared in the signature header. Neither says anything about the From address displayed in the mail client, which is the only identity a human actually reads.

DMARC is the layer that connects them. It does three things: it requires one of those authenticated identities to match the visible From domain, it states what receivers should do when none does, and it asks receivers to report back on what they saw.

The pass condition

A message passes DMARC when at least one of these is true:

• SPF passed, and the envelope sender domain aligns with the From domain.
• DKIM passed, and the signing domain in d= aligns with the From domain.

One is enough, and that redundancy is deliberate rather than sloppy. It is what lets legitimate forwarded mail survive: forwarding breaks SPF, because the forwarding server relays from an IP your record never listed, but the DKIM signature travels with the message and still verifies. A domain that relies on SPF alone will lose forwarded mail the moment it reaches enforcement.

The word doing the work in both lines is aligns. Authentication alone is not enough, and alignment is the idea worth understanding properly, because it is where most domains get stuck.

The three policies

• p=none takes no action. Monitoring only, but reports still flow, which is the entire reason to publish it.
• p=quarantine tells receivers to treat failing mail as suspicious. In practice that means the spam folder.
• p=reject tells receivers to refuse failing mail during the SMTP transaction. The recipient never sees it, and there is no spam folder copy to rescue.

These are requests, not commands. A receiver is free to ignore your policy, and some apply their own judgement on top. In practice the major mailbox providers honour reject, which is what makes it worth reaching.

The record

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

It lives at _dmarc on the domain, as a TXT record. v and p must come first, in that order. Everything else is optional, though rua should be treated as mandatory in practice. Every tag and what it does covers the rest.

The reports are the point

Aggregate reports, requested with rua, arrive as gzipped XML, typically once a day from each reporting receiver. Each one summarises how much mail that receiver saw claiming to be from your domain, from which IP addresses, and how it authenticated.

This is the part people skip and should not. Before you publish DMARC you are guessing about who sends mail as your domain. After a month of reports you know, including the systems nobody on the mail team remembered: the invoicing platform, the recruitment tool, the monitoring service that emails alerts. That inventory is what makes enforcement safe, and it is why the move from none to reject is a staged rollout driven by data rather than a flag you flip.

Publishing p=none changes nothing about delivery. There is no risk in it, and no reason to wait.

Where receivers look for the policy

A receiver takes the domain from the From header and queries _dmarc on it. If there is no record there, it falls back to the organisational domain, found using the public suffix list, and uses that record instead. This is why a policy on example.com governs marketing.example.com without you publishing anything on the subdomain, and why an attacker cannot evade your policy by inventing a subdomain that does not exist.

It also means the parent record is doing more work than it looks. Tightening example.com tightens every subdomain that lacks its own record, at the same moment. If a subdomain is behind in its rollout, it needs either its own record or an explicit sp value first.

DMARC is not a deliverability feature

A persistent myth says publishing DMARC improves inbox placement. It does not, at least not directly. Authentication is a prerequisite for being trusted, not a reputation boost: passing DMARC does not make a receiver want your mail, it just stops that receiver discounting it as unauthenticated.

What enforcement does buy you is control over your domain's use by others, and the reporting data to see it. Some large mailbox providers now require authentication for bulk senders, which makes DMARC a condition of delivery rather than an enhancement to it. Those are both good reasons to publish. Expecting spam-folder placement to improve on its own is not.

What DMARC does not protect against

DMARC defends the exact domain in the From header. It does nothing about the attacks that surround it:

• Look-alike domains. examp1e.com is a different domain, and your DMARC record has no authority over it.
• Display-name spoofing. A message from attacker@gmail.com with the display name set to your CEO passes DMARC for gmail.com, entirely legitimately.
• Subdomains you have not considered, unless your policy covers them. It does by default, which is worth knowing in both directions.
• Compromised accounts. Mail genuinely sent through your own platform by someone who stole a password authenticates perfectly.

Where to start

Check what a domain publishes today with the DMARC tool. If the answer is nothing, publishing your first record is a ten-minute job that breaks nothing and starts the data flowing.