Guide

DMARC fail: why legitimate email fails DMARC, and how to fix it

By Adam Sierant, Director of Northstar Infinity Works Ltd · Updated 10 September 2026 · 5 min read

What a DMARC failure means

A message fails DMARC when neither of its checks aligns: SPF did not pass for a domain matching the From address, and DKIM did not pass for one either. That is not the same as SPF or DKIM failing. A message can pass both and still fail DMARC, because the domains that passed belong to someone else.^[1]

What happens next depends on the sending domain’s policy. At none, nothing changes; at quarantine, receivers treat the message as suspicious; at reject, they refuse it.^[2] That is why failures matter most just before a firm tightens its policy: every legitimate service still failing is mail that will be junked or bounced.

Reading the evidence in a message header

Receiving systems record their verdict in the Authentication-Results header. In a message received by Microsoft 365, look for three values: smtp.mailfrom, the envelope domain that SPF checked; header.d, the domain that signed with DKIM; and header.from, the domain in the From line.^[1]

Authentication-Results: spf=pass smtp.mailfrom=bounces.billing.example;
  dkim=pass header.d=billing.example;
  dmarc=fail action=oreject header.from=samplefirm.example

Here SPF and DKIM both passed, for billing.example. Neither matches samplefirm.example, so DMARC failed, and action=oreject shows that the sending domain’s reject policy was applied.^[1]

The common causes

A service sends as the firm with its own domain

Case management, practice accounts, e-billing, e-signature, newsletter and survey tools often send email that shows the firm’s address in the From line while using their own envelope domain and signing with their own DKIM key. SPF and DKIM pass for the provider, and DMARC fails for the firm.^[1]

The fix is to make one of the two checks align. Configure DKIM signing at the service with the firm’s domain, usually by publishing records the provider supplies, or change the envelope address to the firm’s domain or one of its subdomains. If the service can do neither, send its mail from a subdomain with its own records.^[1]

Microsoft 365 is signing with onmicrosoft.com

Microsoft 365 signs outgoing mail from a custom domain with the tenant’s onmicrosoft.com domain until DKIM signing with the custom domain is enabled. That signature is valid but does not align with the firm’s From domain, so DMARC then depends entirely on SPF.^[3] Enabling DKIM for the firm’s domain means publishing the two selector CNAME records Microsoft provides and switching signing on.^[3]

Forwarding

When a server forwards a message, that server is not listed in the original domain’s SPF record, so SPF fails.^[4] DKIM survives if the message is not changed, but mailing lists and security gateways that alter the subject or add a footer break the signature as well.^[1] For mail your own firm receives through such a service, Microsoft 365 can treat it as a trusted ARC sealer, which preserves the original authentication results.^[1]

The SPF record exceeds its limits

SPF evaluation may use no more than 10 DNS-querying terms, counting include, a, mx, ptr and exists together with redirect, and a record that needs more returns a permanent error rather than a pass.^[5] Each service added to the record usually brings its own include, which may contain several more. The fix is to remove services that no longer send, move bulk mail to subdomains with their own records, and rely on DKIM alignment where a provider supports it.

Strict alignment

With strict alignment, set by aspf=s or adkim=s, mail from a service using bounces.samplefirm.example no longer aligns with samplefirm.example. Relaxed alignment, the default, accepts it.^[1] Unless a firm has a specific reason for strict alignment, relaxed is the right setting.

Systems nobody thinks of as email

Monitoring alerts, backup reports, ticketing tools, door-entry systems and multifunction printers often send notifications from the firm’s domain. Nobody thinks of them as email the firm sends, so they are missed when the list of services is drawn up. They appear in aggregate reports like any other source, and need the same fix.

Finding failures before your clients do

A header shows one message. Aggregate reports show everything: receiving systems send summaries listing each sending IP address, how many messages it sent, and whether SPF and DKIM passed and aligned.^[1] The pattern to look for is authentication passing while alignment fails, the usual sign of a legitimate service set up with its own domain rather than yours.^[1]

Reports arrive as compressed XML attachments, often from dozens of receivers, which is why so many go unread. Reading them is less about tools than about matching every source to a service that someone at the firm can name.

After the fix

A fix is finished only when the next reports show that source passing. Aggregate reports usually arrive once a day and cover the day before, so allow a few days before judging a change, and look again after the next batch run of any service that sends in bulk, such as month-end billing.^[1]

A short diagnostic checklist

1. Take one failing message and note its smtp.mailfrom, header.d and header.from values.
2. If the first or second ends in your own domain, look for strict alignment or a mistake in the record.
3. If both belong to a provider, identify the service and ask it to sign with your domain.
4. If the envelope domain is yours but SPF fails, count the DNS lookups your SPF record needs.
5. If the message was forwarded, look for a list or gateway that changes messages on the way.
6. Record the fix, the date and the test that proved it worked.

The last step is the one most often skipped, and the one that saves most time later. Our sample record shows the format we leave with firms. To see what your domain publishes now, check it here. If you would rather not work through reports yourself, arrange a scope call and we will look at your domain’s published records before it.