What to Do When DMARC Reports Show Legitimate Source Failures

You set up DMARC monitoring. You are getting aggregate reports. The reports show failures. Now what?

This is where most DMARC implementations stall. Admins collect reports but do not know how to turn the data into actions. This guide covers what to do when DMARC reports show failures from legitimate sources.

What DMARC Aggregate Reports Actually Tell You

A DMARC aggregate report arrives as an XML file (or a human-readable summary from your tooling). It tells you which mail servers are sending email on behalf of your domain and whether those messages passed or failed authentication.

The key sections in any report:

Source IP - the server that sent the message

SPF result - pass or fail for the SPF check

DKIM result - pass or fail for the DKIM check

DMARC result - pass or fail for the alignment check

Message count - how many messages from this source

A failure does not automatically mean something is wrong. It means the authentication checks did not align, which can happen for legitimate reasons.

Legitimate Failure vs Spoofing - How to Tell the Difference

The first question when you see a failure is: is this my mail or someone pretending to be me?

Check the source IP. If it belongs to one of your known vendors, email providers, or internal systems, the failure is likely legitimate. If the IP is from an unknown source in a region you do not operate in, it is more likely spoofing.

Look at the volume. Spoofing campaigns typically send high volumes to many recipients. Legitimate failures from your own infrastructure tend to be lower volume and targeted.

Check whether the sending domain matches your From domain exactly. Spoofed mail often uses exact matches to look legitimate. DMARC alignment failures on mail you actually sent usually mean a configuration issue, not an attack.

Common Legitimate Failure Scenarios

#### Email Forwarding

When someone forwards your email to another provider, the forwarded copy often fails DMARC. This happens because the forwarding server becomes the new sender, and its IP does not match your SPF or DKIM.

The forwarding server rewrites the Return-Path to its own domain, breaking SPF alignment. DKIM may survive if the forwarding server does not modify the message body, but many forwarders do modify it, breaking DKIM as well.

If you control the forwarding setup, consider using a redirect rule instead of a traditional forward. If you do not control it, you may need to accept that forwarded mail from this recipient will fail DMARC.

#### Internal Mail Relays

If your organization uses an internal mail relay or email gateway, your DMARC reports may show failures for mail that passes through those servers. This typically happens when the relay does not preserve DKIM signatures or when the SPF check runs against the relay IP instead of the original sender.

The fix is usually to ensure your mail relay is included in your SPF record or is signing outbound mail with DKIM.

#### Third-Party Marketing Platforms

If you send email through Mailchimp, SendGrid, or any third-party platform, those messages will fail DMARC if the platform does not send on your behalf with proper authentication. Most major platforms handle this by sending from their own infrastructure with your domain in the From header but their IPs in the SPF.

The platform should be sending with DKIM signed by their infrastructure but with your domain in the aligned identity. If it is not, contact the platform to enable proper DMARC-compliant sending.

When to Update Your SPF Record

If your DMARC report shows failures from a source that should be authorized to send mail for your domain, the fix is usually to add that source to your SPF record.

Common cases:

You started using a new email provider (Google Workspace, Microsoft 365, etc.)

Your organization added a new mail server or gateway

A subsidiary or acquired company is sending on your behalf

To update SPF, add an include statement for the new sender. For example:


v=spf1 include:_spf.google.com include:sendgrid.net ~all

After updating SPF, wait for the TTL to expire before expecting changes to propagate. Monitor your DMARC reports for the next 24-48 hours to confirm the failures from that source stop.

When to Add DKIM for a New Sender

If a new sender is failing DKIM alignment and adding it to SPF does not help, you may need to add DKIM for that sender.

Many third-party platforms provide DKIM keys that you add to your DNS. This lets the platform sign mail on your behalf with your domain in the DKIM identity, which satisfies DMARC alignment.

If you manage your own DKIM and a new internal system needs to send signed mail, generate a new DKIM key pair, add the public key to DNS with a unique selector, and configure your mail server to sign with the corresponding private key.

How to Safely Progress Your DMARC Policy

Most domains start with p=none (monitor only). This lets you collect reports and fix legitimate failures before enforcing policy.

When to move to p=quarantine:

You have reviewed at least 2 weeks of aggregate reports

All legitimate sending sources are passing or are accounted for in your SPF/DKIM

You are comfortable with the risk of some legitimate mail going to spam

When to move to p=reject:

You have reviewed at least 30 days of reports at p=quarantine

All known legitimate sources are passing consistently

You have a process for monitoring and updating authentication when legitimate sources change

Moving to p=reject too early causes legitimate mail to bounce. Moving too late leaves your domain exposed to spoofing. The right timing depends on how dynamic your email infrastructure is.

Automating DMARC Report Analysis

Manual review of DMARC reports does not scale. If you are managing more than a few domains or receiving reports from multiple sources, parsing XML files by hand is not practical.

DMARCFlow automates the analysis step. It ingests your aggregate reports, categorizes failures by source, flags new sending infrastructure, and tracks your policy progression over time. This turns the "now what" question into a dashboard view instead of an XML scavenger hunt.

For MSPs managing DMARC across client portfolios, automated categorization and alerting means you can spot misconfigurations before they cause delivery problems or security incidents.

FAQ

Why do legitimate emails fail DMARC after I set it up?
This is normal on first setup. Your initial DMARC configuration rarely accounts for every legitimate sender. Review the failing source IPs against your known infrastructure, update SPF or add DKIM for the missing senders, then continue monitoring.

Can I ignore DMARC failures from my own domain?
No. Failures from your own infrastructure indicate misconfiguration. If your own mail servers are failing DMARC for your own domain, external receivers may also fail those messages or mark them as suspicious.

How long should I stay at p=none before moving to p=quarantine?
At minimum 2 weeks of aggregate reports, but longer if your email infrastructure changes frequently. You want to see at least one full cycle of any recurring senders (newsletter runs, billing systems, etc.) before enforcing policy.

What is the most common cause of legitimate DMARC failures?
Email forwarding is the most common. When messages are forwarded, the forwarding server becomes the sender and breaks SPF alignment. This affects B2B communications more than consumer email.

---

For ongoing DMARC monitoring that categorizes failures and tracks policy progression across all your domains, DMARCFlow provides automated analysis and alerting.