GuidesAuthentication

DMARC fails although SPF and DKIM pass

Both checks say pass, and DMARC still says fail. The cause is a domain that does not match your From address. One test email shows which one, and the fix is a setting at whoever sends the mail.

Updated 5 October 20269 min read

In short

DMARC passes only if SPF or DKIM passes for the domain in your From address. A pass for your provider's domain does not count.
Open a sent message in Gmail with Show original and compare smtp.mailfrom, header.i and header.from in the Authentication-Results header.
Fix DKIM first: turn on signing with your own domain at every service that sends for you. A DKIM signature survives forwarding, SPF does not.
A subdomain is close enough by default. If your DMARC record contains adkim=s or aspf=s, it is not.
Warmup does not repair alignment. Warmup emails are sent through your mailbox and fail with it.

DMARC does not ask whether SPF and DKIM passed. It asks whether one of them passed for the domain in your From address. If SPF passed for your provider's bounce domain and DKIM passed for your provider's signing domain, both lines say “pass” and DMARC still says “fail”. The fix is at the sender: have it sign with your domain, or use a bounce address on your domain. One of the two is enough.

The word for this match is alignment. It is the part of DMARC that a DNS checker cannot see. Whether your mail is aligned only shows in a message that was really sent. This page shows how to read one.

Three domains travel with every email

An email carries your domain in up to three places. Each check looks at a different one.

Where	Also called	Who looks at it
The From line your reader sees	Header From, `header.from`	DMARC. It is the yardstick for the other two.
The Return-Path	Envelope sender, MAIL FROM, bounce address, `smtp.mailfrom`	SPF. It checks whether the sending server is allowed to use this domain.
The `d=` value in the DKIM-Signature header	Signing domain, `header.d` or `header.i`	DKIM. It checks whether the signature of this domain is valid.

SPF (RFC 7208) and DKIM (RFC 6376) each answer a narrow question, and neither question mentions your From line. A newsletter service can pass SPF for its own bounce domain and sign with its own key, and the message can still claim to come from you. DMARC closes that gap. RFC 9989, the DMARC standard since May 2026, accepts a result only if the domain behind it matches the From domain, and gives the reason for DKIM in one sentence:

DMARC requires that Identifier Alignment is applied to the DKIM-Authenticated Identifier because a message can bear a valid signature from any domain, even one used by a bad actor.

The same holds for SPF, since anyone can publish an SPF record for a domain they own. So the rule is: DMARC passes if SPF passes and its domain aligns, or if DKIM passes and its domain aligns.

Find the mismatch in one real message

You need one email sent the way your real mail is sent, and a Gmail address to receive it.

Send a message from the mailbox or tool in question to a Gmail address you can open.
Open it in Gmail on a computer. Next to Reply, click More, then Show original. Google describes the same steps in Trace an email with its full header.
Find the header Authentication-Results, in which the receiving server notes the outcome of its checks (RFC 8601). Compare three values: the domain after smtp.mailfrom=, the domain after header.i=@ (some receivers write header.d=), and the domain after header.from=.

This is the pattern of a message that passes SPF and DKIM and fails DMARC. The header is shortened and uses example domains:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Read it from the bottom. The From domain is example.com. SPF passed, but for send.vendor-mail.example. DKIM passed, but the signature belongs to vendor-mail.example. Neither is example.com, so nothing vouches for the name in the From line.

After the service has been set up to sign with your domain, the same message looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF still points at the vendor. That is fine. DKIM now matches, and one aligned pass is all DMARC needs.

How close is close enough: relaxed and strict

The two domains do not have to be identical. By default, alignment is relaxed: it is enough that both belong to the same registered domain, which the standard calls the organizational domain. Strict alignment demands an exact match. You choose with the tags adkim for DKIM and aspf for SPF in your DMARC record.

SPF or DKIM passed for	From domain	Relaxed (default)	Strict
`example.com`	`example.com`	Aligned	Aligned
`mail.example.com`	`example.com`	Aligned	Not aligned
`example.com`	`news.example.com`	Aligned	Not aligned
`vendor-mail.example`	`example.com`	Not aligned	Not aligned

The standard notes that “nearly all Domain Owners have found relaxed alignment sufficient to meet their needs”. Check your own record all the same. The example record at the top of Google's Set up DMARC page ends in adkim=s; aspf=s, so a record copied from there is strict. If yours has those two tags and a tool sends from a subdomain, remove them. Google itself warns on that page that strict alignment “can result in messages from associated subdomains to be rejected or sent to spam”.

Where the mismatch usually comes from

A service that sends from its own servers

Newsletter platforms, CRMs, invoicing tools and help desks send your mail from their infrastructure. Until you connect your domain, they typically use a bounce address on their domain and sign with their own key. Amazon's documentation says plainly why SPF alignment is rare here: the Return-Path “is used for bounces and complaints that the provider (SES) tracks using an address they own” (Amazon SES). The setting that fixes it has a different name at every service, and it ends in a few DNS records on your side.

Service	Before you connect your domain	The setting to look for
Twilio SendGrid	Mail is shown as sent “via sendgrid.net”.	Domain authentication: CNAME records for a bounce subdomain and two DKIM keys.
Amazon SES	The Return-Path is a subdomain of `amazonses.com`.	Easy DKIM for the signature, and a custom MAIL FROM domain for SPF.
Mailchimp	The domain is verified but not authenticated.	Email domain authentication: two CNAME records for DKIM.

These are the vendors' own descriptions as of October 2026. Other services work along the same lines. Search their help for “authenticate domain”, “custom DKIM” or “branded sending domain”.

Your mailbox provider signs with its own domain, or not at all

With a mailbox on your own domain, the Return-Path is normally your own address, so SPF aligns as soon as your SPF record lists the provider. The value after smtp.mailfrom= tells you. DKIM is the part that needs a switch.

Google Workspace. Until you turn on DKIM for your domain, Google has signed with one of its own domains. An earlier version of Google's help page said that Gmail then signs “with this default DKIM domain key: d=*.gappssmtp.com”. The current page no longer names the domain, so check your own header: a header.i that ends in gappssmtp.com means your key is not active. Generate it in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, add the TXT record it shows you, then click Start authentication (Set up DKIM).
Microsoft 365. Microsoft's documentation, updated in August 2026, states: “Currently, no DKIM signing occurs for outbound mail from custom domains”. You publish two CNAME records and enable signing in the Defender portal (How to use DKIM for email in your custom domain).

The record you add for a DKIM key always sits below _domainkey, under a name the provider chooses. For Google Workspace it looks like this, with the key shortened:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

A tool that connects to your mailbox and sends through it adds no signature of its own. Mail from such a tool looks exactly like mail you write by hand, so the fix is at the mailbox provider and not in the tool.

The message was forwarded

When a recipient forwards your mail automatically, it arrives from a server your SPF record does not list. SPF fails or passes for the forwarder's domain. A DKIM signature survives the trip as long as nobody changes the message. Mailing lists that add a footer or a subject tag break the signature as well. You cannot repair this from your side. Google's sender FAQ says that for Gmail “DMARC alignment isn’t required for forwarded or mailing list messages”. It is the reason to have DKIM aligned and not to rely on SPF alone.

It is not your mail

If your DMARC reports show failures from servers you have never used, somebody may be sending with your address. Those messages are supposed to fail. Nothing needs fixing, and they are the argument for a stricter policy later.

Fix DKIM first, then SPF

Either one gets you a pass. DKIM is the better one to have, because it travels with the message. The M3AAWG best practices put it as a rule: “Sign all outbound mail with a DKIM key that aligns with the domain of the RFC5322.From header.” RFC 9989 recommends using both.

List everything that sends as your domain. Mailboxes, the newsletter tool, the CRM, invoices, the contact form on your website. Your DMARC reports name the ones you forgot.
Test each one with the header check above and note which of the two domains is not yours.
Turn on signing with your domain wherever header.i shows another name, and publish the records the service gives you. Choose a 2048-bit key if your DNS host accepts it. Gmail requires at least 1024 bits and recommends 2048.
Set a custom bounce domain where the service offers one, on a subdomain such as bounce.example.com. That aligns SPF as well.
Send the test again and look for dmarc=pass. DNS changes can take a while. Google allows up to 48 hours for a new DKIM key to start working.

What does not work is adding the vendor to your own records. An include: for the vendor in your SPF record changes nothing if the Return-Path is on the vendor's domain, because SPF looks up the record of that domain and not yours. A DMARC record cannot list trusted third parties either. The standard says there is “no generally accepted mechanism” for that.

If the header shows dmarc=pass and the message still lands in spam, authentication is no longer the cause. SPF, DKIM and DMARC pass, but the email still lands in spam picks up from there.

What a failing DMARC costs while your policy is p=none

With p=none you ask receivers to take no action on a failure, so nothing is rejected because of your policy. It still counts against you in two ways.

Bulk sender rules. Gmail, Yahoo and Outlook.com require aligned mail from bulk senders, which for Gmail and Outlook.com means from 5,000 messages a day. Google's sender FAQ lists the temporary error 4.7.32 for mail whose From header “isn’t aligned with either the authenticated SPF or DKIM organizational domain”, and names “Temporary or Permanent Failure codes, or spam foldering” as the consequence.
It blocks the next step. As soon as you move to p=quarantine or p=reject, every unaligned message of your own is to be treated as spam or refused. At Gmail the bounce reads “Unauthenticated email from domain-name is not accepted due to domain's DMARC policy”, error 5.7.26 (Troubleshoot DMARC issues).

If you have no DMARC record at all, start with the record to add. It also turns on the reports that show alignment for all your senders at once.

What warmup can and cannot do here

A warmup does not repair alignment. WarmupBay connects to your mailbox and sends from it, so its warmup emails are sent and signed by your provider exactly like the mail you write yourself. If your mailbox fails DMARC, they fail with it. Fix the records first.

WarmupBay helps with the part before and the part after. When you connect a mailbox, it checks SPF, DKIM and DMARC for the domain, and it stops the warmup if they are still missing after 72 hours. Once they are in place, your mailbox exchanges a few emails a day with others in a shared pool, and the dashboard shows where they landed: inbox, a Gmail tab, or spam, separately for Google and for other providers. It does not test mail from your newsletter tool or CRM, because that never passes through your mailbox, and it cannot yet connect Microsoft 365 or Outlook.com mailboxes. It is free for 10 warmup emails a day. Connect your mailbox when the header shows dmarc=pass.

Questions people ask

SPF passes and is aligned, DKIM is not aligned. Is that enough?

For DMARC, yes. One aligned pass is enough. It stops being enough when a recipient forwards your mail, because SPF then no longer matches. Google also writes in its sender FAQ that alignment with both SPF and DKIM will likely become a requirement, so set up DKIM for your domain anyway.

Why does DMARC fail for some recipients and pass for others?

Because the mail reaches them by different routes or from different senders. A recipient who forwards to another mailbox, or a mailing list, changes what SPF and sometimes DKIM see. It can also be one of several sending services that is not set up yet. Aggregate reports list the results by sending server and show which case it is.

Does the Reply-To address play a part in DMARC?

No. DMARC uses only the domain in the From header. The Reply-To address, the display name and the Sender header are not part of the check.

How do I see alignment problems without opening headers?

In DMARC aggregate reports. Each record has a policy_evaluated block with a dkim and an spf result, which are the results after the alignment test. The auth_results block below it shows the raw results and the domains they were for. A raw pass next to an evaluated fail is exactly the case on this page. You get the reports by adding a rua address to your DMARC record.

The header says dkim=fail or dkim=neutral. Is that the same problem?

No. Then the signature itself did not verify, which is a different fault. If the text reads body hash did not verify, Google's troubleshooting page names the cause: the message was changed after it was signed, for example by a gateway that adds a footer. Alignment is about a signature that is valid but belongs to another domain.

Do I need a separate DKIM key for every service that sends for me?

In practice, yes. Each service signs with its own key and publishes it under its own selector name below _domainkey on your domain, so several keys sit side by side without conflict. This is different from SPF, where a domain may have only one record.