Skip to main content
Security
Published 3 min read

What Is an Authentication-Results Header?

How receiving servers record SPF, DKIM and DMARC outcomes, and how to read the fields.

The Authentication-Results header, defined in RFC 8601, is where a receiving mail system writes down what its checks found. It is the single most useful header for a quick answer to the question: did SPF, DKIM and DMARC pass on this message?

Anatomy of the header

Authentication-Results: mx.example.net;
        spf=pass [email protected];
        dkim=pass header.d=example.com header.s=mail2026;
        dmarc=pass (p=REJECT) header.from=example.com
  • authserv-id (mx.example.net): the server that did the checking.
  • Method and result (spf=pass): the check that ran and its outcome.
  • Properties (smtp.mailfrom, header.d, header.s, header.from): which identity was checked. smtp.* values come from the SMTP envelope, header.* from message headers.
  • Comments in parentheses: free text such as the DMARC policy or the reason for a result.

The sections are separated by semicolons, and long values are folded across lines, so any parser has to unfold the header before splitting it.

Common results

ResultMeaning
passThe check succeeded
failThe check failed
softfailSPF only: probably not authorized, but not a hard fail
neutralThe domain made no statement
noneNo record or signature to check
temperrorA temporary problem, often DNS
permerrorA permanent problem, such as a broken record

Some systems write it differently

Not every system follows the same layout. Exchange Online, for example, begins with a method result and no server name, then adds properties such as compauth. A good parser should read the standard layout first and cope with these variations, which is how the Email Header Analyzer handles them.

Several headers on one message

A message can pass through several systems that each add an Authentication-Results header, so seeing more than one is normal. Do not merge them: read each one with its authserv-id, because a gateway may record a result before forwarding while the final mailbox provider records a different one afterward. Disagreement can be explained by forwarding or modification in between. The header closest to the top was added most recently.

Trust

Only trust your own provider's header

A sender can place a fake Authentication-Results header in a message. Compliant receivers strip or ignore headers that claim to be their own, but you should rely on the header added by your own mail system and treat others as information.

Paste a message's headers into the Email Header Analyzer to see every Authentication-Results header listed separately with its results and domains.

Share headers safely

Headers contain addresses, IP addresses and server names. If you need to paste them into a ticket or chat, mask the sensitive values first with the Log Sanitizer, and only analyze messages you are authorized to inspect.

Frequently asked questions

Why is there more than one Authentication-Results header?
Each system that checks the message can add its own, for example a gateway and then a mailbox provider. They record results at different points, so they may legitimately differ.
What is the authserv-id?
The first item in the header. It names the server that performed the checks, which tells you whose statement you are reading.
Can the sender fake this header?
A sender can include one in the message they send. Receivers are expected to remove or ignore such headers from outside their own system, so rely on the one added by your own provider.

The tool that pairs with this guide.

Did this help you tighten your security headers?

If these free developer tools save you time, consider buying me a byte. Your support helps keep DevCraftKit free and growing.

Buy me a byte 💾