Why Email Fails DMARC Alignment Even When SPF/DKIM Pass

You run an SPF check on your domain. It passes. You run a DKIM check. It passes too. Then you look at your DMARC aggregate report and see 12,650 failures with only 179 messages passing alignment. The numbers do not add up. SPF and DKIM are working, so why is DMARC failing for most of your mail?

The answer is that SPF and DKIM are authentication mechanisms. DMARC is an alignment and authentication mechanism. They measure different things, and passing one does not guarantee passing the other.

The Critical Difference Between Authentication and Alignment

SPF and DKIM answer the question: is this sending server authorized, and was the message signed?

DMARC answers a stricter question: was the message signed by a server authorized for the same domain that appears in the From address?

The From address is what recipients see when they read an email. It is the RFC 5322 From field, not the HELO/EHLO domain, not the bounce address, not the Return-Path. When a message is submitted through a third-party email service, the From address on the envelope might stay yourdomain.com, but the SPF check runs against the service's HELO/EHLO domain, not yours. If those do not match, DMARC fails.

The same problem happens with DKIM. An email service may DKIM-sign a message with its own domain, not yours. SPF passes because the service's IP is authorized for its own domain. DKIM passes because the message was signed by the service. But DMARC fails because neither the SPF domain nor the DKIM domain matches your From address domain.

The Six Most Common Causes of Bulk Alignment Failures

1. Third-party email service providers that do not DKIM-sign with your domain

Marketing platforms, CRM systems, helpdesk tools, and transactional email services often send from your From address but sign with their own DKIM domain. When you send a marketing campaign through such a service, SPF passes because the service's IP is authorized for its own domain. DKIM passes because the message was cryptographically signed. But DMARC alignment fails because your From address is yourdomain.com while the DKIM signature is from emailplatform.com.

The fix is to use custom DKIM. Most major email service providers let you add your own DKIM key pair and sign with your domain. If your ESP does not support this, you need a different ESP.

2. Forwarded mail that breaks the authentication chain

When a message is forwarded, the forwarder re-sends it from its own IP. That IP is not authorized for your From address domain, so SPF fails. The forwarder may also strip or modify DKIM headers. This is why forwarding to Gmail or Office 365 from an address with a strict DMARC policy often results in the forwarded copy being rejected or filtered.

ARC (Authenticated Received Chain) headers can help. They record the original authentication results before forwarding so that the final receiver can see the chain. Many large email providers now honor ARC, but it is not universally deployed, and some filtering systems still apply strict DMARC checks to forwarded mail.

3. Mailing list servers that rewrite From addresses

Traditional mailing list software often rewrites the From address to something like ListName via listdomain.com, which breaks alignment. Some lists preserve your From address but add List-ID headers. Others strip DKIM signatures entirely. The result is that messages from your domain to mailing list subscribers fail DMARC.

Modern mailing list software can preserve DKIM signatures and use List-ID headers that receivers can use for reputation. If you run your own mailing list, upgrade to software that handles this correctly. If you are subscribing to lists from a domain with strict DMARC, be aware that some of your list mail may fail alignment.

4. Subdomains that send without their own SPF record

A subdomain that has no SPF record inherits the organizational domain's SPF record. If the org domain has a p=reject policy and the subdomain sends mail from an IP not included in the org SPF record, SPF fails for that subdomain. Even if the subdomain SPF is correct, if the subdomain's From address is sub.yourdomain.com and the DKIM is signed for yourdomain.com, alignment can fail depending on the policy.

The fix is to add a dedicated SPF record for each sending subdomain. Do not assume that a subdomain is covered by the organizational domain's SPF record.

5. Multiple ESPs with inconsistent DKIM setup

If you use one ESP for transactional email, another for marketing, and a third for internal notifications, each must be configured to DKIM-sign with your domain. If only one of them is correctly set up, mail from the other two fails DMARC alignment even though SPF passes for each.

Before moving to p=reject, audit every service that sends email from your domain. Test each one individually by examining the authentication results headers in the delivered message.

6. Legacy relay servers and SMTP forwarding in your own infrastructure

Internal mail relayers, SMTP proxies, and archiving appliances can break alignment. They receive mail from an authorized internal IP, then re-inject it for delivery. The re-injected message carries the original From address but is submitted from the relayer's IP. If the relayer is not in your SPF record or if it strips DKIM, alignment fails.

This is common in healthcare, financial services, and other regulated industries where email archiving is mandatory. The relayers are often invisible to senders because they sit between the mail client and the internet.

How to Read Your DMARC Aggregate Report to Find the Culprit

Your DMARC aggregate report arrives as an XML file, usually daily, from each receiver that processes mail from your domain. Parsing it manually is painful. The report tells you:

Which IPs are sending mail purporting to be from your domain
Whether the message passed SPF, DKIM, and DMARC alignment
Which organizations are sending you reports
What percentage of your mail is being checked (the pct tag in your DMARC record, which controls what fraction of total mail is subjected to DMARC checks rather than all of it)

Look first at the failure-to-pass ratio. If you are seeing 12,650 failures and 179 passes from the same set of sending IPs, those IPs are likely your known senders, and the problem is alignment, not a spoofing attack. If you see failures from IPs you do not recognize, that is a different problem and potentially an attack.

For each failing IP, ask three questions: Do we recognize this IP? Is it authorized to send from our domain? Does our From address domain match the domain this IP is authorized for or signing as?

DMARCFlow aggregate reports break down alignment failures by source IP and domain, making it straightforward to identify which third-party senders or forwarding rules are causing bulk DMARC failures rather than guessing from raw aggregate data.

How to Fix Bulk Alignment Failures Step by Step

1. Collect 30 days of aggregate reports. One day is not enough. You want a complete picture of all your sending sources.

2. List every IP address that appears in the reports. Classify each one as: internal mail server, known third-party ESP, unknown external source.

3. For known third-party ESPs, check whether they are DKIM-signing with your domain. If they are not, set up custom DKIM with the provider. If they do not support custom DKIM, find a provider that does.

4. For forwarding sources, check whether the failures are from legitimate forwarding (a business partner, a mailing list). If so, consider enabling ARC and adjusting your policy to p=quarantine instead of p=reject while the forwarding relationship is resolved.

5. For mailing lists, audit the list software. Upgrade if necessary. Add the list's domain to your SPF record if the list re-sends from its own infrastructure.

6. For subdomains, add dedicated SPF records and ensure each subdomain has its own DKIM configuration if it sends independently.

7. Re-run aggregate reports weekly during the fix process. Track whether the failure volume is decreasing. If it is not, you have missed a sending source.

8. When failure volume stabilizes at an acceptable level, move to p=quarantine for a period before moving to p=reject.

How to Prevent Bulk Alignment Failures Before They Happen

The best time to audit your sending sources is before you set a strict DMARC policy. If you are starting from p=none, use that monitoring period to find every legitimate sender that needs to be fixed.

Before moving to p=reject, require all third-party senders to DKIM-sign with your domain as a contract requirement. Do not accept "SPF passes" as sufficient. SPF-only setup breaks DMARC alignment for any sender whose HELO domain differs from your From domain.

Set up subdomain sending policies separately from your organizational domain policy. A subdomain that sends marketing mail should not be governed by the same p=reject policy that protects your primary domain until it has been audited.

FAQ

Q: SPF passes for all my mail. Why does DMARC still fail?

A: SPF passing means the sending IP is authorized for the HELO/EHLO domain. DMARC alignment checks whether the From domain matches that HELO/EHLO domain. If your From address is from yourdomain.com but your SPF record authorizes mailserver ESP's domain, DMARC fails for anything that does not also align with yourdomain.com. SPF and DMARC are measuring different things.

Q: DKIM is signed correctly. Why are messages still failing DMARC?

A: DKIM must sign the From domain or a parent domain that aligns with it. If your ESP DKIM-signs with ESPdomain.com but your From address is from yourdomain.com, the DKIM signature is valid but alignment fails. The DKIM domain must match or be a parent of the RFC 5322 From domain.

Q: My aggregate report shows failures from my own mail server. Should I be worried?

A: Yes. If your own mail server is generating DMARC alignment failures, something in your infrastructure is breaking alignment. Possible causes include a forwarding rule you did not know about, a distribution list, an internal relay, or a co-location email gateway. Every internal failure source deserves investigation.

Q: Can I just move to p=none and ignore the failures?

A: p=none means you get reports but take no action. This is a reasonable temporary state during migration or when you have legitimate senders you cannot immediately fix, such as some forwarding relationships. But p=none also means attackers can send spoofed email from your domain without any enforcement. The goal should always be to fix alignment issues and move to p=quarantine or p=reject, not to stay in monitoring mode indefinitely.

Q: How do I know if the failures are from attackers or from my own misconfigured senders?

A: The source IP tells you. If the failures come from IPs you recognize as your own ESPs, your own mail servers, or known forwarding services, the problem is misconfiguration. If failures come from IPs you do not recognize, that is more likely spoofing attempts. DMARC aggregate reports include source IP addresses specifically so you can make this distinction.