Fix “DMARC alignment failed”: SPF or DKIM pass, DMARC fails

What “alignment failed” means

SPF and DKIM each authenticate a domain, but neither checks the address people see:

• SPF checks the domain in the envelope sender: the SMTP MAIL FROM, also called the Return-Path, bounce address or envelope-from. It shows up as smtp.mailfrom= in the Authentication-Results header.
• DKIM checks the domain in the signature’s d= tag, shown as header.d=.

DMARC ties them to the From: address (the “Author Domain”). It passes only when SPF passes for a Return-Path domain that aligns with the From: domain, or a DKIM signature verifies for a d= domain that aligns with it. One aligned pass is enough. A service that sends with its own bounce domain and signs with its own domain passes SPF and DKIM for itself, and DMARC fails for you. RFC 9989 explains why: “any Domain Owner, even a bad actor, can publish an SPF record for its domain and send an email that will obtain an SPF ‘pass’ result” (§4.4.2), and “a message can bear a valid signature from any domain, even one used by a bad actor” (§4.4.1).

Relaxed and strict alignment

Your DMARC record picks the mode for each mechanism: aspf= for SPF and adkim= for DKIM, each r (relaxed) or s (strict). Both default to r. RFC 9989 defines them as:

• Relaxed (§3.2.10.1): “When the Author Domain (Section 3.2.2) has the same Organizational Domain (Section 3.2.14) as an Authenticated Identifier (Section 3.2.1), the two are said to be in relaxed alignment.”
• Strict (§3.2.10.2): “When the Author Domain (Section 3.2.2) is identical to an Authenticated Identifier (Section 3.2.1), the two are said to be in strict alignment.”

The original specification, RFC 7489 §3.1, says the same in its own words: in relaxed mode the two domains “must have the same Organizational Domain”, and in strict mode “only an exact DNS domain match is considered to produce Identifier Alignment.” Comparisons ignore case.

The Organizational Domain

For a typical domain the Organizational Domain is the registered name: example.com for bounces.example.com, example.co.uk for mail.example.co.uk. RFC 9989 (published May 2026, it obsoletes RFC 7489) finds it with a DNS tree walk: it looks up _dmarc records from the name upward, and the name with the fewest labels that has a DMARC record is the Organizational Domain, unless a psd= tag says otherwise (§4.10.2). Receivers that still follow RFC 7489 use a public suffix list instead. For almost every domain both give the same answer. They can differ when a subdomain has its own DMARC record and its parent has none: then, under the tree walk, the subdomain is its own Organizational Domain and the parent doesn’t align with it. Publishing a record on the parent domain fixes that. The checker below flags this case.

Sources: RFC 9989 §3.2.10, §4.4, §4.7 (adkim, aspf), §4.10.2 and Appendix B.1; RFC 7489 §3.1 (checked 2 October 2026).

Check alignment for your domain

Enter the domain in your From: address to see the DMARC record that applies and its alignment modes. To test a failing message, also enter its Return-Path domain (smtp.mailfrom) and DKIM signing domain (header.d) from the Authentication-Results header (where to find them). The lookups run in your browser against public DNS.

What this can and can’t tell you: it reads DNS right now, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails). It finds Organizational Domains with RFC 9989’s DNS tree walk, using a built-in list of common public suffixes rather than the full Public Suffix List, and notes where a receiver that still follows RFC 7489 might decide differently. It can’t see whether SPF or DKIM passed for a given message, or which DKIM selector a service uses. For the full A–F grade with SPF, DKIM, MTA-STS, BIMI and DNSSEC, use the DMARC checker.

Read the Authentication-Results header

Open the source of a failing message that reached any mailbox you control (Gmail: Show original; Outlook: File > Properties > Internet headers) and find Authentication-Results. The receiver adds it, so the exact layout varies, but the fields are standard (RFC 8601, with header.from registered for DMARC by RFC 9989 §9.1). A typical alignment failure looks like this:

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

If smtp.mailfrom is missing or is postmaster@ a server name, the message had an empty Return-Path, as bounces and auto-replies do. SPF then checks postmaster@ the server’s HELO name (RFC 7208 §2.4, cited in RFC 9989 §3.2.4), which rarely aligns with your From: domain, so such mail relies on DKIM.

Microsoft’s header puts the same fields on fewer lines and adds action= and compauth=; the 550 5.7.509 guide walks through one.

Read a DMARC aggregate report row

Aggregate reports (sent to the rua= address in your record) show every source that sent as your domain. Each <record> holds two different sets of results, and mixing them up is the most common way to misread a report:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>mailer.example.net</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example.net</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>mailer.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

So the pattern for an alignment failure is pass in auth_results, fail in policy_evaluated, and an auth_results domain that isn’t yours. The row above is 412 messages from one service whose SPF and DKIM both passed for mailer.example.net; the disposition is none only because the record is still at p=none. Under p=quarantine or p=reject those messages would go to spam or bounce. Look up source_ip and the auth_results domains to identify the service. A row whose auth_results fail as well, from an IP you don’t recognise, is more likely spoofing or forwarding than a misconfigured sender.

Source: RFC 9990 §3.1.1.8–3.1.1.13 (DMARC aggregate reporting, published May 2026; reports under RFC 7489 use the same element names) (checked 2 October 2026).

Fix it: make each sender align

Every service that sends with your From: address needs at least one aligned pass. Aim for aligned DKIM on every one: it doesn’t depend on the Return-Path and usually survives plain forwarding. Align SPF too where the service supports a custom Return-Path. The general steps:

1. Find the service from the header.d and smtp.mailfrom domains, or from source_ip in your aggregate reports.
2. Turn on its domain authentication (it may be called custom DKIM, sender authentication or domain verification) and publish the DNS records it gives you, so it signs with d= your domain or a subdomain of it.
3. If it offers a custom Return-Path or custom MAIL FROM, set one on a subdomain of yours and publish the records it asks for, so SPF passes for a domain that aligns.
4. Check a new message’s header: you want dkim=pass with header.d= your domain, and dmarc=pass. Or paste the domains into the checker above.

Microsoft 365

Microsoft’s DKIM guide says that for custom domains such as contoso.com, “Currently, no DKIM signing occurs for outbound mail from custom domains” until you configure it, so there is no DKIM signature that could align. In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, publish the selector1._domainkey and selector2._domainkey CNAMEs it shows for your domain, then enable signing. Microsoft’s guide: “DKIM passes DMARC validation only if the domain that DKIM signed the message and the domain in the From address align.” If the portal reports CnameMissing, check the two CNAMEs here. For SPF, Microsoft has you add include:spf.protection.outlook.com to your domain’s SPF record.

Google Workspace

In the Google Admin console, go to Menu > Apps > Google Workspace > Gmail > Authenticate email, generate a key (the default selector is google), publish the TXT record at google._domainkey.yourdomain.com, then click Start authentication. Mail is then signed with d= your domain.

SendGrid

Under Settings > Sender Authentication, authenticate your domain. With automated security on, SendGrid gives you a CNAME such as em1234.yourdomain.com for the Return-Path and SPF, and s1._domainkey and s2._domainkey CNAMEs for DKIM, so SPF and DKIM are checked against your domain instead of SendGrid’s. The em1234 Return-Path is a subdomain, so it aligns only under relaxed alignment. A “Use a custom return path” option lets you choose the label of that subdomain.

Mailchimp

Go to your profile > Account & billing > Domains, and click Start authentication next to your verified domain. Mailchimp asks for two DKIM CNAME records (named like k2._domainkey) and a DMARC TXT record. Its help page covers DKIM, not the Return-Path, so expect DMARC to pass on aligned DKIM.

Amazon SES

By default SES uses a subdomain of amazonses.com as the MAIL FROM domain, so SPF passes for Amazon and doesn’t align. Two fixes, and you can do both:

• Easy DKIM (Identities > your domain > Authentication > DKIM): once you publish the DNS records it shows, SES adds a DKIM signature for your domain to every message sent from that identity.
• Custom MAIL FROM domain (Identities > your domain > Custom MAIL FROM domain > Edit): pick a subdomain you don’t send or receive mail from, such as bounce.yourdomain.com, and publish an MX record 10 feedback-smtp.region.amazonses.com and a TXT record v=spf1 include:amazonses.com ~all on it. This aligns SPF only under relaxed alignment. If the MX record goes missing, SES falls back to amazonses.com unless you chose “Reject message” for MX failure.

Other services

Look for “domain authentication”, “custom DKIM”, “branded sending domain” or “custom return path” in the service’s settings. If it can’t sign with your domain or use your Return-Path, it can’t pass DMARC for your From: address. Either send it from a subdomain set up for it, or have it use a From: address on a domain it controls.

Check the alignment mode

If your record has aspf=s or adkim=s, only an exact match counts, so a Return-Path on bounce.yourdomain.com or a signature from mail.yourdomain.com fails for you@yourdomain.com. Most custom Return-Path setups (SendGrid’s em1234 subdomain, SES’s custom MAIL FROM) only align under relaxed mode. Unless you need strict, remove the tags: RFC 9989 notes that “nearly all Domain Owners have found relaxed alignment sufficient to meet their needs” (§4.4). The trade-off (§11.8): under relaxed alignment, anyone who controls the SPF or DKIM records of one of your subdomains can send mail that passes DMARC for your main domain, so don’t hand subdomains to parties you don’t trust.

Forwarding and mailing lists

When mail is forwarded, the new server isn’t in your SPF, so SPF fails or passes for the forwarder’s domain; a list that edits the subject or adds a footer also breaks DKIM. Aligned DKIM survives plain forwarding, which is one more reason to set it up. The rest is on the receiving side (ARC, trusted forwarders), and you’ll see these as failing rows from many IPs in your reports.

Before you raise the policy: make sure every legitimate source in your aggregate reports shows pass for at least one of policy_evaluated dkim or spf. Any that doesn’t will go to spam under p=quarantine and bounce under p=reject (at Microsoft, as 550 5.7.509).

Sources: Microsoft Learn, How to use DKIM for email in your custom domain and Set up SPF; Google Workspace Admin Help, Set up DKIM; Twilio SendGrid, How to set up domain authentication; Mailchimp, Set up email domain authentication; Amazon SES Developer Guide, Using a custom MAIL FROM domain, Easy DKIM and Complying with DMARC (checked 2 October 2026). Menu names change; follow the service’s current page if they differ.

FAQ

Why does DMARC fail when SPF passes?

SPF checks the Return-Path (envelope sender, smtp.mailfrom) domain, not the From: address. DMARC only counts an SPF pass when that domain aligns with the From: domain: under relaxed alignment it must share the From: domain’s Organizational Domain, under strict alignment (aspf=s) it must be identical. A sending service that uses its own bounce domain passes SPF for itself, which doesn’t count for you.

Why does DMARC fail when DKIM passes?

The signature that passed was made with a d= domain that doesn’t align with the From: domain, typically the sending service’s own domain. A message can carry several DKIM signatures, and DMARC passes if any valid one aligns (RFC 9989 §4.4.1). Set the service up to sign with your domain, usually called domain authentication or custom DKIM.

Do I need both SPF and DKIM to align?

No. One aligned pass is enough for DMARC. Aligning DKIM matters more, because an SPF pass doesn’t survive forwarding and a DKIM signature usually does when the message isn’t changed.

Should I use strict alignment (aspf=s, adkim=s)?

Usually not. Relaxed is the default, and RFC 9989 notes that nearly all domain owners have found it sufficient. Strict alignment makes bounce subdomains such as bounces.example.com and signatures from mail.example.com fail for From: addresses at example.com. Consider strict only if you can’t control who publishes SPF or DKIM records on your subdomains.

Checking many domains?

If you manage sending domains for clients or brands, Email Security Signals checks a whole list and returns one row per domain with the DMARC policy, SPF, DKIM selectors found and an A–F grade, ready to export as CSV. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.

Related: fixing the 550 5.7.509 DMARC reject bounce, fixing DKIM “no key for signature”, fixing “multiple DMARC records found” and fixing “multiple SPF records”.