Third-Party Emails Rejected by DMARC: Fix Guide

You set up DMARC, watched your aggregate reports for a few weeks, then flipped the policy to p=reject. A few days later, someone in marketing files a ticket: their emails to customers from the new CRM system stopped arriving.

That's not a DMARC problem. That's DMARC working exactly as designed - and exposing a gap in your sending authorization.

This article explains why third-party senders fail DMARC, how to find out which ones are failing, and the three realistic paths to fix it.

Why Third Parties Fail DMARC: The Three Failure Modes

When an email arrives at a destination mailbox, the receiving server checks it against your DMARC record. For DMARC to pass, one of two things must be true:

SPF aligned: the sender's IP is in your SPF record and the RFC 5321 MAIL FROM domain matches your From domain
DKIM aligned: the email is signed with a DKIM key in your domain's DNS and the RFC 5322 From domain matches the signing domain

Third-party senders typically fail on both counts. Here's why.

Failure Mode 1: From Header Mismatch

Your CRM sends email where the From header reads support@yourcompany.com, but the actual sending infrastructure is owned by the CRM vendor. The MAIL FROM domain might be something like smtp.crmplatform.com. To the receiving server, this looks like email from two different organizations - SPF alignment fails, and without DKIM, DMARC fails too.

Failure Mode 2: SPF Not Aligned

Even if the vendor sets the MAIL FROM correctly, their sending IPs are not in your SPF record. Your SPF record covers your own mail servers, not their platform. Without an explicit include: for their sending infrastructure, SPF alignment fails.

Failure Mode 3: No DKIM Signing

Many third-party platforms either don't offer DKIM signing at all, or require opt-in configuration that wasn't completed during onboarding. Without a DKIM signature that passes alignment, DMARC authentication fails.

Finding Out Who's Failing

Before you can fix anything, you need to know what's breaking. There are two ways:

Method 1: Read Your DMARC Aggregate Reports

Your DMARC aggregate reports (XML files) tell you which IPs are sending email purporting to be from your domain, and whether they passed or failed authentication. The reports are tedious to parse manually - which is exactly why people use tools for this.

In DMARCFlow, the failure dashboard shows you a list of failing sources organized by sending domain, with the specific authentication result (SPF fail, DKIM fail, or both). You can see at a glance which vendors are consistently failing and which ones appeared recently after a policy change.

Method 2: Watch for Bounce Feedback

Some bounce messages are useful. If you see temporary failure messages from external mail systems, they often include the reason: authentication failed, policy rejected, or bad sender reputation. Permanent failures (hard bounces) confirm the email never arrived.

The problem with relying on bounces alone is that you only learn about failures when someone notices and reports them. By then, customers may have missed important transactional emails.

The Three Fix Paths

Once you know which third parties are failing, you have three options. They're listed in order of preference.

Fix Path 1: SUBMISSIONS (Recommended)

The cleanest solution is to have the third party send through your own infrastructure rather than their own.

RFC 7372 defines the SUBMISSIONS submission port (port 587) specifically for mail that should be considered authorized on your behalf. When a vendor connects to your mail server via SUBMISSIONS and authenticates with credentials you provide, the mail is submitted as your organization - SPF and DKIM both pass because the sending infrastructure is yours.

What this looks like in practice:

The third party connects to mail.yourcompany.com on port 587, authenticates with a dedicated credential you create for them, and sends with the From header set to your domain. Your mail server relays it outward with your own SPF and DKIM signatures.

This requires your own mail server to accept relay credentials and the third party to support authenticated SMTP submission. Most modern CRMs, marketing platforms, and helpdesk tools support this - but it does require configuration on both sides.

If you don't run your own mail infrastructure (you're fully on Google Workspace or Microsoft 365), you can often configure third-party relay by adding their sending domains as authorized senders within your admin panels, or by setting up a relay service that accepts submissions on your behalf.

Fix Path 2: SPF Delegation via include:

If the third party sends from their own infrastructure but consistently from a predictable set of IPs, you can add their sending domain to your SPF record using an include: mechanism.

For example, if Salesforce sends from sf-mta-*.salesforce.com, you add:

include:sf-mta-bounce.salesforce.com

This extends your SPF record to cover their IPs as authorized senders. The risk is that you're adding a mechanism you don't control - if Salesforce changes their sending infrastructure without telling you, your SPF breaks.

A practical constraint: RFC 720 requires that SPF checks complete within 10 DNS lookups. Every include: counts as a lookup. If you're already near the limit (from other includes, your own mx records, etc.), you may hit the ceiling and need to consolidate first.

Fix Path 3: Lower the Policy to p=quarantine

If neither of the above is feasible in the short term, you can lower your DMARC policy to p=quarantine while you work on a proper fix. Email that fails DMARC will be treated as suspicious rather than rejected - it lands in spam instead of bouncing.

This is a temporary compromise, not a solution. A policy of p=quarantine still provides useful aggregate reporting data. Many organizations use this as a staging step while they migrate third parties to SUBMISSIONS.

Do not stay at p=quarantine permanently. The goal is p=reject with full visibility and control over your authorized sending sources.

How to Prevent Third-Party Failures Before p=reject

The right time to audit third-party senders is before you set a strict policy, not after. Here's a checklist:

1. Map every service that sends email on your behalf - CRM, marketing automation, transactional email, support platform, billing system, payroll, etc.

2. For each service, confirm whether it sends via your infrastructure (SUBMISSIONS) or its own

3. If it sends via its own infrastructure, open a ticket and ask about DKIM signing and authenticated SMTP submission support

4. Set up DMARC monitoring at p=none first - collect aggregate reports for at least 2-4 weeks before moving to p=quarantine

5. When adding a new vendor, check their email sending configuration before going live; treat new senders as a DMARC audit event

DMARCFlow automatically flags new sending sources that appear in your aggregate reports for the first time. If a new vendor starts sending as you and they haven't been authorized yet, you'll see them appear in the failures dashboard before they cause an email outage.

FAQ

Does p=quarantine stop third-party emails from bouncing?

No. p=quarantine means failing emails go to spam, not that they stop being sent. The emails still arrive, just less reliably. p=reject is what causes bounces.

Can I use a different Return-Path domain to fix DMARC failures?

No. The Return-Path (also called the envelope sender) is what DMARC checks for SPF alignment. Changing the Return-Path doesn't solve the underlying authorization problem.

What if a third party refuses to change their sending practices?

You have two options: stop using that vendor for email that needs to come from your domain, or stay at p=quarantine indefinitely. Moving to p=reject without resolving third-party sending means permanent delivery failure for those emails.

How long does it take for a DMARC policy change to show effect?

Most large email receivers check your DMARC record every time they receive mail from your domain. A policy change typically takes effect within minutes to hours. However, caching behavior varies, and some receivers may honor cached records for up to 24 hours.

Summary

Third-party senders fail DMARC because they send from their own infrastructure using your From header - which fails both SPF and DKIM alignment checks.

The real fix is SUBMISSIONS: have vendors send through your infrastructure on port 587 with authentication, so your own servers handle SPF and DKIM signing.

The short-term fix is SPF delegation via include:, but this requires ongoing maintenance and adds lookup count complexity.

The fallback is p=quarantine, which stops the immediate bounces but doesn't solve the underlying problem.

DMARCFlow monitors all sending sources automatically, flags new vendors as they start sending, and gives you the failure data you need to audit third-party senders before you move to a strict policy. Set up monitoring before p=reject - not after.