How to Check Email Headers: SPF, DKIM and DMARC

By Ahsan

Email headers are the metadata block carried at the top of every email message. The block records the route a message took between mail servers, the authentication checks applied to it, and the software that handled it along the way. A message that reaches an inbox with a forged sender address still carries the headers added by each server on its route, and those headers form the record used to establish where the message came from and whether it was altered in transit.

Message structure

A message consists of a header block and a body, separated by a blank line. The header block holds named fields such as From, To, Subject, Date and Message-ID, together with MIME fields that describe how the body is encoded. The sending client writes the first fields, and each server on the route adds further fields. Received headers are prepended rather than appended, so the chain reads from the bottom upward, with the earliest hop at the bottom and the final delivery at the top. The body is a MIME structure of parts, with text and HTML versions, attachments and embedded images each carried as a separate part.

Received headers

Each Received header records the server a message came from, the server that accepted it, the protocol used, and the time of the handover, with the from clause naming the connecting host and its IP address. A message sent through three relays carries three Received headers, and the bottom one records the first handover from the sender's own server. Each server adds its entry above the entries already present, which places the origin at the bottom of the block. The earliest entries carry the least trust, because they were written by servers under the sender's control and can be fabricated before the message reaches any server the recipient's provider operates.

Authentication results

The Authentication-Results header records the verdicts a receiving server reached when it checked the message, with one entry each for SPF, DKIM and DMARC. SPF checks the envelope sender, the MAIL FROM address used in the SMTP exchange rather than the From address shown in the inbox, against the TXT record published for that domain, and the check passes when the connecting server appears in the list of permitted servers. RFC 7208 sets the SPF specification and limits evaluation to ten DNS lookups, so a record with too many include terms returns a permanent error. DKIM adds a cryptographic signature to the message, and the receiving server fetches the public key from DNS at the selector named in the signature to verify it. DMARC then compares the domain in the visible From address with the domains that passed SPF and DKIM, and applies the published policy when neither check aligns.

DKIM signatures

The DKIM-Signature header carries the fields the receiving server needs to verify the signature. The d tag names the signing domain, the s tag names the selector, the h tag lists the signed headers, the bh tag holds a hash of the message body, and the b tag holds the signature itself. The public key sits in a DNS TXT record at the selector followed by _domainkey and then the domain, and the receiving server recomputes the body hash and checks the signature. The From header must appear in the signed list, which is the field the check ties the signature to. A signature fails when the body or a signed header was modified after signing, or when the selector has no matching public key in DNS. A forwarder that rewrites the subject line or appends a footer breaks the body hash, while one that leaves the signed headers and body untouched preserves the signature.

DMARC alignment

DMARC is the policy layer that gives the other two checks a consequence. A DMARC record lives at _dmarc followed by the domain, and its p tag sets the policy for messages that fail both SPF and DKIM alignment: none, which asks for no action, quarantine, which asks for the spam folder, or reject, which asks for refusal. The rua tag names an address for aggregate reports, so a domain owner receives regular summaries of which servers sent mail in its name and whether each stream passed. Alignment ties the checks to the address the reader sees, because neither the envelope sender checked by SPF nor the signing domain checked by DKIM is the visible From address. DMARC became a Standards Track specification as RFC 9989 in May 2026. The provider rules give the policy its weight: Google and Yahoo have required SPF or DKIM from every sender since 1 February 2024, with bulk senders above about 5,000 messages a day to personal Gmail accounts required to pass both and publish a DMARC record. Outlook.com has applied the same requirement to high-volume senders since 5 May 2025, rejecting non-compliant mail with the error 550 5.7.515. The bulk sender requirements are set out in full in the provider requirement summaries, and the record formats are covered in the SPF, DKIM and DMARC checking guide.

Alias forwarding and X-Ray

Forwarding changes the authentication picture because it changes the envelope sender. When a message is forwarded, the forwarding server becomes the sender in the SMTP exchange, so the SPF check runs against the forwarder's domain rather than the original sender's domain, and the original SPF result no longer applies. DKIM survives forwarding when the forwarder leaves the signed headers and the body unchanged, which makes it the check that carries the original authentication through a forwarding chain. AliasFleet presents the same record per message through Email X-Ray, a Pro feature that lists the MIME headers, the server hops and the SPF, DKIM and DMARC verdicts for forwarded mail. The verdicts authenticate the domain a message claims to come from, and they do not establish that the message is safe, because a message can pass all three checks while carrying a link to a site the sender controls.