CertaDNS
Skip to lesson

Diagnosing Failures · lesson 1 of 3

Four causes, one method

After this lesson you can

Take a failing message to one of four causes using only its headers.

Assumes you have read The two queries.

Every DMARC failure is one of four things. The headers of a single failing message separate them in about a minute, and the method is the same whether the message is yours or an attacker’s.

The four

CauseSignature in the headers
Not your mailSource IP unrelated to any system of yours; both mechanisms fail outright.
Your mail, nothing alignedSPF passes for a vendor domain, or DKIM passes with a vendor d=. Both results are pass; neither is your domain.
Your mail, alignment broken in transitOne mechanism passed at origin and failed here — typically SPF at a forwarder.
Your mail, genuinely misconfiguredA missing key, a selector that does not resolve, an SPF record that does not list the sender.

The method

1. Read Authentication-Results.
   Note every header.d and every smtp.mailfrom.
   Which domains actually passed?

2. Compare each to the From domain.
   Any of them yours, under relaxed alignment?
     none  -> cause 2 (nothing aligned) or cause 1
     one   -> DMARC should have passed; re-read for a second
              Authentication-Results from an earlier hop

3. Is the source IP one of yours or a vendor's?
   no   -> cause 1. Nothing to fix; this is the policy working.
   yes  -> continue

4. Did the message pass at an earlier hop?
   Look for an earlier Authentication-Results or an ARC chain.
   passed earlier, failing now -> cause 3
   never passed                -> cause 4

A worked case

From: billing@example.com
Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=bounce.vendor.example;
   dkim=pass header.d=vendor.example header.s=v1;
   dmarc=fail header.from=example.com

Both mechanisms passed, and neither passed for example.com. This is cause 2, and it is the most common shape in any estate with third-party senders. The fix is on the vendor’s side — a custom return-path, customer-domain DKIM, or both — and no change to your SPF or DMARC record affects it.

Cause 1 is a result, not a problem

A failure from infrastructure with no relationship to you is the policy doing its job. Chasing it is how time gets spent on spoofing volume nobody can influence, while a real alignment problem in cause 2 sits unfixed.

Try it on a real domain

Free, no account, public DNS only.

Last reviewed