Why Third-Party Email Senders Break DMARC Alignment

The problem you probably did not expect

You have SPF configured. You have DKIM configured. Your DMARC record is published. Then a third-party email security vendor (Proofpoint, Mimecast, Cisco IronPort) starts sending some of your mail, and suddenly recipients are rejecting it.

The rejection says DMARC failed. Your first instinct is to check your SPF and DKIM. They look fine. So what went wrong?

The issue is not that authentication failed. The issue is that the sending domain does not match your From address domain. This is called DMARC alignment, and it is a separate check from SPF or DKIM passing.

Why DMARC checks alignment separately from authentication

SPF and DKIM answer the question: is this email from a server that is allowed to send for this domain?

DMARC alignment asks a different question: does the domain in the From header match the domain that SPF or DKIM authenticated?

Here is the specific sequence that causes failures with third-party vendors:

Your mail server sends an email. The From header shows yourdomain.com. Your vendor receives it for processing, archiving, or security scanning.
The vendor sends it onward to the recipient. The vendor's server uses its own EHLO domain (vendor-example.com) and its own DKIM keys.
The recipient's server receives the email. SPF check: pass (the vendor's IP is valid for vendor-example.com). DKIM check: pass (vendor-example.com was signed by the vendor). DMARC check: From: yourdomain.com does not match vendor-example.com. Alignment fails. DMARC fails.

The DMARC specification allows either SPF alignment OR DKIM alignment to pass (it is an OR check, not an AND check). But if the vendor is sending from its own infrastructure and signing with its own domain, neither alignment path matches your From domain. Both SPF and DKIM can pass at the authentication level while DMARC still fails.

Why this catches people off guard

The failure does not happen during vendor setup. It happens when the vendor starts sending mail directly to external recipients, or when a recipient domain enforces a strict DMARC policy.

Most vendors know about this problem. Most offer a configuration option to fix it. The options vary in cleanliness and effort.

Option 1: Vendor sends as your domain through your infrastructure (best)

Configure the vendor to use your SMTP infrastructure (your IPs, your DKIM keys) instead of theirs. The vendor sends as yourbrand@yourdomain.com from servers that authenticate as yourdomain.com. SPF passes (your IP is in your record). DKIM passes (you signed with your key). Alignment passes.

This is the cleanest solution. Your domain reputation stays yours. DMARC p=reject works normally. The vendor becomes a processing layer, not a sending layer. DMARCFlow sees this as a known, aligned sending source with no alerts triggered.

Option 2: Include the vendor in your SPF record

If the vendor must send from their own infrastructure, add their sending IPs to your SPF record. This makes vendor-example.com a valid SPF sender for yourdomain.com. Alignment passes because the SPF domain now matches your From domain.

The practical problem: many vendors use large and variable IP ranges. Getting the full range into your SPF record without hitting the 10-DNS-lookup limit is a real constraint. You may need SPF flattening or to route vendor traffic through a dedicated subdomain instead.

Option 3: Subdomain delegation for third-party sends

Route marketing email, bulk transactional email, and third-party tool notifications through a subdomain like marketing.yourdomain.com or bulk.yourdomain.com. That subdomain has its own SPF, DKIM, and DMARC record.

Your main domain stays isolated with a strict policy. If the marketing vendor misbehaves or fails alignment, it only affects the subdomain. DMARCFlow monitors both your main domain and subdomains, alerting separately on each DMARC policy state.

How Proofpoint specifically causes this

Proofpoint has two sending modes that produce different DMARC outcomes:

Proofpoint on customer infrastructure: the customer controls the IPs and DKIM keys. Alignment works normally. No DMARCFlow alerts for unaligned sources.
Proofpoint from Proofpoint infrastructure: Proofpoint signs with its own domain. Alignment fails for any customer From address unless specific "Custom Brand Sending" configuration is applied.

The Custom Brand Sending configuration makes Proofpoint send using the customer's sending domain and signing with the customer's DKIM selector. Without it, Proofpoint's shared infrastructure will fail DMARC alignment for any domain using it.

What aggregate reports show when this happens

In DMARC aggregate reports (RUA), this failure type appears as alignment failures from IP addresses outside your known infrastructure. You see high volumes of DMARC failures from a specific IP range. The DKIM result shows "pass" (the vendor signed) and the SPF result shows "pass" (the vendor's IP is authorized for the vendor's domain), but the From domain does not match either.

The pattern in your DMARCFlow aggregate report view: new source IPs appear under an unaligned DKIM domain or SPF domain. DMARCFlow flags these automatically as "unaligned sending source detected" and names the approximate infrastructure. This is faster than manually parsing RUA XML.

What to ask your vendor before they start sending

When you onboard any new email vendor that will send as yourdomain.com, ask these two questions before go-live:

"What domain will you use in the SMTP envelope (EHLO) when sending as our users?"
"What DKIM selector will you use, and will it be our domain or yours?"

If the answer to either is "our domain" instead of "yourdomain.com," alignment will fail unless they reconfigure. Get the answer in writing before they start sending to external recipients.

How to test before going to p=reject

Before moving your DMARC policy to p=reject, audit every IP and service that sends email as yourdomain.com:

Your primary mail server (MX)
Marketing email platforms (Mailchimp, HubSpot, Klaviyo)
Transactional providers (SendGrid, Postmark, Amazon SES)
Security vendors (Proofpoint, Mimecast, Cisco IronPort)
CRM and sales tools that send on your behalf
Any custom integrations

For each source, confirm the sending domain in SPF and the DKIM signing domain both match yourdomain.com. If a vendor cannot align, move it to a subdomain with its own DMARC record and keep your main domain isolated.

DMARCFlow's source inventory view shows all sending IPs grouped by infrastructure. Each group shows the DKIM domain and SPF domain it uses. Sources that do not match your From domain appear as unaligned. You can audit the full list in minutes instead of parsing aggregate reports manually.

Checklist before you enable p=reject

Identify every IP and service that sends as yourdomain.com
Confirm each source passes DMARC alignment
Move unaligned vendors to subdomains with separate DMARC records
Run DMARC p=quarantine for 30 days and review aggregate reports
Look for any unexpected alignment failures before upgrading
Switch to p=reject when the failure rate is zero for your own sources
Keep DMARCFlow monitoring active to catch any new unaligned source before it causes a rejection wave

How DMARCFlow makes this practical to manage

DMARCFlow addresses the core operational problem with third-party sender alignment: you cannot fix what you cannot see.

The specific value:

Aggregate report parsing groups failures by source IP and names the sending infrastructure
Unaligned DKIM domains are identified automatically, so you do not have to cross-reference DKIM selector DNS records manually
New unaligned sending sources trigger an alert before they cause a rejection cascade
Source inventory stays current as you add or change vendors

When a new vendor starts sending unaligned mail, DMARCFlow alerts you with the source IP and approximate vendor name. You can contact the vendor and fix the alignment before recipient servers start bouncing. That is the difference between finding out about an alignment problem from a vendor support ticket versus from a spike in your bounce rate.

FAQ

Q: SPF and DKIM both pass. Why does DMARC still fail?

A: DMARC alignment is a separate check from authentication. SPF and DKIM verify that the sending server is authorized. DMARC verifies that the domain in the From header matches the domain that was authenticated. Both can pass at the vendor level while DMARC fails if the vendor's sending domain differs from your From domain.

Q: Can I just add the vendor's IPs to my SPF record?

A: Adding the vendor's IPs fixes SPF alignment. But if the vendor also uses its own DKIM domain, DKIM alignment still fails. The complete fix requires either the SPF domain or the DKIM domain to match your From domain, or configuring the vendor to send on your behalf through your own infrastructure.

Q: Does TLS encryption fix DMARC alignment?

A: No. TLS encrypts the connection between mail servers. DMARC alignment is about domain matching, not connection security. You can have perfect TLS and still fail DMARC alignment.

Q: My vendor says they support DMARC. What should I ask them?

A: Ask: "Will you send as ourdomain.com from your infrastructure, or as vendor.com?" Then ask: "What DKIM selector will you use?" Get the answers before they start sending live traffic.

Q: What does the failure pattern look like in aggregate reports?

A: Look for DKIM result "pass" or SPF result "pass" combined with alignment "fail." That specific combination (auth passes, alignment fails) is the signature of a third-party sender alignment problem. High volume from a single IP range with this pattern almost always means a vendor is misconfigured.