DMARC fail with SPF and DKIM passing: fixing "not aligned"

This is one of the most confusing results an MSP sees in a DMARC report or a message header: spf=pass, dkim=pass, dmarc=fail. It doesn't mean the receiver got it wrong. DMARC doesn't ask whether SPF or DKIM passed. It asks whether they passed for the domain in the From: header. That's identifier alignment, and it's the whole point of DMARC.

The rule in one sentence

RFC 9989 §5.3.5: "If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check." The Author Domain is the domain in the visible From: header. The Authenticated Identifiers are:

• SPF: the envelope sender (RFC 5321 MAIL FROM) domain, if SPF passed for it. RFC 9989 §4.4.2 says DMARC "relies solely on SPF validation of the MAIL FROM identity," so a HELO pass doesn't count.
• DKIM: the d= domain of any DKIM signature that verified (§4.4.1). One aligned valid signature is enough, even when the message carries others.

Only one aligned pass is needed. SPF and DKIM don't both have to align.

Relaxed vs strict alignment

RFC 9989 defines two modes, set per identifier with aspf and adkim. Both default to r:

• Relaxed (r): the two domains have the same Organizational Domain (§3.2.10.1). bounce.client.com aligns with client.com.
• Strict (s): the two domains are identical (§3.2.10.2). bounce.client.com doesn't align with client.com.

RFC 9989 notes that "nearly all Domain Owners have found relaxed alignment sufficient." If a client's record sets aspf=s or adkim=s and it fails for subdomain-based senders, strict alignment is often the whole problem.

Reading the header

Ask for a sample message and open the Authentication-Results header that the receiving system added (RFC 8601). A typical "not aligned" case looks like this:

```

Authentication-Results: mx.example.net;

spf=pass smtp.mailfrom=bounces.vendor.net;

dkim=pass header.d=vendor.net;

dmarc=fail header.from=client.com

```

Compare the domains. smtp.mailfrom is the SPF identifier, header.d is the DKIM signing domain, and header.from is what DMARC evaluates. Here both passes belong to vendor.net, and neither shares the Organizational Domain client.com, so DMARC fails.

The usual causes, and the fix for each

1. A SaaS sender using its own bounce domain and DKIM key. This is the most common cause. The vendor authenticates as itself, not as the client. Examples from vendor documentation:

• Amazon SES uses a subdomain of amazonses.com as the default MAIL FROM.
• Salesforce rewrites the envelope sender to a bnc.salesforce.com address when bounce management is on.
• Mailchimp Transactional (Mandrill) says the return-path "by default… points to mandrillapp.com." A custom return-path subdomain (a CNAME to mandrillapp.com) is optional.

Fix: turn on the vendor's custom-domain DKIM, so d= is the client's domain. Optionally, add a custom MAIL FROM or Return-Path subdomain so SPF aligns too.

2. DKIM is set up, but for the wrong domain. A key for client.com doesn't help mail sent as client.co.uk. Salesforce documents this exact case: DKIM alignment fails when the key's Domain field doesn't match the From: domain. Fix: set up a key for each From: domain the vendor sends from.

3. Strict alignment on a subdomain-based setup. SendGrid's return-path, Postmark's custom Return-Path and Amazon's custom MAIL FROM are all subdomains. Postmark says outright that its setup "cannot meet the requirement aspf=s." Fix: use relaxed alignment unless there's a specific reason not to.

4. Forwarding or mailing lists. A forwarder changes the sending IP, so SPF fails or passes only for the forwarder's domain. A list that edits the subject or adds a footer can break DKIM. RFC 9989 §7.4 covers this at length. Fix: on the sending side, make sure mail carries an aligned DKIM signature, which usually survives plain forwarding. List-related failures are a known limitation, and RFC 9989 advises domains whose users post to mailing lists not to publish p=reject.

5. Spoofing. Sometimes DMARC is working exactly as designed. Someone else's server sent mail using the client's From: domain and passed SPF and DKIM only for their own domain. Don't "fix" this by adding their servers.

What not to do

• Don't add the vendor's include to the apex SPF record and call it fixed. If the vendor's envelope sender is its own domain, the apex record is never checked for that mail, and alignment doesn't change.
• Don't drop the policy back to p=none across the board because of one unaligned tool. Fix the tool. If you need time, send that tool from a subdomain with its own DMARC record.
• Don't publish a second DMARC record to "test." RFC 9989 §4.10 says that if multiple DMARC records are returned for one name, "they are all discarded," which leaves the domain with no policy at all. Use t=y on the existing record if you want testing behavior.

Finding the senders that fail

Single messages tell you about one case. DMARC aggregate reports (RFC 9990) tell you about all of them. Each row shows a sending IP, a message count, the SPF and DKIM domains and results, and the DMARC outcome. Group the failing rows by sending source, identify each service, and work through the fixes above one vendor at a time. Remember that receivers only send aggregate reports if the record has an rua tag. RFC 9989 says that without it, receivers "MUST NOT generate aggregate feedback reports."

Check the client's DMARC record now

Run the free DMARC checker →

It shows whether the domain is monitor-only or enforcing, parses p= and rua, and gives the next DNS record to publish. Check for an rua address before you go hunting for unaligned senders.

Founding Partner: $1,999, one time. Track every client's DMARC posture and the senders still failing alignment, with weekly rescans and alerts. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →