Email authentication
Authentication-Results header explainer
Paste the Authentication-Results line off a message and read what every verdict in it means, including Microsoft’s compauth result and its three-digit reason code.
Free, no accountIn your browser
Paste the line on its own or the whole header block. Nothing you paste here leaves your browser.
Result
Nothing to explain yet
Paste an Authentication-Results line and every verdict in it, including Microsoft’s compauth reason code, is explained as you type.
What this is
This tool reads a pasted authentication-results header - the line the service that accepted a message stamped on it - and explains each verdict in it in plain words, including Microsoft’s non-standard compauth result and the three-digit reason code that sits beside it.
Authentication-Results is the one header in a message that records what the receiving service decided, rather than what the sender claimed. It names the host that did the checking, then one verdict per method - spf, dkim, dmarc - each with the properties that say which domain the verdict was about: smtp.mailfrom for SPF, header.d for DKIM, header.from for DMARC.
Microsoft 365 adds compauth to that line, and compauth is theirs alone: it combines SPF, DKIM and DMARC with other signals, judges the From: domain, and writes a three-digit reason code saying which of those decided the answer. No other provider stamps it, and no RFC defines it, which is why a code like 001 or 601 is unreadable without Microsoft’s own table - reproduced here, row by row, with their wording.
How to read the result
Each finding is one method from the line, with what that method actually asks and which domain this verdict was about. Where the result is Microsoft’s rather than the standard’s - compauth, a reason code, action=, bestguesspass - the finding says so, so you can tell a rule everyone follows from a rule one vendor wrote. The table underneath shows every verdict exactly as stamped, newest header first, since each service adds its own at the top and only the newest one is your own.
This page reads the verdicts one message already received, not why SPF, DKIM or DMARC produced them. For how the three protocols fit together, what order to fix them in, and what to do once one fails, see our guide How SPF, DKIM and DMARC work together, and what to do when one fails.
Common mistakes
What goes wrong most often, and how to tell.
- Reading an Authentication-Results line a forwarder wrote as if it were yoursA message that passed through a list or a forwarder arrives carrying that hop’s verdicts as well as your own service’s. Only the newest line - the top one, stamped by the host that delivered to you - decided what happened to the message; an older one tells you what somebody upstream saw before the message was rewritten.
- Treating compauth=fail as the reason a message was blockedMicrosoft’s own note is that despite a compauth failure the message might still be allowed if other assessments do not indicate a suspicious nature. The reason code beside it is the useful part: 001 points at a sender with no published authentication, while 601 points at spoofing inside your own accepted domain.
- Guessing at a reason code that is not in the tableMicrosoft publishes exact codes, a few families like 1xx and 4xx, and one range. A code that matches none of them is one they have not documented, and inventing a meaning for it is how a header gets read backwards - this page says plainly that there is no published row instead.
Questions
What people ask about this tool.
- Microsoft’s table gives 001 as implicit authentication failing: the sending domain published no email authentication records, or published weak ones - an SPF record ending ~all or ?all, or a DMARC policy of p=none. It is a statement about what the sender published, not about a cryptographic check going wrong.
- No. Composite authentication, its three-digit reason codes, action= and bestguesspass are all documented by Microsoft for their own service and appear in no RFC. Only spf, dkim and dmarc results in this header are standard, which is why this page labels the Microsoft-only parts as theirs and links the page they are published on.
- No, and nothing can from the header alone: the line records what one host decided at one moment, against DNS as it was then. To check what the domain publishes now, run it through the SPF, DKIM or DMARC checker - a key rotated or a record edited since the message arrived will give a different answer today.
- That is another Microsoft-only result: no DMARC TXT record exists for the domain, and in their words, if the domain had a DMARC TXT record, the DMARC check for the message would pass. It is a hint about what would happen if the domain published a policy, not a DMARC pass.
- Either works. Paste a whole raw header block and every Authentication-Results header in it is read, newest first; paste the single line, or even just the verdicts with the field name and checking host left off, and it is read on its own.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Microsoft, “Anti-spam message headers” read 13 October 2026
Use it from the API
The same check, as one request.