Three checks guard one email, and each one looks at a different name. Build a message, flip the switches and watch a receiver decide. The case below is the one that bounces mail from perfectly set-up domains.
A receiver sees three different domains on one message. SPF checks the envelope sender. DKIM checks the domain in the signature. DMARC checks the From address you actually read, and asks whether either of the other two names matches it.
What the reader sees in their inbox (RFC5322.From).
The bounce address used between servers (RFC5321.MailFrom). This is what SPF checks.
The DKIM signature added by the sending system. Its d= tag names the signing domain.
The DMARC record in DNS for the From domain.
Relaxed means the two names only need the same registered domain. Strict means they must match exactly. This lab finds the registered domain with a short built-in list of suffixes such as co.uk; real receivers use the Public Suffix List, as RFC 7489 describes.
Six cases, each judged by the same rule from RFC 7489 section 6.6.2: DMARC passes when at least one aligned identifier authenticates. Pick pass or fail, then see why. Every case can be loaded into the lab above.
Does this message pass DMARC?
SPF has a hard budget. RFC 7208 section 4.6.4 says an implementation must limit the terms that cause DNS queries to 10 per evaluation, and must return permerror beyond that. Only include, a, mx, ptr, exists and redirect count. ip4, ip6 and all are free. Add vendors until the budget breaks.
The vendor records here are made up to show the arithmetic. In a real record the lookups inside each include: count too, so the only way to know your total is to count your own providers. When SPF returns permerror, SPF cannot supply an aligned pass, and DMARC then depends on DKIM alone.
Two different things are circulating, and they are not the same. Official rules apply to large senders. A separate report, not confirmed by Microsoft when I checked, says some mail from domains with no DMARC record is also bouncing.
Microsoft announces that domains sending more than 5,000 emails a day to Outlook.com must pass SPF and DKIM, and publish DMARC with at least p=none that aligns with SPF or DKIM.
Per Microsoft's April 29 update, enforcement starts: non-compliant mail from high-volume domains goes to Junk first. Rejection with 550 5.7.515 was planned for a later date, still "to be announced" on the page as fetched on 9 Nov 2026.
MailRoute, an email security company, says it saw bounces in its own logs from this day: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, including for low-volume senders. It states that Microsoft had published nothing about it as of 6 Nov 2026.
The one-line fix everyone suggests
Why p=none is safe: RFC 7489 defines it as "the Domain Owner requests no specific action be taken regarding delivery". It only publishes the rulebook, so alignment can be measured before anything is enforced. Add rua=mailto:... to receive the aggregate reports. Whether a bare record satisfies Outlook.com's unannounced check is MailRoute's claim, not something I could confirm from Microsoft.