Your SPF passes, your DKIM passes, and DMARC still fails

An invoice from the ERP stops reaching a customer. You open the header and read spf=pass, you read dkim=pass, and two fields further along, dmarc=fail. Nobody mistyped the DNS. Something else is failing.

That combination is, by a distance, the one we have run into most often when taking over somebody else's domain, and it almost always arrives wrapped in the same sentence: "but the mail is set up correctly, we checked". And it is true that it is set up correctly. SPF authorises the sending server. DKIM signs the message and the signature validates. Both checks pass on their own and the message is still rejected, because DMARC is not asking whether they pass: it is asking whether they match the sender the recipient sees.

There are two senders, and you only see one

Every internet email carries two sender addresses, and Microsoft's documentation separates them by name. The first is the MAIL FROM address, "the email address used in the transmission of the message between SMTP email servers", also called the 5321.MailFrom or envelope sender. The second is the From address, the header one, "shown as the message sender in email clients", also the 5322.From. Servers use the first. The second is what your customer reads in their Outlook.

SPF and DKIM, on their own, do not require those two addresses to have anything to do with each other. The page says so itself: "SPF and DKIM don't require the domains in the following email addresses to 'align' (match)". That is the gap impersonation walks through: an attacker can stand up a domain, publish an immaculate SPF for it, sign with DKIM immaculately, and put your company's name in the From field. Both checks pass. The sender on display is yours. We have already written about how that trust gets exploited over the phone in the piece on who verifies at your help desk that you are who you say; this is the written version.

DMARC closes that gap by adding one more question: is the domain that just passed SPF or DKIM the same as the one in the From? That is called alignment, and the full rule fits in one line of the documentation: "A message passes DMARC if one or both of the described SPF or DKIM checks pass. A message fails DMARC if both of the described SPF and DKIM checks fail" — where "pass" already includes being aligned. One of the two aligned is enough. If neither aligns, it does not matter that both validated.

What this looks like in a header

The documentation carries the example itself, and it is a carbon copy of the invoice from the opening. This is the header of a message where both checks validate and it is rejected anyway:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

The three fields to look at, in this order: header.from= is the domain the recipient reads; smtp.mailfrom= is the envelope one; header.d= is the one that signed. Here the first says contoso.com and the other two say adatum.com. Neither aligns, which is why the result is dmarc=fail with action=oreject — the "o" stands for origin, meaning the rejection was asked for by the sending domain's policy. If you see action=pct.reject, the sender published p=reject with a pct= below 100 and your message happened to be in the sample.

The table worth printing out

Microsoft publishes an alignment table with five rows. The aspf and adkim tags in the record decide how strict it is: relaxed (r, the default) accepts subdomains of the same organisational domain; strict (s) requires an exact match. Here is the table, with the From header domain on the left and the MAIL FROM or DKIM signing domain on the right:

The fourth row is the one that surprises most people, because it looks like family and is not, and relaxed mode does not save it either: a message whose From is @contoso.com signed with the domain contoso.onmicrosoft.com does not align. They are two different organisational domains, however much one is the other's tenant. It is the classic case of somebody who added their own domain and never got round to configuring DKIM signing with it, and it is another reminder that the onmicrosoft.com domain is not somewhere to settle down.

Where it actually breaks: in your applications

The mail people write from Outlook is almost never the problem: it leaves the tenant with your own domain in both addresses and aligns on its own. The problem lives in everything else that sends mail with your domain in the From without anyone having it written down anywhere. The real list for a small company, the one that appears when you sit down to make it, usually looks like this:

For each one, Microsoft's documentation gives exactly two ways out, and they are worth reading before you start editing records. One: change the service's MAIL FROM to a domain of yours — the literal resolution it proposes for the scenario of an external service sending on your behalf is "Configure DKIM signing with your domain at the service, or change MAIL FROM to your domain/subdomain". Two: have the service sign with DKIM using your domain, that is with d=yourdomain.com. If the provider allows neither, there is the third route the guide itself recommends and almost nobody applies: use a subdomain for that service — "for email services that aren't under your direct control (for example, bulk email services), use a subdomain" — and publish its own DMARC record, so that a reputation problem of theirs does not take your people's mail down with it.

The report that tells you who sends as you

The protocol publishes that list for you, if you ask it to. A record with rua=mailto: asks recipients for an aggregate XML report, typically daily, containing, literally, "the IP addresses of servers or services that send mail using your domain" and whether they pass or fail. It is the sender census nobody has written down.

Reading it has a catch, and it is the same catch as the whole post. In the XML there are two blocks that look alike and are not: <auth_results> says whether SPF and DKIM validated raw, and <policy_evaluated> says whether they aligned. Microsoft's guide flags this as the single most important reading of the report: "The most important insight from aggregate reports is identifying the gap between authentication pass and alignment pass". A block with <spf><result>pass</result></spf> in the first and <spf>fail</spf> in the second is exactly the ERP from the opening, with its IP next to it so you know which one we are talking about.

Two operational traps almost nobody warns you about, both written on the same page. First: Microsoft 365 does not send forensic reports (ruf=) even if you put a valid address there, so if you are waiting on those messages to debug, they are not coming from that direction. Second, and bigger: Microsoft 365 only sends aggregate reports "as long as the MX record for the Microsoft 365 domain points directly to Microsoft 365". If you have a security gateway or a filter in front, or a hybrid scenario with on-premises delivery, those reports are not sent. Which means precisely the more complex installations, the ones that need the census most, are the ones left without it if nobody tells them.

The order matters, and there is a hurry but not that much

The temptation, when somebody discovers this, is to publish p=reject that same Friday. Microsoft proposes the opposite, with a sentence worth reading twice: "Blocking legitimate email in any significant volume is unacceptable to users, but it's almost inevitable that you're going to get some false positives". The plan it publishes is: start at p=none with reports and watch; move up to p=quarantine, using pct= in steps of 10, 25, 50, 75 and 100 to affect more mail progressively; and only then p=reject. Starting with the lowest-volume subdomain and leaving the main domain for last.

One more warning, because it affects you rather than whoever writes to you: outbound mail from your Microsoft 365 domains that fails DMARC at the destination is routed through the high-risk delivery pool if your policy is p=reject or p=quarantine, and the documentation closes that off without softening it: "There's no override for this behavior". Hardening the policy before fixing your own senders does not only reject mail: it puts your own traffic in the slow lane.

And a finishing touch that costs nothing and almost nobody does: domains you have registered and do not use for mail also need their record. Microsoft's recipe for a parked domain is one line, v=DMARC1; p=reject;, with no pct= and no report addresses, because no legitimate mail should ever come from there. And it adds the case everyone forgets: that includes your own *.onmicrosoft.com domain if you are not using it to send.

The limits of what we have just said

Everything quoted here comes from Microsoft's documentation for Microsoft 365 as revised on 3 July 2026 and can change; DMARC as a protocol is described in RFC 7489, and other mail providers may behave differently given the same policy. We have not included figures on how much deliverability improves when you move to p=reject, because we have no source we could defend, and the numbers circulating out there almost always come from whoever sells the reporting dashboard. What we do know is where the failure sits, and it sits in alignment.

And the conflict of interest up front: everyWAN charges for doing this inventory and for writing it down. The verifiable part is what is quoted and linked; publishing the record with rua= and spending a month reading the reports is something anyone can do without us, and it is exactly what we recommend you do before asking anybody for a quote, ourselves included.

Sources (verified on 4 October 2026): the definition of the 5321.MailFrom and 5322.From addresses, the sentence "SPF and DKIM don't require the domains […] to 'align' (match)", the DMARC pass and fail rule, the relaxed and strict alignment table with its five rows, the common failure scenarios and their resolutions, the recommendation to use a subdomain for services you do not control, the contents of the aggregate report and the sentence about the gap between "authentication pass" and "alignment pass", the fact that Microsoft 365 does not send forensic reports and only sends aggregate reports if the MX record points directly to Microsoft 365, the gradual p=none → p=quarantine → p=reject plan with its pct= steps, the warning about the high-risk delivery pool for outbound mail, and the recommended record for parked domains — "Set up DMARC to validate email in Microsoft 365", Microsoft Learn, revised 3 July 2026. The protocol specification — RFC 7489. Cover photograph: "Konica Minolta Bizhub C454e photocopier" by Baron Maddock, Wikimedia Commons, licensed CC BY 4.0.