Why SPF “Fails” in DMARC Reports with Amazon WorkMail

You open your DMARC report and see something confusing:

• dkim=pass
• spf=fail in the DMARC policy result
• …and yet SPF for some other domain actually passed

In many cases the pattern looks like this (values anonymised):

<header_from>company-domain.example</header_from>
<spf>
  <domain>region-mail-out.amznsmtp.example</domain>
  <result>pass</result>
</spf>
<policy_evaluated>
  <spf>fail</spf>
</policy_evaluated>
            

If you are using Amazon WorkMail, this situation is very common. WorkMail sends through Amazon SES under the hood – and that has implications for DMARC SPF alignment.

SPF Is Passing – DMARC Alignment Is Failing

First important point: your SPF record is usually not “broken”. What fails is the DMARC alignment check.

DMARC looks at three domains (all anonymised here):

• Visible From: user@company-domain.example (header_from)
• MAIL FROM / Return-Path: b1234@region-mail-out.amznsmtp.example
• DKIM d= domain: d=company-domain.example

SPF is evaluated for the MAIL FROM domain, for example:

SPF domain: region-mail-out.amznsmtp.example
SPF result: pass
            

DMARC then asks: “Does this SPF domain align with the visible From: domain?”

• If your DMARC record uses aspf=s (strict), the domain must be exactly the same.
• If it uses aspf=r (relaxed), a subdomain is allowed.

With WorkMail’s default behaviour, the MAIL FROM is an Amazon-controlled domain like region-mail-out.amznsmtp.example. That will never equal company-domain.example, so SPF alignment fails – even though the underlying SPF check succeeded.

Why Amazon WorkMail Uses an Amazon MAIL FROM Domain

Amazon WorkMail is built on top of Amazon SES. When you send an email through WorkMail, SES is handling the actual delivery.

Out of the box, SES uses an internal sending identity similar to this (again anonymised):

MAIL FROM: b1234@region-mail-out.amznsmtp.example
Return-Path: <b1234@region-mail-out.amznsmtp.example>
            

This is technically fine – SPF passes because that SES sending infrastructure is authorised. But for DMARC, it creates a mismatch:

• From: user@company-domain.example
• SPF domain: region-mail-out.amznsmtp.example

Result: SPF alignment = fail. Meanwhile, DKIM (signed with d=company-domain.example) typically passes and is aligned – so DMARC, overall, still passes.

Two Options When You See SPF Fail in DMARC Reports

Once you understand this, you basically have two strategies:

Option 1: Accept DKIM-Only Alignment

In many cases, you can simply accept that:

• SPF alignment fails (because of the Amazon MAIL FROM domain)
• DKIM alignment passes (because DKIM uses your own domain)
• DMARC passes because at least one of SPF or DKIM is aligned

Your DMARC reports will keep showing lines where <spf>fail</spf> appears in <policy_evaluated>, but these messages are still delivered because DKIM alignment saves them.

Option 2: Fix SPF Alignment with a Custom MAIL FROM Domain

If you want “all green” in DMARC and cleaner reporting, you can configure a custom MAIL FROM domain. Instead of using an Amazon domain, SES (and therefore WorkMail) will send using a MAIL FROM under your own zone, for example:

MAIL FROM: bounce@bounce.company-domain.example
SPF domain: bounce.company-domain.example
            

The idea is simple:

• You choose a subdomain such as bounce.company-domain.example
• You add the MX and SPF TXT records SES gives you for that subdomain
• You update your DMARC policy to use relaxed SPF alignment (aspf=r)

Now DMARC sees that bounce.company-domain.example is a subdomain of company-domain.example. With relaxed alignment, SPF passes and aligns.

Conceptual Setup: Custom MAIL FROM for WorkMail

The exact console labels may change over time, but the workflow is always the same:

1. Open the SES console in the same region where WorkMail is configured.
2. Select your sending domain (for example company-domain.example).
3. Enable a custom MAIL FROM domain, such as bounce.company-domain.example.
4. Add the DNS records SES shows you:
   • One MX record for bounce.company-domain.example
   • One TXT record, typically an SPF like v=spf1 include:amazonses.example -all
5. Wait for verification until the custom MAIL FROM is active.
6. Adjust your DMARC record if needed, for example:

   v=DMARC1; p=reject; adkim=s; aspf=r; rua=mailto:dmarc-reports@redacted-domain.example; fo=1
                       

All domains above are anonymised on purpose, but the pattern is exactly what you will see in a real environment.

What You Should Not Do

There is one tempting “quick fix” that is almost always a bad idea: changing the visible From address to an Amazon-owned domain just to make SPF alignment happy.

That would mean your customers suddenly receive emails from something like notifications@region-mail-out.amznsmtp.example instead of your own brand. You lose brand recognition, your reply handling becomes messy, and you no longer have DMARC protection on your own domain.

The right way is almost always:

• Keep sending as @company-domain.example
• Let DKIM sign with d=company-domain.example
• Optionally fix SPF alignment via a custom MAIL FROM subdomain

How DMARCFlow Helps You Untangle WorkMail & SPF

When you first look at raw XML DMARC reports, the “SPF fail” lines are easy to misunderstand. Was the record wrong? Was the IP blocked? Or is it just an alignment nuance?

DMARCFlow helps you in three concrete ways:

• Separate views for SPF checks vs. SPF alignment – so you instantly see whether a failure is DNS related or an alignment side-effect.
• Provider-aware explanations for Amazon WorkMail, SES, and other platforms that use shared sending domains.
• Actionable recommendations for DMARC, SPF, and DKIM, including custom MAIL FROM guidance if it actually makes sense for your case.

Final Thoughts

If you are using Amazon WorkMail and see SPF failures in your DMARC reports, you are not alone. In most cases, your SPF record is fine – it is the alignment with your From domain that fails.

You can either live happily with DKIM-only alignment or go the extra mile and configure a custom MAIL FROM domain so that SPF aligns as well. The key is understanding what the reports actually tell you, instead of blindly trying random SPF changes.

If you want to shortcut the guesswork, run your domain through DMARCFlow and let us decode the reports for you.