Why DMARC fails: a practical guide to email alignment

You set up SPF. You set up DKIM. You published a DMARC record. Every online checker shows green.

Then you open a real email and see this: spf=pass, dkim=pass, dmarc=fail.

How can two passes add up to a fail? The answer is one word: alignment. It is the most common reason DMARC fails, and the least explained.

This guide shows you how to read an email’s headers, find the domains that DMARC really compares, and fix the exact setting in your email platform or DNS. We use one simple example all the way through, so you can follow it step by step with your own email open next to it.

DMARC pass  =  (SPF pass  AND  SPF aligned)
               OR
               (DKIM pass AND  DKIM aligned)

DMARC pass  =  (SPF pass  AND  SPF aligned)
               OR
               (DKIM pass AND  DKIM aligned)

The one rule behind every DMARC result

DMARC doesn’t need both SPF and DKIM. One path that passes and aligns is enough. Microsoft says it plainly in its DMARC setup guide: “A message passes DMARC if one or both of the described SPF or DKIM checks pass.”

Here are the four situations you will meet most often:

Having a DMARC record in DNS doesn’t mean your emails pass. The record only states your policy. Each email is judged on its own. If you need a refresher on what SPF, DKIM and DMARC are, read SPF, DKIM and DMARC explained first. This guide is about why the result fails, and how to fix it.

The domains DMARC actually compares

An email carries several “sender” addresses. Most people only see one. DMARC compares two or three of them:

Our example for the rest of this guide

A store sends its newsletter through an email platform. Here are the three important lines:

From: Example Store <newsletter@example.com>
Return-Path: <bounce-4821@mailer.example.net>
DKIM-Signature: v=1; a=rsa-sha256; d=mailer.example.net; s=s1; ...

From: Example Store <[email protected]m>
Return-Path: <[email protected]t>
DKIM-Signature: v=1; a=rsa-sha256; d=mailer.example.net; s=s1; ...

The reader sees example.com. But SPF checks mailer.example.net (the Return-Path), and DKIM was signed by mailer.example.net too. Both checks can pass. Neither is about example.com. So DMARC fails.

Relaxed vs. strict alignment

“Aligned” can mean two things. Your DMARC record chooses, separately for SPF and DKIM:

• Relaxed (r): the two domains belong to the same organization. bounce.example.com and example.com are aligned.
• Strict (s): the two domains must be exactly the same.

The tag aspf sets the mode for SPF. The tag adkim sets it for DKIM. If you don’t write them, both are relaxed by default.

Should you use strict? Usually not. The new DMARC standard, RFC 9989 (published May 2026, replacing RFC 7489), says: “In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs.” Strict mostly creates new failures, for example when your platform uses a bounce subdomain.

The common reasons DMARC fails

First, separate two kinds of problems. They look the same in a report, but the fixes are different:

• Authentication failure: SPF or DKIM itself failed. Something is broken.
• Alignment failure: SPF or DKIM passed, but for another domain. Nothing is broken. It’s just set up for the wrong domain.

If DMARC passes but your emails still land in spam, the cause is elsewhere. Use the spam troubleshooting guide for that.

How to read email headers and find the problem

This is the most useful skill in this guide. It takes five minutes, and it gives you the real answer, not a guess.

1. Send a real test email from the platform that has the problem, to a Gmail or Outlook address you can open.
2. Open the full headers. In Gmail, open the email, click the three dots (⋮) and choose Show original. In Outlook, use your app’s “view message source” or “message details” option, or paste the headers into Microsoft’s Message Header Analyzer.
3. Find the From domain. This is your reference.
4. Find the SPF result and the domain after smtp.mailfrom=.
5. Find the DKIM result and the domain after header.d= (the d= value).
6. Find the DMARC result and the domain after header.from=.
7. Compare. Is the SPF or DKIM domain the same as the From domain (strict), or in the same organization (relaxed)?

Try it: find the problem

Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=mailer.example.net;
    dkim=pass header.d=mailer.example.net;
    dmarc=fail header.from=example.com

Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=mailer.example.net;
    dkim=pass header.d=mailer.example.net;
    dmarc=fail header.from=example.com

The answer: both checks passed, but for mailer.example.net. The From domain is example.com. They belong to different organizations, so neither path is aligned. Nothing is broken. The platform simply isn’t using your domain yet.

Three details that confuse people

• Compare d=, not s=. The selector (s=, for example s1 or google) only tells the receiver where to find the key. Gmail headers often show [email protected]. That’s a related value, but the alignment check uses the d= domain.
• There may be several Authentication-Results headers. Every server on the way can add one. Trust the one added by the receiving mailbox provider (usually the top one, named after the receiver, like mx.google.com). Ignore any that came with the email from outside.
• Microsoft adds compauth. It’s Microsoft’s combined verdict, based on the From domain. See the table below.

These meanings come from Microsoft’s anti-spam message headers reference. If you don’t want to read raw headers at all, paste them into Google’s Admin Toolbox Messageheader tool.

How to fix SPF alignment

SPF alignment means the Return-Path (MAIL FROM) domain must be yours. Here’s how:

1. Look at the real Return-Path in a test email before you touch SPF. Is it your domain or the platform’s?
2. Find the “custom return-path” or “custom MAIL FROM” setting in your platform. Pick a subdomain you don’t use for anything else, like bounce.example.com.
3. Add exactly the DNS records the platform asks for (usually a CNAME, or an MX plus an SPF TXT record on that subdomain).
4. Check the alignment mode. A subdomain like bounce.example.com aligns with example.com under relaxed SPF alignment, not under aspf=s.
5. Send a new test email and confirm smtp.mailfrom now shows your subdomain.

Where the setting is, on common platforms

If your platform can’t align SPF, that’s fine. One aligned DKIM signature is enough for DMARC. Twilio SendGrid’s own DMARC troubleshooting article puts it simply: “In order for DMARC to pass, either SPF, DKIM, or both must align.”

How to fix DKIM alignment

DKIM alignment is the most reliable fix, because DKIM usually survives forwarding (section 08).

1. Turn on DKIM signing with your own domain in your platform. It’s often called “domain authentication”.
2. Publish the records exactly as the platform shows them (usually CNAME or TXT records under _domainkey).
3. Confirm it’s active. Many platforms need you to click “verify” or “start authentication” after DNS is published.
4. Send a new test email and check that d= now shows example.com (or a subdomain of it).
5. Check it passes, not just that it’s there: dkim=pass header.d=example.com.

Two more things to check:

• Key length: Gmail requires a DKIM key of at least 1024 bits and recommends 2048 bits.
• Changes after signing: if something edits the email after it’s signed (a footer added by a gateway, a rewritten link), the body hash breaks and you’ll see dkim=fail (body hash did not verify).

Why forwarding and mailing lists cause problems

Sometimes your direct emails pass, but the same email fails after someone forwards it. Here’s why:

• SPF breaks on forwarding because the forwarding server isn’t in your SPF record.
• DKIM usually survives, because the signature travels with the email, as long as nobody changes the signed parts.
• Mailing lists often change the subject or add a footer. Many now rewrite the From address to their own domain to avoid DMARC failures.

DMARC failure vs. policy vs. DNS problems

Three different things are often mixed up:

• p=none doesn’t make anything pass. It only asks receivers not to act on failures. The email still fails, and Microsoft may still mark it as an implicit failure (compauth reason 001).
• Changing reject to none doesn’t fix alignment. It hides the symptom and removes your protection.
• Two DMARC records on the same name are as bad as none. Receivers discard them both.
• A DNS error is not an alignment failure. With a temporary or permanent lookup error, the email can’t be judged as pass or fail. Fix DNS first.
• Receivers have the final word. They can still filter an email that passes DMARC, or deliver one that fails.

Use DMARC reports to find other failing senders

One test email checks one path. Your domain may have five or ten. DMARC aggregate reports show all of them. Add a rua=mailto:... address to your DMARC record, and mailbox providers like Google and Microsoft send you a daily summary (an XML file) of who sent email as your domain.

The two parts of a report that tell the real story

Each row in a report has two sets of results. The difference between them is exactly the alignment problem. The new reporting standard, RFC 9990, defines them:

• auth_results: raw SPF and DKIM results, “uninterpreted with respect to DMARC”.
• policy_evaluated: “the results of applying the DMARC policy”. Its spf and dkim values are the alignment results.

<row>
  <source_ip>203.0.113.25</source_ip>
  <count>1840</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>   <!-- not aligned -->
    <spf>fail</spf>    <!-- not aligned -->
  </policy_evaluated>
</row>
<auth_results>
  <dkim><domain>mailer.example.net</domain><result>pass</result></dkim>
  <spf><domain>mailer.example.net</domain><result>pass</result></spf>
</auth_results>

<row>
  <source_ip>203.0.113.25</source_ip>
  <count>1840</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>   <!-- not aligned -->
    <spf>fail</spf>    <!-- not aligned -->
  </policy_evaluated>
</row>
<auth_results>
  <dkim><domain>mailer.example.net</domain><result>pass</result></dkim>
  <spf><domain>mailer.example.net</domain><result>pass</result></spf>
</auth_results>

Read it like this: pass in auth_results, fail in policy_evaluated = an alignment problem. Here, 1,840 emails passed for mailer.example.net but weren’t aligned with example.com. It’s one of your own services, set up halfway.

Sort every source into one of three groups

Verify the fix across every sending service

A green DNS checker only shows that your records exist. It doesn’t show that real emails pass. Google’s DMARC troubleshooting guide also starts from the message headers, not from DNS. So finish with real emails:

• I sent a test email fromeveryservice that uses my domain: newsletter, CRM, website forms, store notifications, helpdesk, invoices.
• Each test shows the From domain I expect.
• Each test has at least one path that passesandaligns (SPF or DKIM).
• Each test showsdmarc=passin the receiver’s Authentication-Results.
• The platform shows my DNS records as verified and my custom domain as active.
• I wait a few days and check the next DMARC reports for anything still failing.
• Only then do I consider a stricter policy.

DMARC pass is only one part of deliverability

A DMARC pass proves one thing: your domain allowed this email. That’s important. But it says nothing about the people you’re sending to. RFC 9989 is clear that a pass doesn’t make an email “safe or desirable” on its own.

You can have perfect alignment and still hurt your reputation by sending to addresses that bounce. So once DMARC passes, the next step before a campaign is validating email addresses on your list.

Where MailVexa fits

MetaLogic MailVexa is email verification software for Windows and Mac. It doesn’t touch your DMARC setup, and it doesn’t send email. It prepares the list you send to:

• Layered checks for every address: format, disposable domains, free providers, MX, SMTP and mailbox, catch-all, and the recipient domain’s SPF/DMARC records.
• Clear groups with reasons: Valid, Risky, Invalid and Unknown, so you know which addresses to send to and which to hold back.
• An exclude list for past bounces and unsubscribes, so they never come back in a new import.
• Local processing: your list stays on your computer. Checks run at about 10,000 emails an hour with one proxy.
• Exports your platform can use: CSV or XLSX, with your own columns kept.

For the full routine, see how to clean your email list before sending a campaign. When you’re ready, download MailVexa and verify your first 2,000 addresses free.

Common questions

Why does DMARC fail when SPF and DKIM both pass?

Because they passed for another domain, usually your email platform’s. DMARC needs at least one of them to pass for a domain that aligns with your From address.

Does DMARC require both SPF and DKIM to pass?

No. One check that passes and aligns is enough. Using both is still recommended, so one can cover for the other.

Does changing Reply-To fix DMARC alignment?

No. DMARC ignores Reply-To and the display name. Only the domain in the From address counts.

Can subdomains pass DMARC alignment?

Yes. With relaxed alignment (the default), bounce.example.com aligns with example.com. With strict alignment (aspf=s or adkim=s), the domains must match exactly.

Does p=none fix a DMARC failure?

No. p=none only asks receivers not to act on failures. The emails still fail. You fix the failure by aligning SPF or DKIM.

Why does DMARC fail only for forwarded emails?

Forwarding usually breaks SPF, because a new server sends the email. If your DKIM signature is aligned and the content isn’t changed, DMARC can still pass.

Why do some emails pass while others from the same domain fail?

They come from different services. Your newsletter platform may be set up, while your CRM, helpdesk or store sends without your DKIM. Test each service, and check your DMARC reports.

Can an email pass DMARC and still go to spam?

Yes. DMARC only proves the sender is real. Spam filters also look at reputation, complaints, bounces, content and engagement.

Sources

Standards

• RFC 9989: DMARC (May 2026, replaces RFC 7489). Alignment modes, defaults, DNS Tree Walk, tags.
• RFC 9990: DMARC aggregate reporting. policy_evaluated and auth_results.
• RFC 8617: ARC (Experimental).

Mailbox providers

• Gmail: Email sender guidelines. From alignment, DKIM key length.
• Google Workspace: Troubleshoot DMARC issues
• Google Admin Toolbox: Messageheader
• Microsoft: Set up DMARC
• Microsoft: Anti-spam message headers. compauth reason codes.
• Microsoft: Message Header Analyzer

Email platforms

• Amazon SES: Custom MAIL FROM domain. Records and behavior on MX failure.
• Twilio SendGrid: Troubleshooting DMARC failures

Product

• MetaLogic MailVexa. Desktop email verification software for Windows and macOS.

We build MetaLogic MailVexa, so weigh our description of it accordingly. We have no commercial relationship with any email platform or mailbox provider mentioned in this guide. Standards and platform settings were checked in October 2026. Platform menus change often, so follow the exact records your own platform shows you.