Email authentication helps a receiving system assess whether a message is authorized to use a domain. It does not certify the person behind a display name or establish that an attachment, link or payment request is safe.
Microsoft’s February 24, 2004 Caller ID for E-Mail announcement proposed publishing sending-server information to help address spoofing. That historical proposal explains this page’s URL. Today’s SPF, DKIM and DMARC mechanisms have their own specifications; they should not be treated as a renamed version of that one proposal.
Notice which identity is being checked
A message can contain a friendly display name, a visible From address, an envelope sender used during transport, a Reply-To address and a signing domain. Those fields do not necessarily match. Before interpreting a pass or fail, ask which domain the result refers to.
The following is a conceptual comparison. Read the individual standards for exact processing rules and use your provider’s tools for a real investigation. Header fields inside an untrusted message can themselves be forged; rely on authentication results established by your receiving service, not an arbitrary pasted header line.
| Mechanism | What it checks | What a pass does not prove |
|---|---|---|
| SPF | Whether the sending host is authorized for the evaluated envelope-sender or HELO domain. | That the visible From address or message content is trustworthy. |
| DKIM | A domain’s cryptographic signature over selected message content, using a published key. | That the signer is the person named on screen or that the signed content is benign. |
| DMARC | Whether passing SPF or DKIM aligns with the visible From domain, under the applicable alignment rules. | That the request is legitimate or the authenticated account is uncompromised. |
The specifications include SPF (RFC 7208), DKIM (RFC 6376) and DMARC (RFC 9989). The 2026 DMARC standard supersedes RFC 7489; its reporting specifications are aggregate reporting and failure reporting. DMARC can pass through either an aligned SPF result or an aligned DKIM result; both are not required. A domain’s policy expresses a handling preference, while receivers retain their own filtering decisions.
Worked example: a pass for the wrong expectation
The practical habit is to separate origin checks from the requested action. A legitimate origin can carry a harmful request; a failed check can also result from configuration or forwarding behavior. Neither result replaces investigation.
For readers: verify the action, not just the badge
- Expand sender details where your mail app permits it, and compare the domain with the one you expected.
- For an unexpected request involving money, credentials or confidential information, use a known contact method independent of that message.
- Report suspicious mail using your provider’s or organization’s reporting function. Avoid forwarding a live suspicious attachment to colleagues as a test.
- If you already entered credentials or ran a file, move to the appropriate account or device response.
Lookalike spelling, display names and compromised legitimate accounts are reasons to keep this separate verification step even when authentication succeeds.
For domain owners: inventory before enforcement
Microsoft’s email-authentication overview explains how the mechanisms work together in its service. Configuration depends on your actual senders and provider, not a universal DNS record copied from an article.
List every authorized sending service: employee mail, invoices, support systems, newsletters and any other application sending as your domain. For each, record its owner, signing or sender-domain configuration and a receiving-side verification result. Review reports and legitimate delivery failures before tightening policy. Forwarding and message modification can affect checks, so test the routes your organization really uses.
Keep a rollback and change owner. A published record is evidence of configuration; it is not evidence that every legitimate sender is covered or that every recipient applies policy identically. Revisit the inventory whenever a sending service changes.