How a receiver evaluates DMARC

DMARC evaluation is a short, fixed sequence. Knowing it in order lets you say precisely where a given message stopped, which is most of what diagnosing a DMARC problem consists of.

The sequence

1. Extract the domain from the From: header.
   No usable From domain, or more than one From address?  -> fail

2. Look up the DMARC record at _dmarc.<that domain>.
   None found?  -> try the organisational domain
   Still none?  -> DMARC does not apply. Stop.

3. Run SPF. Did it pass, AND is the envelope domain aligned
   with the From domain?

4. Run DKIM. Is there any valid signature whose d= is aligned
   with the From domain?

5. If either 3 or 4 is true  -> DMARC pass. Stop.
   Otherwise                 -> DMARC fail. Apply p= (or sp=).

One aligned pass is enough

This is why deploying both protocols is worth the effort even though they overlap. They fail in different circumstances — SPF does not survive forwarding, DKIM does not survive body modification — so a message that breaks one frequently still has the other. A domain with only one working protocol has no margin.

The word doing the work is "aligned"

Steps 3 and 4 both say "and is aligned". Strip that word out and DMARC becomes useless: any SPF pass for any domain would satisfy it, which is exactly the attack the previous lesson described. Alignment is the whole mechanism, and it is the subject of the next module.

Where the policy is looked up

Step 2 has a fallback that matters for subdomains. For a message from invoices.example.com:

• The receiver looks for _dmarc.invoices.example.com.
• If there is none, it finds the organisational domain — example.com — and looks for _dmarc.example.com.
• If that record has an sp= tag, that is the policy applied. Otherwise p= is.

So a single record at the organisational domain covers every subdomain that does not have its own. That is a considerable convenience and it is also why sp= deserves an explicit value rather than being left to inherit.

What a receiver actually does

A DMARC policy is a request. RFC 7489 §6.7 is clear that receivers may deviate, and they do — a receiver may deliver a message that failed p=reject because other signals strongly indicate it is wanted, or quarantine one that passed.

In practice the large mailbox providers honour p=reject closely, because a domain owner asking for their own mail to be rejected is a strong and unusual signal. But the gap between policy and disposition is real, and aggregate reports record both — which is how you find out.