Gmail Passes, Microsoft Quarantines: Fix DMARC Alignment

You added a new sender. Gmail says dmarc=pass. Microsoft puts the same flow in junk, delays it, or rejects it with a 550 5.7.x error. Product asks whether email is “fixed.” Support says customers are missing password resets. Nobody wants to debug headers at midnight.

This is not a Gmail-vs-Microsoft mystery. It’s almost always one of two things: the message genuinely isn’t aligned and Gmail is just more forgiving about it, or the two receivers saw different mail paths for reasons that have nothing to do with authentication. You can tell which one you have in about ten minutes, with headers, not guesses.

If the rejection itself is the more pressing problem, the exact fixes for Gmail’s 550 5.7.26 and Microsoft’s 550 5.7.515 are their own posts. This one is for figuring out why the receivers disagree in the first place.

The mechanics, fast

DMARC needs SPF or DKIM to both pass and align with the visible From: domain. Passing alone isn’t enough. A message can show spf=pass and still fail DMARC because the passing domain was mailer.vendor.example.net, not example.com. The full mechanics, with an annotated header, are in DMARC alignment explained. Read that first if header.d= and smtp.mailfrom= alignment is new to you. What matters here: once a message aligns cleanly, a Gmail/Microsoft split stops being an authentication question and becomes a receiver-behavior question.

Step 1: capture the raw headers from both receivers

Don’t debug this from a provider dashboard. Send the same type of message to a Gmail mailbox and a Microsoft 365 / Outlook mailbox, then pull the original headers.

Gmail: open the message → three-dot menu → Show original.

Microsoft 365 / Outlook: open the message → View message details or View source, depending on the UI.

From each, copy From, Return-Path, every DKIM-Signature, and every Authentication-Results line:

From: Billing <billing@example.com>
Return-Path: <bounce@mailer.vendor.example.net>
Authentication-Results: ... spf=pass smtp.mailfrom=mailer.vendor.example.net
Authentication-Results: ... dkim=pass header.d=example.com
Authentication-Results: ... dmarc=pass header.from=example.com

If Microsoft rejected the message outright, you may only have an NDR or an SMTP log. Keep the rejection text and your sending provider’s event log. The same alignment checks still apply to the message as sent, even without the receiver-side headers.

Step 2: confirm the message actually aligns

Check header.d= on the DKIM signature and smtp.mailfrom= on the SPF result against the visible From: domain. Aligned:

dkim=pass header.d=example.com
dmarc=pass header.from=example.com

Not aligned: SPF passed for the vendor’s domain, and DKIM signed with the vendor’s domain too.

dkim=pass header.d=vendor.example.net
spf=pass smtp.mailfrom=mailer.vendor.example.net
dmarc=fail header.from=example.com

If Gmail shows this and passes anyway, something is off with your capture (check you pulled the right message). Gmail enforces the same alignment rule. If both receivers show a clean aligned pass and still disagree on disposition, move to Step 3.

Step 3: compare the two Authentication-Results lines side by side

Put Gmail’s and Microsoft’s results next to each other:

Gmail:     dmarc=pass, disposition=none
Microsoft: dmarc=fail, disposition=quarantine

or:

Gmail:     dmarc=pass
Microsoft: dmarc=pass, disposition=quarantine (local policy)

The first pattern means the receivers ran different checks: one saw a message that genuinely fails alignment, one didn’t. That usually traces to one of:

  • Forwarding or a mailing list rewrote the message before Microsoft saw it, breaking the DKIM signature or changing the envelope sender. Gmail may have received a different, unmodified copy. See why forwarding breaks SPF and DMARC for the mechanism.
  • DNS propagation reached one receiver before the other. If you just published or changed a DKIM or SPF record, wait and resend.
  • The message was actually two different sends: a retry, a resend from a queue, or a slightly different payload triggered by an A/B test or template variant. Confirm you’re comparing the same send, not two.

The second pattern (DMARC passes at both, but Microsoft still quarantines) means authentication isn’t the problem. That’s a Microsoft-side tenant policy, spam filter, or reputation decision layered on top of a passing DMARC result. RFC 9989 §7.4 is explicit that receivers must not reject mail solely because a domain publishes p=reject — and the reverse holds too: nothing stops a receiver from quarantining a message that passes DMARC. Don’t go chasing DNS records for this one. It’s a deliverability/reputation question, not an authentication bug.

Step 4: check aggregate reports for the pattern, not just the one message

One test message tells you about one send. Aggregate reports tell you whether this is systemic. In DMARC Guardian, reports are grouped by sender (the From domain) or by source IP, and the reporting organization is visible on each report, so you can pull every row Microsoft has sent for a source and compare it against Google’s rows for the same source without re-sending test mail. Look for the source that’s clean everywhere except one reporting organization; that’s your Microsoft-specific (or Gmail-specific) sender, and now you have the IP and header data to go debug it instead of guessing.

Operator checklist

For the sender you’re chasing:

  • Capture raw headers from a real Gmail test message and a real Microsoft test message.
  • Confirm the visible From: domain on both.
  • Confirm at least one aligned SPF or DKIM result on each, not just a pass.
  • If one receiver shows unaligned results the other doesn’t, check for forwarding, a rewritten envelope, or a DNS propagation gap.
  • If both receivers show a clean DMARC pass and Microsoft still quarantines, stop looking at DNS: it’s tenant policy or reputation.
  • Pull aggregate reports for the source and compare rows across reporting organizations before you touch any record.

Don’t hand-wave it as deliverability

This failure rarely looks dramatic. No one gets paged because “DMARC alignment is wrong.” Password resets just disappear, invoices land in junk, and support spends an afternoon asking customers to check spam. Pull the headers, compare From, smtp.mailfrom, and header.d, and you’ll know within minutes whether you have an authentication bug or a Microsoft-specific policy call: two very different fixes.

Run a free check on your domain →