An email header tells a complete story: who sent the message, which relays it passed through, which authentication checks passed, which failed, and why. Every deliverability problem you will diagnose in your career is visible in the headers if you know where to look.
The problem is that there are now seven or more different headers carrying authentication information. They overlap, they contradict, and the receiver decides which to trust based on internal rules you cannot see. Here is how to read each one, and how the free analyzer at check.live-direct-marketing.online parses all of them into a plain-English verdict.
Because the mail may have been relayed, forwarded, or ARC- sealed by an intermediate system. The final receiver may rewrite or add its own Authentication-Results line. The ARC chain carries the original verdict. Reading only the last line loses information.
The headers that matter
In order of when they appear and what they tell you:
- Received — one per hop, newest first. Tells you the path and timing.
- Received-SPF — legacy SPF-specific header. Still added by some receivers.
- DKIM-Signature — one per DKIM signing operation. Contains domain, selector, canonicalisation, and the signature itself.
- Authentication-Results — summary of all auth checks performed at a specific server.
- ARC-Authentication-Results — same summary, but cryptographically preserved for downstream receivers.
- ARC-Message-Signature — signature over the message at the time of sealing.
- ARC-Seal — signature over the ARC chain itself. Prevents tampering with the chain.
How to read the Authentication-Results line
The format is defined in RFC 8601. It starts with the server that made the checks, then lists each method and its result.
Authentication-Results: mx.google.com;
dkim=pass header.i=@yourbrand.com header.s=s1 header.b=abcd1234;
spf=pass (google.com: domain of bounce@yourbrand.com designates 203.0.113.42 as permitted sender) smtp.mailfrom=bounce@yourbrand.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourbrand.com;
arc=none (no signatures found)Line by line: dkim=pass with the signing identity (header.i), selector (header.s), and a prefix of the signature (header.b). spf=pass with a human comment and the envelope MAIL FROM. dmarc=pass with the published policy and the disposition actually applied. arc=none means no ARC chain — either the message was not relayed or the relay did not seal.
Watch the dis= field in DMARC. It tells you what the receiver actually did, which can differ from the published policy. dis=NONE = delivered. dis=QUARANTINE = spam folder. dis=REJECT = 550 response.
ARC chain explained
Authenticated Received Chain (ARC) solves the mailing-list problem. When a list expands a message, adds a footer, and forwards it, the original DKIM signature breaks (body hash changes) and SPF fails (envelope sender becomes the list). Without ARC, DMARC would reject every mailing-list message.
ARC works by letting each intermediate server add a sealed record of what it saw before modifying the message. A downstream receiver reads the chain, verifies each seal, and treats the earliest trusted verdict as authoritative.
In the headers you see ARC-Authentication-Results (what the intermediary saw), ARC-Message-Signature (a snapshot of the message), and ARC-Seal (a signature over the chain). Each has an instance number i=1, i=2, etc. A chain of five means five intermediaries signed.
What Google's compauth=fail means
Google adds a proprietary compauth field to its Authentication-Results. It is the composite verdict Gmail actually uses to route.
compauth=pass— authentication succeeded, mail is trusted.compauth=softfail— ambiguous, often routed to Promotions.compauth=fail— authentication failed composite check. Usually spam, sometimes outright reject.compauth=none— no domain to authenticate. Common for personal mail.
A compauth=fail with reason=001 indicates DMARC failure. reason=002 indicates spoofing detected via SPF/DKIM conflict. reason=601 or higher are Gmail-specific heuristics. The full reason codes are not published, but 001 and 002 cover most cases.
How to tell SPF passed but DMARC failed
This is the single most common authentication puzzle. The header will show:
spf=pass smtp.mailfrom=bounce.esp-provider.net;
dmarc=fail (p=REJECT dis=QUARANTINE) header.from=yourbrand.comSPF passed because the envelope sender is bounce.esp-provider.net and the connecting IP is on that domain's SPF record. DMARC failed because bounce.esp-provider.net does not align with the header From yourbrand.com. The message is in Quarantine (dis=QUARANTINE). Fix: align the envelope sender to your domain (custom Return-Path in your ESP), or get DKIM signing aligned on d=yourbrand.com.
Using the free header analyzer
Paste a raw email header into the analyzer at check.live-direct-marketing.online/headers. The tool parses every authentication line — including the ARC chain, legacy Received-SPF, Google's compauth, Outlook SCL, and the Mail-Ru / Yandex Russian-localised auth output. The verdict is a plain-English summary:
- Sender, envelope sender, recipient.
- SPF result + why.
- DKIM result per signing identity (if there are two signatures, you see both).
- DMARC result + policy + disposition.
- ARC chain length and whether each seal verified.
- Relay path from the Received headers, with geolocation.
- Red-flag fields: FREEMAIL From, forged Reply-To, etc.
Example headers with common issues
A header with all three authentication methods failing because of a misconfigured ESP:
Received: from outbound-esp.net (outbound-esp.net [198.51.100.5])
by mx.google.com with ESMTPS id abc123
for <user@gmail.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
Tue, 16 Jun 2026 09:12:45 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning
bounce@yourbrand.com does not designate 198.51.100.5 as permitted sender)
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) header.i=@yourbrand.com header.s=default;
spf=softfail smtp.mailfrom=bounce@yourbrand.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourbrand.com;
compauth=fail reason=001
ARC-Authentication-Results: i=1; mx.google.com;
dkim=fail; spf=softfail; dmarc=fail
DKIM-Signature: v=1; a=rsa-sha256; d=yourbrand.com; s=default;
c=relaxed/relaxed; h=From:Subject:Date:To;
bh=AAABBBCCCDDDEEEFFF=; b=signature-bytes...
From: Hello <hello@yourbrand.com>
Subject: Our new product is liveReading this: the mail came from the ESP's outbound IP (198.51.100.5), SPF softfailed because the customer's SPF did not include the ESP. DKIM failed body-hash — almost certainly because a relay modified the body after signing, or the signer used a stale public key. DMARC failed but policy is p=NONE, so dis=NONE (delivered anyway). compauth=fail reason=001 is Gmail's composite verdict: untrusted. Action: route the recipient to spam. Fix priority: 1) add the ESP to SPF, 2) investigate body-hash DKIM failure (whitespace normalisation, signing order).
Most commercial header analyzers are a UI over dig, nslookup and a parser. The underlying data is all in the header itself. A free analyzer that parses the same fields gives you the same fidelity. Pay for monitoring, alerts, historical trends — not for header parsing.