Inboxpass All guides

Guides

Why DMARC fails: alignment explained

25 October 2026

DMARC fails when neither SPF nor DKIM passes on a domain that matches the one in the From header. That match is called alignment. The usual cause is not a broken record. It is a service that passes SPF or DKIM on its own domain instead of yours, so the check passes but DMARC still fails. Find which identifier the failing mail carried, and you have found the fix.

The rule, in one paragraph

DMARC looks at the domain in the visible From header. RFC 9989, the current DMARC standard, says a message passes when at least one authenticated identifier aligns with that domain. There are two candidates:

If either one passes and its domain aligns with the From domain, DMARC passes. If neither does, DMARC fails, and the receiver applies your policy. A pass on a domain that does not align counts for nothing. RFC 9989 section 4.4.2 says only an SPF result that aligns with the From domain is enough.

What “aligned” means

The adkim and aspf tags in your DMARC record set the mode for each check. Both default to relaxed.

RFC 9989 section 4.4 notes that in practice nearly all domain owners have found relaxed alignment enough. Google’s DMARC troubleshooting page warns that strict alignment increases the chance that messages are rejected or sent to spam. If you have adkim=s or aspf=s in your record and nobody remembers why, consider going back to relaxed.

One change in RFC 9989: the organizational domain is now found by a DNS tree walk, querying _dmarc records up the name, instead of relying only on the Public Suffix List. For a normal domain like example.com the answer is the same.

The four common failures

1. SPF passes on the provider’s bounce domain

Most email services send with their own domain in the envelope sender so they can process bounces. SPF checks that domain, finds the service’s servers listed, and passes. But the From header says shop@example.com, and the envelope sender is something like bounces.provider.example. Different organizational domains, so SPF does not align.

Adding the provider’s include to your own SPF record does not change this, because SPF never checked your domain in the first place. You have two ways out:

2. DKIM passes, signed by the provider

Until you complete DKIM setup, many services sign with their own domain. The signature is valid, so DKIM passes, but d= is the provider’s domain. Microsoft 365 is a common example: its DKIM article says custom domains get no DKIM signing until you set it up, and only the onmicrosoft.com domain is signed automatically.

The fix is to publish the service’s DKIM records on your domain and turn on signing. Our guide to setting up DKIM walks through it.

3. A sender you forgot

The service is not in your SPF record and has no DKIM set up for your domain. Both checks fail or come back none. Google’s troubleshooting page lists this first under SPF: the message was sent by a server that is not in your SPF record. Common culprits are a website contact form, a booking tool, an invoicing app, or a scanner that sends email.

Fix it with DKIM for that service, an SPF include, or both. See how to create an SPF record for the SPF side.

4. The message changed after signing

DKIM fails if the signed headers or body change in transit. Google’s page calls out servers that modify messages, such as gateways that add a footer or rewrite links. Ask whoever runs that server to stop modifying mail, or have it sign after it makes changes. A bad or outdated DKIM key in DNS produces the same result, and Google suggests checking the published key against the one your service expects.

Forwarding and mailing lists

Some failures are not yours to fix. When a message is forwarded, the forwarding server sends it from its own IP, which is not in your SPF record. When a mailing list adds a subject tag or footer, the DKIM signature breaks. RFC 9989 section 7.4 says a reject policy can cause problems for these indirect flows, naming alumni forwarders, role-based aliases, and mailing lists.

An aligned DKIM signature is your best protection here, because plain forwarding does not usually alter the message, so the signature survives. SPF never survives a forward. Receivers also make allowances. Google’s sender FAQ says alignment is not required for forwarded and mailing-list messages under its bulk sender rules. In your aggregate reports, look for a reason of forwarded or mailing_list.

How to find which one you have

From a single message

Send a message through the service that is failing to a Gmail address you control. Open it, choose More, then Show original. In the Authentication-Results header, check three things:

spf=pass smtp.mailfrom=bounces.provider.example
dkim=pass header.d=provider.example
dmarc=fail header.from=example.com

That example is failure 1 and failure 2 together: both checks pass, on the provider’s domains, and neither matches example.com. If header.d= showed example.com, DMARC would pass. Google’s page also suggests pasting the full header into the Google Admin Toolbox Messageheader tool for a readable summary.

From your DMARC reports

Each row in an aggregate report has two sets of results. auth_results shows the raw SPF and DKIM checks with their domains. policy_evaluated shows the DMARC result after alignment. A row with a raw pass and an evaluated fail is an alignment problem. A row with a raw fail is an authentication problem. Our DMARC report guide explains each field.

From a bounce

When mail to Gmail is rejected by your policy, the bounce reads: 5.7.26 Unauthenticated email from example.com is not accepted due to domain’s DMARC policy. Google’s troubleshooting page uses that text. It means the message failed DMARC and your policy is quarantine or reject.

A short checklist

  1. Is there exactly one DMARC record at _dmarc.example.com, and does it start with v=DMARC1?
  2. Have SPF and DKIM been live for at least 48 hours? Google’s page asks for that before turning on DMARC.
  3. For each failing source: what is the envelope sender domain, and what is the DKIM d= domain?
  4. Does either share an organizational domain with the From address?
  5. If not, set up DKIM for your domain in that service.
  6. Is adkim or aspf set to strict without a reason?
  7. Is the failing mail forwarded or sent through a list? If so, an aligned DKIM signature is the protection, and some failures will remain.

Fix the failures for your own services before you raise the policy. On p=none, a failure costs nothing but a line in a report. On p=reject, it is a lost message.

Sources