Why Forwarded Emails Fail When You Set DMARC to Quarantine

You set DMARC p=quarantine on your domain. Your legitimate emails are going through. Then someone reports that a forwarded copy of your email never arrived. You check SPF, DKIM, DMARC records -- everything looks correct. So why did the forwarded version fail?

The answer is not that your records are wrong. The answer is that forwarding fundamentally changes how email authentication works, and p=quarantine makes receivers treat those alignment failures differently than p=none would.

When your email is forwarded, the forwarding server becomes the new sender. It re-injects your message using its own SMTP envelope, even though the From: header still shows your domain. At the destination, the receiving server checks SPF against the forwarding server's domain (not yours) and DKIM against whatever that server signs with (if anything). Alignment fails. With p=none, the message gets delivered anyway. With p=quarantine, it gets quarantined or spam-foldered. DMARCFlow is the tool that shows you this is happening in your aggregate reports, before users start complaining.

How forwarding breaks DMARC alignment

When you send an email directly to recipient A, your mail passes through your sending infrastructure, and the receiving server checks your SPF and DKIM against your own domain. Alignment is straightforward.

When recipient A forwards your email to recipient B, something important happens: recipient A's mail server becomes the new sender. It passes along the original message but now injects it with its own SMTP envelope. The From: header still shows your domain, but the actual sending server is now recipient A's server.

The receiving server at recipient B checks SPF against recipient A's domain (not yours) and DKIM against whatever recipient A's server signs with (if anything). Neither matches your From: domain. DMARC alignment fails.

With p=none, the receiving server accepts the message anyway. With p=quarantine, it puts it in quarantine folders instead. The forwarded email disappears without the sender ever knowing.

This is not a bug. It is how forwarding works by design. The problem is that p=quarantine turns a silent failure (p=none) into a visible delivery failure that confuses senders and recipients alike.

Which forwarding scenarios trigger quarantine

Not all forwarding breaks DMARC alignment the same way. Here is where the problem shows up most:

List forwarding and mailing list servers

Mailing lists re-inject email from the list server's own infrastructure. They also often rewrite the From: header to show the list address rather than the original sender. Both actions break SPF and DKIM alignment. If your domain's DMARC policy is p=quarantine or p=reject, list server delivery will be affected.

Personal auto-forwarding

When a user sets up a rule to automatically forward all incoming mail to a personal Gmail or Outlook account, the original SMTP transaction is between the forwarding server and the new recipient. The forwarding server is not authorized to send on behalf of the original domain, so SPF fails. The forwarded message may be quarantined at the destination.

Email-to-fax or email-to-SMS gateways

Some organizations route email through third-party fax or SMS gateways that re-transmit the message. These gateways typically do not preserve DKIM signatures and often use their own sending infrastructure. DMARC alignment fails, and with p=quarantine, legitimate outbound notifications get quarantined.

Forwarding through secondary MX hosts

Some organizations forward mail through a secondary MX or mail relay for archiving or compliance scanning. If that relay does not sign with DKIM or authorize itself via SPF for the original domain, alignment breaks and the message gets quarantined at the final destination.

Why p=quarantine still surprises people

p=quarantine is widely presented as the cautious middle step between p=none and p=reject. The logic sounds reasonable: quarantine is softer than reject, so it should be safer.

But quarantine does not mean "accept everything that looks mostly OK." It means "treat alignment failures as suspicious." When a forwarded message fails alignment, receivers apply quarantine instructions to it. The original sender's correct SPF, DKIM, and DMARC records do not protect forwarded copies because those records were validated at the first hop, not the final one.

The confusion comes from thinking about email authentication as protecting the sender. DMARC protects recipients from spoofed mail. When your legitimate mail is forwarded, it is not being spoofed -- it is being re-transmitted by a legitimate but unauthorized server. DMARC treats that re-transmission as a signal of potential spoofing and applies the quarantine policy accordingly.

How to diagnose forwarded email failures

DMARC aggregate reports show you exactly which external domains are failing alignment when delivering mail on behalf of your users. A forwarded email failure typically shows up as:

• A failure from an IP address that does not belong to your known sending infrastructure
• SPF alignment fail or DKIM alignment fail (or both)
• The From: domain matching your organization, but the envelope sender showing the forwarding domain

When you see a pattern of failures from known forwarding services -- Google Workspace forwarding, Microsoft 365 forwarding rules, specific mailing list providers -- you have found a forwarding dependency that p=quarantine will affect.

DMARCFlow reads your aggregate reports and surfaces forwarded email alignment failures in a readable format. You see which forwarding scenarios are causing problems, which alignment checks are failing, and whether the forwarding volume is growing or stable. That visibility is what makes moving from p=none to p=quarantine survivable. Without it, you are changing policy blind and finding out about failures from user complaints instead of aggregate data.

For organizations considering p=quarantine or already running it, this aggregate report review is not optional. It is the only way to know how many forwarding dependencies you have before they become problems.

Decision framework: quarantine vs reject for orgs with forwarding

If your organization forwards mail to external addresses, here is a practical sequence:

1. Review DMARC aggregate reports with p=none active. Look for all failed sources, not just your own IPs. Identify forwarding patterns. DMARCFlow makes this practical without XML parsing.

2. Triage forwarding by business impact. List server forwarding for a high-volume mailing list is different from one user's personal forwarding rule.

3. Address fixable forwarding. Some forwarding can be reconfigured to preserve alignment. Mailing list servers that support ARC (Authenticated Received Chain) may help. Some forwarding services offer DMARC-friendly relay modes.

4. Set a timeline for p=quarantine. Run it long enough to capture aggregate reports that show real forwarding volume.

5. Move to p=reject when aggregate reports show no critical forwarding dependencies remain.

Organizations that skip step 1 and move straight to p=quarantine are the ones who get surprised by suddenly quarantined forwarded mail.

## FAQ

Does p=quarantine block all forwarded emails?

No. p=quarantine instructs receivers to treat alignment failures as suspicious and quarantine the message, but different receivers implement this differently. Some quarantine aggressively; others quarantine only a fraction of alignment-failed mail. The behavior is not standardized the way p=reject is.

Can I forward mail and still use p=reject?

In some cases, yes. If the forwarding service supports ARC, it can preserve the original authentication chain so receivers can make a more informed decision. Some forwarding services also offer DMARC-friendly modes that preserve alignment. Subdomain-based sending (using a subdomain specifically for forwarded or third-party communications) can also work.

My own company forwards mail through an internal relay. Does that break DMARC?

Internal relay configurations can break DMARC if the relay re-injects mail without proper DKIM signing or SPF authorization. If your internal relay fails alignment before forwarding externally, it can trigger quarantine at the destination. Proper relay configuration -- including DKIM signing at the relay or using a dedicated sending subdomain -- prevents this.

How do I know if forwarded mail is being quarantined?

Check your DMARC aggregate reports. If you see alignment failures from domains that are not your own sending infrastructure, and those failures correspond to forwarded mail flows, you have found the problem. You may also hear from users who report that forwarded copies of messages are missing from destination accounts.

Is p=none safe to stay on indefinitely?

p=none gives you visibility without enforcement. It is safe to stay there while you build your DMARC knowledge and address sending infrastructure. Most organizations should spend time at p=none reviewing aggregate reports before moving to quarantine. The main risk of staying at p=none long-term is that you have no protection against domain spoofing.