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.

Authentication-Results header

Paste the line on its own or the whole header block. Nothing you paste here leaves your browser.

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.

Common mistakes

Reading an Authentication-Results line a forwarder wrote as if it were yours — A 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 blocked — Microsoft’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 table — Microsoft 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 does compauth=fail reason=001 actually mean?

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.

Is compauth part of the email standards?

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.

Can this tool tell me whether the verdict in my header is correct?

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.

Why does my header show dmarc=bestguesspass?

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.

Do I need to paste the whole header block, or just the one line?

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 this page gives you comes from the provider’s own documentation. These pages change, so each one says the day it was last read here.

Microsoft, “Anti-spam message headers” — read 13 October 2026

Resell mailbox licences for the domains you just checked, under your own brand.

Get started

API example

Example request

curl -X POST https://163-123-236-68.sslip.io/api/tools/authentication-results-header-explainer \
  -H "Content-Type: application/json" \
  -d '{"header":"Authentication-Results: spf.protection.outlook.com; spf=fail (sender IP is 203.0.113.9) smtp.mailfrom=example.net; dkim=fail (body hash did not verify) header.d=example.net; dmarc=fail action=oreject header.from=example.net; compauth=fail reason=001"}'

Example response

{
  "tool": "authentication-results-header-explainer",
  "input": {
    "header": "Authentication-Results: spf.protection.outlook.com; spf=fail (sender IP is 203.0.113.9) smtp.mailfrom=example.net; dkim=fail (body hash did not verify) header.d=example.net; dmarc=fail action=oreject header.from=example.net; compauth=fail reason=001"
  },
  "result": {
    "verdict": {
      "tone": "danger",
      "headline": "spf=fail · dkim=fail · dmarc=fail · compauth=fail",
      "summary": "Microsoft recorded compauth=fail with reason 001: The message failed implicit authentication (compauth=fail). The sending domain did not have email authentication records published, or if they did, they had a weaker failure policy (SPF ~all or ?all, or a DMARC policy of p=none)."
    },
    "findings": [
      {
        "id": "spf-fail",
        "severity": "fail",
        "title": "spf=fail: this check failed for example.net",
        "detail": "SPF asks whether the IP that handed the message over is allowed to send for the envelope sender in MAIL FROM — the address in smtp.mailfrom, which is rarely the one the reader sees. This verdict is about example.net.",
        "fix": "Run the From: domain through the SPF checker and compare what it publishes against the IP in the comment above: the usual cause is a sending service nobody added to the record."
      },
      {
        "id": "dkim-fail",
        "severity": "fail",
        "title": "dkim=fail: this check failed for example.net",
        "detail": "DKIM asks whether the signature on the message verifies against the key published by the signing domain in header.d. It says who signed, not who the message claims to be from. This verdict is about example.net.",
        "fix": "Run the signing domain and the selector in header.s through the DKIM checker to see what that selector publishes today — a rotated or withdrawn key is the common cause of a fail on an old message."
      },
      {
        "id": "dmarc-fail",
        "severity": "fail",
        "title": "dmarc=fail: this check failed for example.net",
        "detail": "DMARC asks whether SPF or DKIM passed for a domain that lines up with the From: address in header.from, and then applies that domain’s published policy. This verdict is about example.net.",
        "fix": "Check the From: domain with the DMARC checker: a DMARC fail means neither SPF nor DKIM passed for a domain that lines up with the From: address, so fix whichever of the two was meant to."
      },
      {
        "id": "compauth-fail",
        "severity": "fail",
        "title": "compauth=fail: this check failed",
        "detail": "Composite authentication is Microsoft’s own, not a standard: \"Microsoft 365 combines multiple types of authentication (SPF, DKIM, and DMARC) and other parts of the message to determine whether the message is authenticated. Uses the From: domain as the basis of evaluation.\"",
        "fix": "Read the reason code below first — it says which of SPF, DKIM, DMARC or Microsoft’s own spoof rules decided it. Microsoft notes that \"despite a compauth failure, the message might still be allowed if other assessments don’t indicate a suspicious nature\"."
      },
      {
        "id": "compauth-reason-code",
        "severity": "info",
        "title": "reason=001: what Microsoft publishes for it",
        "detail": "Microsoft's table gives 001 as: The message failed implicit authentication (compauth=fail). The sending domain did not have email authentication records published, or if they did, they had a weaker failure policy (SPF ~all or ?all, or a DMARC policy of p=none)."
      },
      {
        "id": "dmarc-action-explained",
        "severity": "info",
        "title": "action=oreject beside the DMARC result",
        "detail": "oreject appears in Microsoft’s own examples but has no row of its own in their table of action values, so this page states no meaning for it rather than guessing."
      },
      {
        "id": "microsoft-codes-not-a-standard",
        "severity": "info",
        "title": "These parts of the line are Microsoft’s, not a standard",
        "detail": "compauth, its reason codes, action= and bestguesspass are documented by Microsoft for their own service and appear in no RFC. Another provider will not stamp them, and the meanings here are only as complete and as current as Microsoft’s page, which is linked and dated below."
      }
    ],
    "parts": [
      {
        "kind": "facts",
        "title": "Who checked this message",
        "rows": [
          [
            "Checking host",
            "spf.protection.outlook.com"
          ],
          [
            "Methods reported",
            "spf, dkim, dmarc, compauth"
          ],
          [
            "Authentication-Results headers",
            "1"
          ]
        ]
      },
      {
        "kind": "table",
        "title": "Every verdict in the paste, newest header first",
        "columns": [
          "Method",
          "Result",
          "Stamped by",
          "Properties"
        ],
        "mono": [
          0,
          1,
          2,
          3
        ],
        "rows": [
          [
            "spf",
            "fail",
            "spf.protection.outlook.com",
            "smtp.mailfrom=example.net"
          ],
          [
            "dkim",
            "fail",
            "spf.protection.outlook.com",
            "header.d=example.net"
          ],
          [
            "dmarc",
            "fail",
            "spf.protection.outlook.com",
            "action=oreject header.from=example.net"
          ],
          [
            "compauth",
            "fail",
            "spf.protection.outlook.com",
            "reason=001"
          ]
        ],
        "note": "Properties are shown exactly as stamped. A parenthesised comment beside a result is the checking host’s own note and carries no defined meaning."
      },
      {
        "kind": "facts",
        "title": "Microsoft composite authentication",
        "rows": [
          [
            "compauth",
            "fail"
          ],
          [
            "reason",
            "001"
          ],
          [
            "Microsoft's row",
            "001"
          ]
        ]
      },
      {
        "kind": "text",
        "title": "What Microsoft's table says about that code",
        "body": "The message failed implicit authentication (compauth=fail). The sending domain did not have email authentication records published, or if they did, they had a weaker failure policy (SPF ~all or ?all, or a DMARC policy of p=none)."
      }
    ],
    "limits": [
      "This reads a verdict somebody else already recorded. It cannot re-run the SPF, DKIM or DMARC check behind it — the live checkers linked below do that against what the domain publishes today.",
      "Anyone can type an Authentication-Results line into a message. Only the one your own receiving service stamped, named as the checking host above, is evidence; anything above it came from whoever was upstream.",
      "Microsoft’s compauth and its three-digit reason codes are their own documentation rather than a standard, and this table is only as complete as their page was on 13 October 2026. A code with no row there is one Microsoft has not published, and that is what this page says about it."
    ]
  }
}

Related tools

Email authentication