What to Do When DMARC Monitoring Shows Failures You Cannot Fix

undefinedYour DMARC monitoring is working. You have 47 failure reports in your inbox this morning. The problem is that most of them come from sources you cannot fix: a Gmail user who forwarded a message to their work account, a mailing list that wraps your emails, a third-party platform sending on your behalf from a server you do not own.

This is not a crisis. This is normal. And it is exactly the situation where most DMARC monitoring tools reveal their limits -- they show you the problem without telling you what to do about it. DMARCFlow was built around this specific gap: not just surfacing authentication failures, but helping you classify them and decide what action is actually warranted.

This post explains why some DMARC failures cannot be fixed, how to classify each failure source, what action is actually available for each category, and how to decide when ignoring a failure is the right answer.

Why Some DMARC Failures Cannot Be Fixed

Email was designed in an era when sender accountability was not a priority. DMARC tries to impose accountability retroactively, and some legitimate email sending patterns do not survive that imposition. The most common sources of unavoidable failures are:

Forwarding services. When a recipient sets up a rule to automatically forward your emails to another address, the forwarding service re-sends your message from its own infrastructure. The From header still shows your domain, but the envelope sender and the sending server are the forwarder's. DMARC checks fail because neither SPF nor DKIM align with your domain on the forwarder's server. You do not own the forwarding service. You cannot fix it.

Mailing lists. Some mailing list software takes your email, wraps it, and sends it from the list server's domain with your domain still in the From header. The list server does not have your DKIM key and its SPF record does not include your domain. DMARC fails. You do not control the list server. You cannot fix it.

Third-party senders using your domain. Platforms that send transactional email or marketing email on your behalf should use proper DKIM signing and SPF authorization. When they are misconfigured, their sends look like failures even though the email is authorized by you. Sometimes the misconfiguration is on their side and you cannot fix it directly.

Legacy servers you no longer control. Old mail servers that were decommissioned but still send email with your domain in the From header will produce perpetual failures. You cannot fix a server you do not know exists.

Genuine spoofing attempts. Actual phishing and impersonation attacks produce DMARC failures too. These are fixable, but only in the sense that you need to investigate and shut them down -- not by tweaking your DMARC record.

A Decision Tree for DMARC Failure Sources

When you see a DMARC failure in your report, ask three questions in order:

1. Do I send email from this source? If yes, check the configuration of that sending system.

2. Is this source authorized to send on my behalf? If yes, check SPF and DKIM alignment for that sender.

3. Is this failure a pattern from a forwarding service, mailing list, or legacy system I cannot reconfigure? If yes, this failure cannot be fixed -- it needs to be classified and monitored.

If you get to question 3 and the answer is yes, you are dealing with an unfixable failure. Here is what to do next.

What Each Failure Category Means and What to Do

Forwarding failures

A Gmail user forwards your newsletter to their work address. Their corporate mail server receives the forwarded message from Google's servers, not from yours. The From header says yourdomain.com, but SPF checks Google's servers and DKIM checks Google's keys. Nothing aligns with your domain.

This is not spoofing. This is email forwarding doing exactly what email forwarding was designed to do.

You cannot prevent this without asking the forwarder to change their behavior. RFC 7489 (the DMARC specification) explicitly acknowledges this limitation: forwarding services will produce authentication failures that are not security incidents.

What to do: Check whether the forwarding path is important. If a specific forwarding destination is generating consistent failures and the recipient does not need the forwarded email, consider contacting the user and asking them to update their forwarding settings. If forwarding is business-critical for a specific workflow, explore alternative communication channels for that use case.

Some forwarding setups can be improved from your side. If you control the forwarding rule (for example, rules you run on your own mail server to forward emails to a ticketing system or an archiving service), make sure your mail server is authorized in your SPF record.

Mailing list failures

Your domain is in the From header of an email sent by a mailing list server that does not sign your emails with DKIM and does not send from your SPF range. Every message the list distributes generates a DMARC failure.

This is a structural incompatibility between your domain's DMARC policy and the mailing list software. The mailing list would need to implement SRS (Sender Rewriting Scheme) or move to a DMARC-compliant relay mode to fix this. Many hosted mailing list services have done this work. Many self-hosted lists have not.

What to do: Contact the mailing list operator and ask whether they support DMARC-compliant sending. If they do not, there is no fix on your side. You can either accept the failures (your p=none policy means they do not affect delivery) or stop using that mailing list. If the list is important to your business, migrate to a service that handles DMARC correctly.

Third-party sender failures

This is the most fixable category of the three, because the platform either needs configuration changes or your DNS records need updating. A platform sends email on your behalf but its sending servers are not included in your SPF record, or it does not sign emails with your DKIM key. This is the most fixable category because the problem is either a missing DNS record or a misconfigured platform integration.

What to do: Confirm the platform is authorized to send on your behalf. Most reputable platforms provide explicit instructions for setting up SPF and DKIM. Follow those instructions. If the platform is sending on your behalf without authorization, that is a separate security concern -- revoke their access immediately.

Common examples: transactional email platforms (SendGrid, Postmark, Amazon SES), marketing email platforms (Brevo, Mailchimp, ConvertKit), CRM platforms that send on your domain.

If you use one of these platforms and still see DMARC failures from their sending infrastructure, the platform's DKIM key rotation may have broken, or your DNS records may have expired. Check the platform's authentication status dashboard and re-verify your DNS records.

Legacy server failures

You see failures from an IP address that you do not recognize and a sending domain you no longer use. Someone is sending email from a server that was supposed to be shut down, or an old marketing platform that was not deprovisioned correctly.

What to do: Track down the server. If it is yours, shut it down or reconfigure it so it stops sending from your domain without authorization. If it is not yours and you cannot identify it, treat it as a spoofing attempt and investigate whether your domain has been impersonated in a campaign.

Genuine spoofing

Your domain appears in the From header of emails sent from IP addresses you do not own, using sending infrastructure you do not recognize. These are actual impersonation attacks.

What to do: These failures are fixable -- not by changing your DMARC record, but by investigating and stopping the spoofing source. Check whether your domain has been used in a phishing campaign. Use your DMARC report data to identify the sending IPs and domains involved. If the spoofing is coming from your own infrastructure being compromised, remediate the compromise. If it is external, there is little you can do to stop it directly, but your DMARC policy protects recipients from receiving your domain's spoofed emails -- as long as your policy is set to quarantine or reject.

When to Ignore DMARC Failures

There is a meaningful difference between monitoring failures and acting on them.

If your DMARC policy is p=none, failures do not affect email delivery. You are collecting data only. In that context, unfixable failures are not problems to be solved -- they are noise to be classified and tracked. The only reason to act on a p=none failure is if it represents a security incident (genuine spoofing) or a configuration error you can actually fix.

If your DMARC policy is p=quarantine or p=reject, failures cause emails to be blocked or junked. In that context, unfixable failures from forwarding services or mailing lists may be blocking legitimate email. If you see legitimate emails being rejected because of forwarding, your options are limited: you can lower your policy to p=none (not recommended if you have spoofing problems) or you can work with the forwarding party to resolve the issue.

The common thread: ignoring a DMARC failure is only safe when you have confirmed it is not a security incident and you have assessed the business risk of leaving it unaddressed. That assessment is still work. DMARC monitoring without the ability to classify and triage failures is just noise generation.

How DMARC Monitoring Tools Handle Unfixable Failures Differently

Most DMARC monitoring tools show you the raw data: SPF fail, DKIM fail, DMARC fail, source IP, sending domain. That data is accurate. It is also incomplete. A failure line that says "SPF fail" does not tell you whether that failure represents a forwarding service, a mailing list, a misconfigured third-party sender, or an impersonation attack.

DMARCFlow was designed to close that gap. When a DMARC report arrives, DMARCFlow surfaces the forwarding path so you can assess whether the email was actually delivered and whether the forwarding party needs to be contacted. It tracks which mailing lists consistently generate failures so you can decide whether to engage with the list operator or accept the failure rate. And it monitors third-party sender authentication status, alerting you when a DKIM key rotation or SPF change at the platform side breaks your alignment.

This is the practical difference: most tools show you the fire alarm ringing. DMARCFlow tells you which room the fire is in.

FAQ

Should I worry if my DMARC report shows failures from Gmail forwarding?

Not usually. Gmail-to-Gmail forwarding is extremely common and produces consistent DMARC failures that are not security incidents. If the forwarded emails are reaching their intended recipients, the failure is informational only.

Can I block forwarding services from triggering DMARC failures?

No. You cannot control how recipient servers handle forwarded messages. The failure originates at the recipient's mail system, not at yours.

My old mail server is no longer active but still appears in DMARC reports. What do I do?

If you still control the server, shut it down or reconfigure it so it stops sending from your domain without authorization. If you do not control it, treat it as a potential spoofing incident and investigate whether your domain is being used without authorization.

Is p=none still useful if I cannot fix all failures?

Yes. p=none tells receiving servers to accept all emails regardless of authentication result. This means your legitimate forwarded emails still arrive even if they fail DMARC. p=none is not a weak policy -- it is a monitoring-only policy that accepts the trade-off of allowing all sends, authenticated or not.

How do I tell the difference between a forwarding problem and a spoofing attack in my DMARC reports?

Forwarding problems produce consistent, repetitive failures from the same IPs (typically large email providers like Google, Microsoft, and Yahoo). The sending domain in the failure report is usually a major ESP, not your own domain. Spoofing attacks typically come from IP addresses that are not affiliated with major email providers and may include suspicious or entirely unrelated sending domains. DMARCFlow helps by surfacing the full failure context rather than just the pass/fail result.