SPF and DKIM Pass But DMARC Fails? Alignment Explained

The Problem: SPF Passes, DKIM Passes, Email Still Rejected

Your Postfix server is configured correctly. SPF checks out. DKIM signs properly. You send a test email to a Gmail address and watch the headers: Authentication-Results: mail.google.com; spf=pass; dkim=pass. Both authentication mechanisms show green. The email lands in the inbox, so you roll out your DMARC policy to p=reject and wait for everything to stay open.

Then the complaints start arriving.

Gmail is rejecting legitimate emails. The sending server is the same one that passed both SPF and DKIM during testing. Nothing in the configuration has changed. The only difference is volume and the full range of email types your system sends.

The issue is not your SPF record. The issue is not your DKIM key. The issue is alignment.

What DMARC Alignment Actually Means

DMARC is not a third authentication method. It is a policy layer that sits on top of SPF and DKIM and checks one specific thing: whether the domain that authenticated your email also matches the domain visible to the recipient in the email From header.

The From header is what users see as the sender address. It is the RFC5322.From field, not the bounce address (RFC5321.MailFrom). DMARC alignment compares the domain in this visible From address against the domain that passed SPF or DKIM.

Here is the exact sequence Gmail runs when it receives your email:

Check SPF: authenticate the sending server against the domain in the RFC5321.MailFrom (bounce address).

Check DKIM: verify the cryptographic signature against the domain in the d= tag of the DKIM signature.

Check alignment: does the RFC5322.From domain match the domain that passed SPF? Does it match the domain in the DKIM signature?

Apply policy: if alignment passes for at least one mechanism, the email passes DMARC. If alignment fails for both, the policy action (none, quarantine, reject) is applied.

This third step is what breaks most Postfix deployments. Passing SPF or DKIM is not enough on its own. The authenticated domain must also align with the From domain.

Relaxed vs. Strict Alignment

DMARC defines two alignment modes:

Relaxed alignment means the From domain and the authenticated domain share the same organizational domain. If your From header shows @example.com and your SPF check passes for mail.example.com, that counts as aligned under relaxed mode. The subdomain does not need to be an exact match, only within the same organizational boundary.

Strict alignment means the From domain must be an exact byte-for-byte match to the authenticated domain. If your From header shows @news.example.com and your SPF check passes for @example.com, that fails strict alignment. Only @example.com sending through @example.com passes.

Most organizations run in relaxed alignment mode. Strict alignment catches more spoofing but it also breaks legitimate email from third-party senders that use their own infrastructure on behalf of your domain.

If you are using a third-party email provider, a marketing platform, or any relay between your Postfix server and the recipient, alignment is the first thing you need to check.

Why Postfix DMARC Alignment Fails in Practice

Alignment failures on Postfix usually trace back to one of these causes:

Third-party mailing platforms. Services like Mailchimp, SendGrid, or ConvertKit send email where the From header shows your domain (@example.com) but the SPF check runs against the provider's server infrastructure and the DKIM signature is signed with the provider's domain. Neither authentication result aligns with @example.com. The email fails DMARC at the alignment step even though both SPF and DKIM technically pass.

Internal relay and forwarding servers. If your Postfix server acts as a relay for internal systems or corporate divisions that send from different subdomains, those emails may carry a From address of @sales.example.com while SPF authenticates against the relay's EHLO hostname of relay.internal.example.com. The domains do not match, alignment fails.

Legacy systems and line-of-business applications. Internal tools often hardcode From addresses or use system accounts that do not correspond to the sending infrastructure. A CRM sending transactional email from noreply@example.com but authenticating via a shared relay IP will fail alignment unless that relay is authorized for example.com in both SPF and DKIM.

Email forwarding chains. If a recipient's server forwards your email to another inbox, authentication results from intermediate hops can be lost or rewritten. This is a known failure mode and is one reason DMARC has the rd (rua) tag for reporting but does not guarantee deliverability through forwarding chains.

How to Read DMARC Aggregate Reports for Alignment Problems

Your DMARC aggregate reports contain the raw authentication results including alignment data. The rua tag in your DMARC record specifies where these reports are sent. Here is how to read them for alignment failures.

Each report entry includes a row per message or batch with:

source_ip: the sending server IP
count: number of messages
disposition: none, quarantine, or reject
dkim: pass or fail, and whether the result was aligned
spf: pass or fail, and whether the result was aligned

The alignment field is the critical piece. A DKIM result of pass (aligned) means the DKIM-signed domain matched the From domain. A result of pass (unaligned) means the signature validated but the signing domain did not match the From header. That unaligned pass still fails DMARC unless SPF also passes aligned.

Look specifically for entries where both dkim and spf show fail or show pass (unaligned). These are your alignment failures. High volumes of these against large receivers like Gmail mean your DMARC policy is rejecting legitimate email from a sending source you control.

The disposition field tells you what the receiver did with those messages. none means the message was accepted but logged. quarantine means it was marked as suspicious. reject means the message was dropped.

This is where a DMARC aggregate report service becomes practical rather than just technically interesting. Parsing these reports manually is slow and the data is dense. DMARCFlow processes the report stream continuously, groups results by sending source, and flags unaligned DKIM results as a separate signal from outright DKIM failures. When you see high unaligned pass rates from a known sending source, that is your warning to fix the integration before moving to p=reject.

How to Fix Alignment Failures in Postfix

Option 1: Cover your subdomains in DMARC.

If your From addresses use subdomains like @news.example.com or @offers.example.com, make sure your DMARC record explicitly covers those. Use the sp tag to set a policy for subdomains separately from the root domain:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; sp=quarantine; adkim=r; aspf=r;

This sets the policy for the root domain to reject while subdomains are quarantined, giving you a safety net while you fix alignment for subsidiary senders.

Option 2: Require DKIM signing from third-party senders.

If a marketing platform or CRM is sending on your behalf, require them to DKIM-sign using your domain (or a subdomain you control) rather than their default sender domain. Most major providers support custom DKIM keys. Setting this up means the DKIM signature in the email header carries your domain, which will align with your From header.

Option 3: Set up a transitional p=none phase.

Before moving to p=reject, run in p=none long enough to capture a complete sending cycle, ideally 30 days. This gives you full visibility into every sending source without blocking legitimate email. Many organizations skip this and roll straight to reject, which is how legitimate email gets dropped before they realize a third-party sender is misconfigured.

Option 4: Audit your sending sources against actual DMARC data.

Map every system that sends email from your domain. Cross-reference that list against your DMARC aggregate reports. Any source in the reports that is not in your inventory is either a misconfigured integration or a spoofing attempt. If a trusted third-party sender is causing alignment failures, the aggregate report will show it as unaligned DKIM results from a consistent IP range. Use that data to engage the vendor, not your firewall.

Preventing Alignment Failures Going Forward

Alignment failures are predictable if you know your sending infrastructure. Before you change your DMARC policy, do these three things:

Audit your sending sources. List every platform, system, and relay that sends email from your domain. Include marketing platforms, transactional email providers, internal applications, and any legacy systems. For each one, confirm whether it authenticates using your domain in SPF, DKIM, or both.

Match your From addresses to your authentication domains. If a system cannot send using your domain in both SPF and DKIM, either reconfigure it or exclude it from your main domain's DMARC policy by using a subdomain dedicated to that sending source.

Review reports monthly. Set up a recurring calendar reminder to review DMARC aggregate reports. Alignment problems that go unnoticed will cause intermittent email failures that are hard to diagnose after the fact. Consistent report review catches drift before it becomes a production problem.

## FAQ

Does passing SPF and DKIM mean my email will pass DMARC?

No. Passing SPF or DKIM is necessary but not sufficient. The authenticated domain must also align with the From domain. An email can pass SPF, pass DKIM, and still fail DMARC if the domains do not match.

What is the difference between relaxed and strict alignment?

Relaxed alignment allows subdomain variation as long as both domains share the same organizational domain. Strict alignment requires an exact match. Relaxed is the default and works for most organizations. Strict alignment catches more spoofing but breaks many legitimate third-party sending configurations.

Why do third-party email senders cause DMARC alignment failures?

Third-party senders authenticate using their own infrastructure, not yours. Their server IPs are not in your SPF record and their DKIM keys sign with their domain, not yours. When the From header shows your domain, alignment fails because neither the SPF domain nor the DKIM domain matches your From domain.

How do I check if my DMARC policy is rejecting legitimate email?

Check your DMARC aggregate reports for entries with disposition=reject or disposition=quarantine where the sending source is one you recognize and trust. Also look for entries where both DKIM and SPF show unaligned results. These indicate your policy is catching legitimate sending behavior that needs to be reconfigured before you can safely tighten the policy further.