My SPF check passes. Why does DMARC still fail?

Because DMARC checks alignment, not just the SPF result. SPF authenticates the envelope sender, which many transactional providers set to their own domain. The check passes for the provider and the domain does not match your From header, so the result does not count for DMARC unless DKIM aligns instead.

Is Easy DKIM enough for Amazon SES, or do I need a custom MAIL FROM domain?

Easy DKIM alone can pass DMARC, because SES signs with your domain and DKIM alignment is enough on its own. A custom MAIL FROM domain adds aligned SPF as a second path, which is what you want when a forwarder breaks the DKIM signature. It needs an MX record and an SPF TXT record on a subdomain of your verified identity.

Should transactional mail go on a subdomain or the root domain?

A subdomain in most cases. It separates the provider reputation from the mail your staff sends, it gives that provider its own SPF record and its own ten-lookup budget, and relaxed alignment means it still satisfies DMARC for a From header on the root domain.

SendGrid DMARC alignment, plus Mailgun and Amazon SES fixes

A ten person online store we would typically work with had a complaint that sounded like nothing. Order confirmations from the shop platform arrived fine. Password resets and payment receipts, sent through a transactional provider by the developer, landed in Gmail's spam folder about half the time. Someone had already checked SPF, SPF passed, and the conversation moved on to subject lines and images.

SPF passing is not the test. DMARC asks a second question, and transactional mail is where the answer usually goes wrong. It is also invisible from the outside: the record looks correct, the provider dashboard says the domain is verified, and the mail still fails.

Why transactional mail fails DMARC while SPF looks fine

DMARC does not care that a message passed SPF. It cares whether the domain that passed is the domain your reader sees. That is alignment, and RFC 7489 fits in one sentence: a message passes DMARC when SPF passes and the SPF domain aligns with the From header, or when DKIM passes and the DKIM domain aligns, or both. Only one of the two has to align.

Google says the same thing from the receiving side. Its sender guidelines require senders of more than 5,000 messages a day to Gmail accounts to publish SPF and DKIM and a DMARC record, and the From domain must align with either the SPF domain or the DKIM domain. Both mechanisms are required, one alignment is enough, and mail that fails can be rejected with a 5.7.26 error. Guidelines checked 28 September 2026.

Marketing platforms usually break this on the DKIM side, which is what the guide on Mailchimp, HubSpot and Klaviyo alignment covers. Transactional providers break it somewhere more specific: the envelope.

Envelope sender versus From header

Every message carries two sender addresses and most people only ever see one.

The envelope sender, also called the return path or MAIL FROM, is the address the sending server hands over during the SMTP conversation. Bounces go there. Nobody reads it. SPF authenticates this one.
The From header is the address in the message itself, the one the recipient sees and the one a phisher would want to forge. DMARC protects this one.

When both belong to you, SPF alignment happens by itself. When a provider sets the envelope to its own domain and leaves your name in the From header, SPF passes for the provider and aligns with nothing. The receiver then has exactly one chance left: DKIM. If DKIM signs with the provider's domain in the d= tag instead of yours, DMARC fails, and the report you eventually read shows a pass for SPF next to a fail for the message.

Alignment has two modes and the default is the forgiving one. Relaxed alignment, aspf=r and adkim=r, accepts any subdomain of the same organizational domain, so mail.example.com aligns with example.com. Strict alignment demands an exact match. Almost every fix below works because relaxed is the default.

From here, everything is one of two moves: make the envelope domain yours, or make the DKIM d= yours.

SendGrid: domain authentication does both, if you finish it

An API key is enough to send mail through SendGrid. It is not enough to pass DMARC. The step that matters is domain authentication, previously called sender authentication, and it is a set of CNAME records you publish on your own domain rather than TXT records you paste in.

With Automated Security switched on, SendGrid generates three CNAMEs: two for DKIM and one that creates a branded subdomain used for the return path. The DKIM records use the selectors s1 and s2, so you publish something shaped like this, with the target values taken from your own dashboard because they carry account-specific identifiers:

s1._domainkey.example.com.   CNAME   s1.domainkey.uNNNNNN.wlNNN.sendgrid.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.uNNNNNN.wlNNN.sendgrid.net.
emNNNN.example.com.          CNAME   uNNNNNN.wlNNN.sendgrid.net.

Two DKIM selectors rather than one is how SendGrid rotates keys without your involvement. Once verified, SendGrid signs your mail with your domain in d=, so DKIM aligns, and the branded subdomain puts the return path inside your organizational domain, so SPF aligns under relaxed mode as well. That is a message that passes DMARC on both mechanisms, which is where you want a receipt to be.

Two things go wrong at this step, repeatedly. The first is a DNS provider that refuses underscores in CNAME record names, which is common on older shared hosting panels. SendGrid's answer is to turn Automated Security off in the advanced settings and publish MX and TXT records manually instead, at the cost of handling key rotation yourself. The second is a provider that proxies records by default, Cloudflare being the usual example: a proxied authentication CNAME resolves to the proxy, not to SendGrid, so verification fails or stops working later. Every record in that set has to be DNS only.

Mailgun: the sending subdomain does most of the work

Mailgun asks you to verify a domain before it will send, and the verification exists for two reasons: to prove you own the name, and to authorise Mailgun's servers to send as it. Its documented setup is two TXT records, one for SPF and one for DKIM, and its guidance is to use a subdomain such as mg.example.com rather than the root domain, which keeps Mailgun's sending reputation separate from the mail your staff sends by hand.

mg.example.com.                 TXT   "v=spf1 include:mailgun.org ~all"
mx._domainkey.mg.example.com.   TXT   "k=rsa; p=MIGfMA0GCSq..."

That subdomain is the reason Mailgun is usually the easiest of the three. Mail leaves with the envelope sender on your sending domain and DKIM signed with d=mg.example.com, and under relaxed alignment both line up with a From header at example.com. Publish the SPF record on the subdomain, not on the root; a second SPF record at the root is not a fix, it is a permanent error, because a domain may publish exactly one.

Amazon SES: Easy DKIM aligns, the default MAIL FROM does not

SES is the one that catches out careful people, because the default configuration passes SPF and fails DMARC at the same time.

When you send through SES without configuring a MAIL FROM domain, the envelope sender is a subdomain of amazonses.com. That domain publishes a valid SPF record covering the SES infrastructure, so an SPF check passes cleanly. It just passes for Amazon. The envelope domain and your From domain do not match, so SPF alignment fails and DMARC can only be satisfied through DKIM.

Easy DKIM does satisfy it. SES publishes CNAME records that let it sign with your domain, so a verified identity with Easy DKIM enabled aligns on DKIM and passes DMARC. Plenty of small senders stop there and are fine. It is a single point of failure though: one broken DKIM record, one message modified by a forwarder, and there is no SPF alignment underneath to catch it.

The fix is a custom MAIL FROM domain, which is always a subdomain of the identity you verified. AWS documents two records on it: an MX record so that bounce feedback reaches SES, and a TXT record publishing SPF.

mail.example.com.   MX    10 feedback-smtp.us-east-1.amazonses.com.
mail.example.com.   TXT   "v=spf1 include:amazonses.com ~all"

Use the region you actually send from in the MX value. Because the custom MAIL FROM domain is a subdomain rather than an exact match, this only aligns under relaxed SPF policy, which is the default; a DMARC record carrying aspf=s will reject the whole arrangement. Set it up in each region and each account you send from, not just production, or the first invoice sent from a staging account will be the one that fails.

One domain, three senders, ten lookups

Most of the domains we audit are not sending through one provider. There is Google Workspace for the staff, a store platform for order mail, a transactional provider for receipts, and something nobody remembers enabling for the monthly newsletter. Each one wants an include: in the SPF record, and SPF allows ten DNS lookups per evaluation under RFC 7208 section 4.6.4. Exceed it and the result is PermError, which most receivers treat as no SPF at all.

Subdomains are the way out. A transactional provider on mail.example.com and a marketing platform on news.example.com each carry their own SPF record with their own lookup budget, while the root keeps only the senders that use the root, and relaxed alignment means all of them still satisfy DMARC for a From header at example.com. If you are already at the limit, the guide on getting under the SPF 10-lookup limit has the counting method.

Which policy belongs on each subdomain is covered in the post on DMARC subdomains and the sp tag.

What we check before and after the change

This is the order we work in on a client domain, and it is deliberately boring.

Inventory first, DNS second. Read two weeks of DMARC aggregate reports and list every source sending as the domain. Changing records before you know who sends is how invoices stop arriving.
Confirm the policy is still p=none while the work is in progress, with a rua address somebody reads. Nothing below is safe to do under enforcement.
Fix one provider at a time and send a real message after each one, to a mailbox on a different platform than the one you use daily.
Read the headers of that message rather than trusting a dashboard. The Authentication-Results line names the SPF domain and the DKIM d= value, which is the only place alignment is visible.
Watch one more reporting cycle before touching the policy, then ramp, quarantine before reject, with the third-party sender checklist done rather than assumed.

The failure we see most often is step three skipped: three providers fixed in one afternoon, one of them wrong, and no way to tell which without starting over.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, working with small and mid-sized companies across North America and Latin America in English and Spanish. Transactional mail is a normal way for this work to start: receipts going missing, one developer who owns the API key, and nobody who owns the DNS zone. We build the sender inventory from your own reports, fix each provider so it aligns on both mechanisms where the provider allows it, keep the SPF record inside its lookup budget, and then take the policy up to enforcement on a schedule instead of a hope.

If you want to look first, the DMARC report analyzer and the email troubleshooter are free and need no account. If you would rather hand it over, here is email deliverability consulting for small business and how we work. Bring a bounced receipt and its full headers to the call and we can usually name the cause on the screen.

Provider documentation for SendGrid, Mailgun and Amazon SES checked 28 September 2026.

Receipts that pass SPF and still fail DMARC: SendGrid, Mailgun and Amazon SES alignment