Header analyser: what went wrong, and whose problem it is

Paste the raw headers of a message. You get the issues ranked, each one marked as yours to fix, the receiver's, or something an intermediary did in transit, plus the DMARC arithmetic a receiver actually ran to reach its verdict.

What it finds that other analysers do not

Whose problem each finding is

Every finding is marked yours, in transit or receiver side. This matters more than it sounds: the single most common way to waste a day on a delivery problem is to go and change SPF because a message that was forwarded failed it, which is what forwarding does to every message and always has.

The DMARC arithmetic, shown as arithmetic

Which domain authenticated, which domain is in the From: header, which alignment mode applies, and therefore what a receiver would do at p=none, p=quarantine and p=reject. A valid DKIM signature by the wrong domain fails DMARC, and seeing the two domains side by side is usually the moment that lands.

Signature tags nobody checks

Every DKIM checker on the market reads the DNS record at the selector. But l=, x=, a= and h= are tags on the DKIM-Signature header, not on the record, so a record checker structurally cannot see them. This reads them:

• A body-length limit (l=) means only the first N bytes are signed. Anything can be appended below that point and the signature still verifies, so a DKIM pass stops meaning the message is intact. RFC 6376 has a section titled "Misuse of Body Length Limits".
• An expired signature (x= in the past), or one whose validity window is shorter than a normal retry schedule, so a deferred message arrives unverifiable.
• SHA-1 signing, which several receivers now treat as no signature.
• A signed-header list that omits From:, which RFC 6376 forbids, or omits Subject:, which lets it be rewritten in transit without breaking the signature.

Which Authentication-Results header you can believe

None of them, by default. They are plain text, and anything upstream of your own mail server can write one, including the sender. Only the header your own inbound gateway added means anything, and a pasted block carries no proof of which that is. Name your gateway above and it gets marked; anything below it is shown as a claim. If a header carrying your own authserv-id turns up below your boundary, that is either a relay failing to strip it or a forgery, and it is reported as critical.

Timing that refuses to invent a number

RFC 5322 defines -0000 and the obsolete alphabetic zones as offset unknown. A delay computed across one of those is fabricated, so it is left blank instead. Clocks on adjacent servers are not synchronised either, so a negative gap is reported as skew rather than as a negative duration.

What it cannot tell you

• Whether a DKIM signature is cryptographically valid. That needs the canonicalised message body, which is not in a header paste. This reads what the signature claims and what the receiver concluded, never whether it holds.
• Whether an ARC chain validates. Same reason. Structure only.
• Whether the originating IP is genuine. Only the hops above your own boundary are trustworthy, and everything below can be fabricated wholesale.
• Whether a message is a phish. It can tell you the message authenticates as nothing, which is a fact. What that means is your call.