What to Do About DMARC Failures from Legitimate Senders

You check your DMARC report and see 12,000 SPF failures from an IP range you do not immediately recognize. Your first reaction: possible spoofing attack. Your second reaction after checking your sender inventory: that is the IP range for the marketing automation platform you deployed six months ago.

This is the reality of DMARC monitoring in any organization with more than a handful of email senders. Legitimate infrastructure misconfigurations show up in your reports constantly, and they are easy to mistake for spoofing attacks if you do not have a process for triaging them. The challenge is not finding the failures. The challenge is knowing which ones matter and what to do about each one.

This guide gives you a repeatable process for working through DMARC failure reports from legitimate sources.

Step 1: Identify the Failing Source

Open your DMARC aggregate report and look for the source IP that is failing. You want three things:

The source IP address
The From domain being used
The SPF and DKIM results for that source

If you are using DMARC monitoring software, it surfaces this automatically. If you are reading raw XML or a plain-text report, you will need to cross-reference the source IP with your known sender list.

The From domain is the key field. If the failing source is sending email with a From domain that does not match your organizational domain, that is a different problem than if the domains are aligned but the authentication check is still failing.

Step 2: Classify the Failure Type

Once you have the source IP and From domain, you can usually classify the failure into one of four categories.

SPF Alignment Failure

SPF authenticates the Return-Path domain (also called the envelope-from), not the From header. DMARC alignment requires the From domain to match the Return-Path domain for SPF to pass alignment. If a legitimate sender is using a different domain in the From header than in the envelope, the SPF check itself might pass, but DMARC alignment will fail.

This is one of the most common causes of false positives in DMARC reports. It shows up as "SPF pass, alignment fail" in your report.

DKIM Alignment Failure

Similar to SPF, DKIM validates a signature on a domain that you control. If the DKIM selector is published on a subdomain or a third-party domain that does not match your From domain, alignment fails. This is common when organizations use third-party email platforms that sign with their own domain rather than the customer's domain.

Look for "DKIM pass, alignment fail" in your reports. That is a strong signal the sender is using a third-party DKIM key.

Third-Party Sender Not Aligned

Marketing automation platforms, CRM tools, support desk software, and legacy systems often send email on behalf of your domain but authenticate using their own infrastructure. They have their own SPF record, their own DKIM keys, and their own sending domains. When they send as you, they fail DMARC alignment because they are not using your authentication records.

This is the most common failure mode for organizations that have many SaaS tools integrated with their email.

Subdomain Sending Without Its Own Records

If a subdomain is sending email but does not have its own SPF record, it inherits the parent domain's SPF. That inheritance works for SPF but not for DMARC alignment, which requires the From domain to match exactly. A subdomain that sends through a different mail system than the parent domain will fail alignment even if SPF technically passes.

Step 3: Match the Failure Type to a Fix

Each failure type has a specific resolution path.

For SPF Alignment Failures

Check whether the sender is using a different From domain than your primary domain. If they are, you have two options:

Ask the sender to use your canonical From domain for outbound mail
Adjust your DMARC policy to use relaxed alignment (adkim=r) instead of strict alignment (the default). Relaxed alignment allows subdomains to match the parent domain.

Relaxed alignment is the industry default for a reason. Most organizations do not need strict alignment unless they have specific anti-spoofing requirements that demand it.

For DKIM Alignment Failures

The fix depends on whether the third party can sign with your domain. Many major SaaS email platforms now support custom DKIM signing -- meaning they will publish the DKIM record under your domain instead of their own. Check whether your vendor supports this. If they do, the DKIM signature will then align with your From domain and DMARC will pass.

If custom DKIM signing is not available, you need to decide whether to accept the alignment failure or route that category of email through a different path that does align.

For Third-Party Senders Not Aligned

This is the most actionable failure type. You have three paths:

1. Whitelist the source IP in your DMARC reporting -- if the IP is known and trusted, you can add it to your sender inventory so your monitoring tool flags it as expected rather than suspicious.
2. Configure the third party to send using your domain -- many platforms let you configure a custom sending domain with your SPF and DKIM records.
3. Use a routing layer -- some organizations route all third-party sending through a proxy that applies their own SPF and DKIM, ensuring alignment.

For Subdomain Sending Failures

If a subdomain is sending mail through an external provider, make sure that subdomain has its own SPF record and that the provider is included in it. The subdomain also needs to be covered by your DMARC record either explicitly or via the wildcard (*.domain.com).

Step 4: Verify the Fix

After making changes, watch your DMARC reports for at least 48 hours. Authentication results can take time to propagate in aggregate reports because they are sent daily or weekly depending on your configuration.

Look for the failing source IP to stop appearing, or to appear with passing results instead of failing ones. If the same failures persist, double-check whether the third-party sender has multiple IPs or a sending infrastructure that rotates source IPs.

When to Escalate or Accept Risk

Not every failure is worth fixing immediately. If a failing source is low volume, only affects internal notifications, or belongs to a vendor that cannot change their configuration, you may need to accept the risk while monitoring it.

Accepting a failure does not mean ignoring it. Log it, track it, and re-evaluate it when the vendor updates their platform or when your DMARC policy matures.

If you are seeing failures from a source you do not recognize at all -- an IP address with no corresponding sender in your inventory -- that is a different category. Treat unknown sources as potential spoofing until proven otherwise, even if the volume is low.

How DMARC Monitoring Tools Help

Manual DMARC report analysis is time-consuming. A mid-sized organization can see thousands of records per day across SPF, DKIM, and alignment results. Triage requires matching source IPs to known senders, classifying failure types, and tracking whether fixes are working -- and doing it again every time a new SaaS tool is added to the stack.

This is where DMARCFlow earns its place. Rather than presenting raw XML dumps or flat tables, DMARCFlow matches source IPs against your known sender inventory automatically and flags which failures are from legitimate senders versus sources that have no corresponding entry in your records. That distinction alone saves hours of manual investigation.

DMARCFlow also groups failures by root cause -- SPF alignment fail, DKIM alignment fail, third-party sender not aligned -- so you can address them in batches rather than one IP at a time. After you make a configuration change, it tracks whether the failures stop, which tells you whether the fix actually worked.

The goal is not just to collect reports. It is to turn DMARC data into a remediation workflow that your team can act on without reading XML.

FAQ

What causes SPF to pass but DMARC alignment to fail?
SPF validates the Return-Path domain, not the From header. DMARC alignment requires the From domain to match the Return-Path domain (for SPF alignment) or the DKIM signing domain (for DKIM alignment). A sender can pass SPF but fail alignment if they are using a different domain in the From header than in the envelope.

How do I fix DKIM failures from third-party senders?
Check whether your third-party email platform supports custom DKIM signing, where they sign with a key published under your domain. If that is not available, consider routing that category of mail through a service that can sign with your domain, or accept the alignment failure if the risk is low and the volume is manageable.

Should I move to p=reject if I have legitimate senders failing DMARC?
No. Moving to p=reject while you have unaddressed legitimate failures means those legitimate emails will be rejected. Fix all known legitimate failures first, then move to p=reject. Use p=quarantine as a stepping stone if needed.

How long does it take for DMARC fixes to show in reports?
DMARC aggregate reports are typically sent daily. Changes to DNS records (SPF, DKIM, DMARC) can take up to 48 hours to propagate fully. Give any authentication changes at least 48 to 72 hours before concluding that a fix has not worked.