Both SPF and DKIM Failures in DMARC Reports

If you're looking at your DMARC reports and seeing both SPF and DKIM failures on the same messages, you're not necessarily dealing with a broken configuration. In most cases, you're seeing what happens when email gets forwarded through a chain that wasn't designed with authentication in mind.

This article explains why both failures often appear together, how to tell if forwarding is the cause, what percentage of failures is acceptable before tightening your policy, and the correct process for moving to p=reject when third-party forwarding is in the picture.

Why Both SPF and DKIM Are Failing on the Same Emails

The most common reason you see simultaneous SPF and DKIM failures is email forwarding, specifically, when a third party re-sends your message under your own domain without being authorized to do so.

Here's what happens in a forwarding chain:

Your original email is sent with correct SPF and DKIM signatures from your domain (sender@example.com).
A recipient's server forwards the message to another address, keeping your domain in the From header but using the forwarder's SMTP to deliver it.
SPF fails because the forwarder's IP address is not in your SPF record, the envelope sender is the forwarder, not your mail server.
DKIM may also break because the forwarder either modifies headers (such as adding or changing the Return-Path) or adds content like a footer, which changes the message body that was originally signed.
Both failures together cause DMARC alignment to fail, the message appears to come from your domain but wasn't sent by an authorized mechanism.

The result: both SPF and DKIM fail for the same forwarded message, and DMARC alignment also fails, because DMARC requires at least one of SPF or DKIM to pass and align with the From domain.

How to Identify Forwarding From Your DMARC Report

Your aggregate DMARC report (delivered to the rua address in your record) contains the evidence. Here's what to look for:

Check the RCPT TO domain. Failures concentrated at free email providers like Gmail, Yahoo, or Outlook are a strong signal of forwarding. These destinations commonly receive forwarded mail from distribution lists and auto-forward rules.

Look for simultaneous SPF and DKIM failures. When forwarding is the culprit, both checks fail at the same time because the forwarder controls the envelope (affecting SPF) and may modify content (breaking DKIM).

Ask the affected recipient. If the failing messages trace back to a specific partner or forwarding address, ask whether they have an auto-forwarding rule in place. In most cases, they'll say yes.

A real example from a Google Workspace admin: after setting up SPF, DKIM, and DMARC for a Google Workspace domain, the admin saw failures concentrated at external Gmail addresses. The cause: a distribution list that was auto-forwarding all incoming mail to personal Gmail accounts. The list's server was re-sending the message using its own SMTP while keeping the original From header intact. Both SPF and DKIM failed because the forwarder's infrastructure and any content modifications didn't match the authenticated sender.

Is This Amount of Failure Normal Before Moving to p=reject?

Whether your failure rate is acceptable depends on the volume and source.

If failures are below 5% and traceable to known forwarding addresses, you're probably looking at normal, manageable forwarding, not a security problem. Forwarding-related failures don't represent spoofing, they're side effects of a legitimate flow.

If failures are scattered across many unrelated destinations with no clear pattern, dig deeper. You may be dealing with a configuration issue or an attempt to relay mail through your domain.

If failures come from your own domain being used by unknown servers, that could indicate spoofing and p=reject would be appropriate.

The key question before moving to p=reject: do these failures represent legitimate forwarded mail you want to preserve, or unauthorized attempts to deliver as your domain?

How to Safely Move to p=reject When Forwarding Is Involved

If forwarding is causing your failures and you still want to tighten your DMARC policy, here are your options:

Option 1: Contact the forwarder. Ask them to stop forwarding or implement ARC (Authenticated Received Chain). ARC lets forwarders add their own signature to the chain so forwarded messages can pass authentication at the final destination.

Option 2: Move to p=quarantine first. Set your DMARC policy to p=quarantine and monitor for two to four weeks. This tags failing mail rather than blocking it outright, letting you catch any legitimate flows you might have missed.

Option 3: Accept the forwarded mail limitation. If forwarding comes from important customer or partner systems you don't control, you may need to stay at p=quarantine for those destinations. Your DMARC policy doesn't block incoming mail, it only controls what happens to mail claiming to be from your domain.

Option 4: Use a DMARC monitoring tool. The tool DMARCFlow parse your aggregate reports and group failures by source, making it faster to distinguish forwarding patterns from genuine auth failures. You can see at a glance whether failures are concentrated in known forwarding paths or scattered across suspicious sources.

Quick Checklist: What to Check First

Before you do anything else:

Confirm your SPF record is correct. Use an SPF checker to verify your record includes all legitimate sending sources.
Confirm your DKIM is signed and propagating. Check that your email provider is actually signing outbound mail and that the record is visible in DNS.
Check your DMARC alignment. Both SPF and DKIM must align with your From domain, passing individually is not enough.
Review your aggregate reports. Look for patterns: do failures come from specific domains, time periods, or RCPT addresses?
Ask about forwarding rules. Contact affected recipients and ask if they have auto-forwarding configured.

FAQ

Why are both SPF and DKIM failing on the same emails?

The most common cause is email forwarding. When a forwarder re-sends your message using their own SMTP while keeping your domain in the From header, both SPF (envelope sender mismatch) and DKIM (content modifications) fail simultaneously.

Is a small percentage of DMARC failures normal before moving to p=reject?

Yes, if those failures are traceable to known forwarding scenarios. Low single-digit percentages from confirmed forwarding addresses are generally not a sign of a problem, they're a side effect of how email forwarding works.

How do I tell if failures are from forwarding?

Check your aggregate DMARC report. Look for failures concentrated at free email providers (Gmail, Yahoo, etc.) and patterns where the same RCPT addresses appear repeatedly. Direct delivery failures usually show up at specific corporate destinations, not widespread providers.

Can I use p=reject if third parties are forwarding my email?

Only if you're willing to risk blocking those forwarded messages. The safer approach is to move to p=quarantine first, confirm the forwarding sources, and either resolve them or accept the quarantine policy for those flows.

What does ARC have to do with forwarding?

ARC (Authenticated Received Chain) is a protocol that lets forwarders add a signature to the email chain, preserving authentication results through multiple hops. If your forwarder supports ARC, forwarded mail is more likely to pass DMARC at the final destination. Not all forwarders support it yet.

If you're monitoring DMARC reports regularly and want a faster way to spot forwarding patterns versus real auth failures, DMARCFlow is designed for exactly that kind of ongoing analysis. It processes aggregate reports and groups failures by source, so you spend less time parsing raw data and more time making actual decisions.