Your monitoring dashboard shows SPF passing on every outbound message. Your DMARC aggregate report still lists failures for the same domain, and some of that mail is landing in spam or getting rejected outright. This gap between an SPF pass and a DMARC failure is one of the most common points of confusion in email authentication, and chasing the wrong record wastes days while deliverability keeps dropping.
DMARC alignment is the rule causing it: the domain that SPF or DKIM actually authenticated must match the domain shown in the message's From: header, and a plain SPF pass on a different domain does not satisfy that rule. SPF and DKIM each check one thing on their own. DMARC adds a second check on top of both of them. Skip that second check when you're debugging, and a message can pass SPF while still failing DMARC completely.
What Is DMARC Alignment?
DMARC alignment compares the domain a receiving server just authenticated against the domain the recipient actually sees. SPF authenticates the envelope-from, which is the Return-Path address used for bounces, not the visible sender. DKIM authenticates whatever domain sits in its own d= tag, independent of the From: header too.
DMARC then asks one more question: does that authenticated domain match the visible From: header domain? If neither SPF nor DKIM aligns, DMARC fails the message, no matter what SPF or DKIM reported on their own.
| Alignment mode | Policy tag | Requirement | Example |
|---|---|---|---|
| Relaxed (default) | aspf=r / adkim=r | Organizational domain must match; subdomains are allowed | mail.example.com aligns with example.com |
| Strict | aspf=s / adkim=s | Exact domain must match; no subdomain difference allowed | mail.example.com does not align with example.com |
Why Does SPF Pass While DMARC Still Fails?
SPF alignment checks the envelope-from domain, not the domain in the visible From: header — the two are separate fields, and receiving servers only show your recipient the second one. A message can pass SPF outright and still fail DMARC if the authenticated domain and the From: header domain do not match under the policy's alignment mode.
Three situations cause this most often. Forwarding rewrites the envelope-from to the forwarding service's own domain, so SPF now authenticates the forwarder, not you — DMARC alignment breaks even though the original send was clean. A third-party sender, like an invoicing tool or a CRM, sends using your From: address but its own SPF domain; if DKIM is not configured for that sender under your domain, nothing aligns. Strict mode on a subdomain send is the third: mail from mail.example.com will not align with a From: header of example.com once aspf=s is set, even though the same setup passes fine under relaxed mode.
A fourth cause shows up less often but confuses people the most: shared sending platforms. If a CRM, help desk, or billing tool sends on your behalf and you added its servers to your SPF record, SPF passes because the platform's IP is listed there. But that platform's outgoing envelope-from is frequently its own domain, not yours, so the SPF pass authenticates the platform, not your organization. DMARC checks alignment against the domain the recipient sees in From:, so an SPF pass tied to someone else's envelope-from never counts toward alignment, no matter how many of that platform's IPs you whitelist.
How Do You Fix an SPF Alignment Failure?
Work from the raw aggregate report, not the summary dashboard, since the summary hides which specific domain broke.
- Pull the raw DMARC aggregate report and find the row where SPF shows a pass but the overall DMARC disposition still shows fail.
- Read the header_from and envelope_from domains listed in that row and compare them directly.
- If they differ, that mismatch is your alignment break, not a DNS syntax problem.
- Configure DKIM signing for that sending source instead of depending on SPF, since DKIM alignment survives forwarding and most third-party relays.
- For a third-party sender, ask them for a custom DKIM selector on your domain rather than trying to add their servers to your SPF record.
- Re-check the next aggregate report cycle, roughly 24 to 48 hours later, to confirm the same rows now show a DMARC pass.
Should You Set Strict or Relaxed Alignment?
Relaxed alignment is the sane default for almost every business domain. It tolerates subdomain sending — marketing.example.com, mail.example.com, notifications.example.com — without breaking, which matters the moment you add a second sending source. Strict alignment only makes sense when you tightly control every sending domain yourself and want to block even your own subdomains from authenticating on your behalf. Most domains that turn on strict mode without planning for it end up locking out a legitimate internal sender by accident.
A useful way to decide: list every domain and subdomain that currently sends mail on your behalf, including any marketing platform, support desk, or invoicing tool. If that list only ever uses your exact root domain, strict alignment costs you nothing extra. If it includes even one subdomain, staying relaxed is the safer starting point, and you can tighten to strict later once every source is confirmed aligned.
DKIM Alignment Works the Same Way
DKIM alignment survives most forwarding because the cryptographic signature travels with the message headers and body, while SPF alignment breaks the moment a forwarding server rewrites the envelope-from. This is why a domain with SPF-only authentication is far more fragile than one with DKIM signing in place: any hop that changes the return path silently costs you SPF alignment, but DKIM keeps working as long as the message content is not modified in transit.
This is also why relying on SPF alone is a fragile authentication setup even when it looks fine day to day. A domain that only publishes SPF will pass DMARC for direct sends and fail it the moment any recipient forwards a message, any mailing list relays it, or any third-party tool sends on your behalf without matching your envelope-from. Publishing DKIM alongside SPF gives DMARC a second, more durable path to alignment, so one broken hop does not take down authentication for the whole message.
Reading raw aggregate XML by hand to find which single row breaks alignment is exactly the kind of check that gets missed once you are sending real daily volume across more than one domain. EmailControl checks SPF, DKIM, and DMARC on every scheduled run and reports the header_from and envelope_from mismatch directly instead of leaving you to parse the raw report — see the FAQ for how each check works.
Fixing alignment sounds like it requires re-architecting how your organization sends mail, but it usually does not. Most alignment failures trace back to one third-party sender or one forwarding rule, not your core mail server. Adding a DKIM selector for that one source, or correcting that one forwarding rule, closes the gap without touching how the rest of your team sends email. The DMARC specification, RFC 7489, defines both alignment modes in full if you need the exact wording for a vendor conversation.
Start Checking Alignment, Not Just Pass or Fail
A pass/fail glance at SPF and DKIM tells you half the story. Alignment is the other half, and it is the half that actually decides whether DMARC accepts the message. Add your domain to EmailControl and the next scheduled check reports SPF, DKIM, and DMARC alignment together, with no DNS changes required to get the first report.