Blog · Dmarc
Why Third-Party Senders Break DMARC and How to Fix Subdomain Delegation
Third-party senders break DMARC in one of two ways: they send from their own infrastructure using your From address, or they fail to DKIM-sign messages with your domain. Either way, the result is the same. Legitimate mail gets rejected or quarantined, and the person who onboarded the vendor spends the afternoon debugging email authentication.
The fix is subdomain delegation. Give the vendor a subdomain, put their SPF information on that subdomain, and manage the subdomain's DMARC policy independently. Here is how it works and what your alternatives are.
Why third-party senders cause DMARC failures
DMARC checks two authentication mechanisms: SPF and DKIM. Both work through alignment.
SPF alignment requires the domain in the RFC 5321 MailFrom (the envelope sender that mail servers see) to match the domain in the RFC 5322 From header (what recipients see in their mail client). These are frequently different even in normal mail. DMARC rejects them unless they match.
DKIM alignment requires the domain in the DKIM signature to match the From header domain. This is easier to satisfy because DKIM signatures can use any domain the sender controls, and a correctly configured vendor can sign with your domain.
The typical failure looks like this: your domain is example.com. You onboard a CRM that sends transactional mail from its own SMTP servers. The MailFrom becomes something like m12345.bounces.crmplatform.com. That domain is not in your SPF record and does not match example.com. SPF alignment fails. If the CRM does not DKIM-sign with your domain, DKIM alignment also fails. With both failing, your DMARC policy rejects the mail.
This is DMARC working correctly. The vendor was never set up for your environment.
The three options for third-party sender authentication
Option 1: Delegate a subdomain to the vendor
Give the vendor a subdomain dedicated to their traffic. Instead of the CRM sending from support@example.com, it sends from support@mail.example.com or crm@example.com. Add the vendor's SPF include to that subdomain. The vendor sets their MailFrom to match the subdomain. The From header the recipient sees is unaffected.
Most enterprise platforms support this. Salesforce, HubSpot, and Marketo all do. Smaller platforms sometimes do not, which means escalating with their support team or moving to a different option.
DNS setup for the delegated subdomain:
crm.example.com. 300 IN TXT "v=spf1 include:mail.crmplatform.com ~all"
DMARC record on that subdomain, starting at p=none:
_dmarc.crm.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Monitor for two to four weeks. If only that vendor sends from the subdomain and alignment is clean, move to p=quarantine, then p=reject. Your root domain policy is unaffected.
Option 2: Ask the vendor to DKIM-sign on your behalf
Some platforms can sign with a DKIM key you control, rather than their default domain key. This requires the vendor to support customer-managed DKIM keys. Google Workspace and Microsoft 365 both support this. When configured correctly, DKIM alignment passes even if the MailFrom does not match your domain.
The catch is coordination. You generate the key pair, hand over the public key, and trust the vendor to sign every message correctly. This only works reliably with vendors that have mature enterprise onboarding.
Option 3: Isolate the vendor on a dedicated subdomain
If the vendor cannot do either of the above and insists on sending from your root domain, isolate their traffic on a subdomain with its own DMARC policy. Your root policy stays at p=reject. The vendor subdomain starts at p=none.
This does not fix alignment for mail they send from your root domain. It stops the vendor problem from forcing you to weaken your main policy.
Comparing the three options
| Subdomain delegation | Vendor DKIM signing | Isolated subdomain | |
|---|---|---|---|
| Alignment result | Both SPF and DKIM pass | DKIM passes | Depends on vendor |
| Vendor cooperation required | Yes, must set custom MailFrom | Yes, must support customer DKIM keys | Minimal |
| Complexity | Medium | High | Low |
| Risk to root domain | None | None | Low if p=none on subdomain |
| When it works best | Most third-party senders | Enterprise platforms with mature auth support | Vendors who refuse to cooperate |
How to audit your current third-party sender exposure
Before onboarding any new vendor, look at what is already sending mail for your domain. DMARC aggregate reports show every sending source, the IPs used, and the authentication results. Unknown subdomains in your reports are your real vendor inventory.
Most organizations find senders they had forgotten about. A platform that was onboarded three years ago by someone who left. A legacy integration that is still running. A shadow IT marketing tool that IT never knew about. These show up as alignment failures in your reports.
DMARCFlow makes this audit faster by showing which subdomains are sending, which IPs they use, and which are failing alignment. That is the list you use to prioritize which vendors to fix first, rather than waiting for mail failures to surface the problem.
Step-by-step: onboarding a new third-party sender without breaking DMARC
Do this before the vendor starts sending.
Ask first. Can the vendor send from a subdomain you control? If yes, get their SPF include mechanism or their outbound IP addresses before they send anything.
Create the delegated subdomain. Add their SPF to the subdomain DNS. Set the DMARC record to p=none. Point the rua aggregate report to your inbox.
Monitor for two to four weeks. Check for unexpected senders on that subdomain. If only the vendor is there and alignment is clean, move to p=quarantine.
Watch for another two weeks at p=quarantine. If nothing breaks, move to p=reject.
Document everything. Vendor name, subdomain, SPF mechanism, policy change dates. Your future self needs this when reviewing your domain portfolio.
Make it a procurement requirement. Any new vendor that sends mail from your domain must support custom MailFrom domains or DKIM signing on your behalf. If they cannot, they are a future DMARC incident. Find out before signing the contract.
What this means for your DMARC rollout
If your organization is still in p=none monitoring mode, third-party senders are probably silently failing right now. You have not noticed because p=none does not block anything. The moment you move to p=quarantine or p=reject, those silent failures become real mail loss.
The vendor problems are already in your DMARC data. The question is whether you look before or after users start complaining that transactional mail is not arriving.
DMARCFlow aggregate reports surface which subdomains are sending mail for your domain, which IPs they use, and which alignment failures are occurring. That visibility is what makes subdomain delegation fast and systematic rather than a reactive scramble every time a new vendor breaks your policy.
Frequently asked questions
Does subdomain delegation change the From address that recipients see?
No. The From header and the MailFrom envelope are independent. Recipients still see support@yourcompany.com. The delegation only changes what mail servers see during SMTP delivery.
What if a vendor cannot support custom MailFrom domains?
Escalate with their enterprise support team. Many vendors who initially say no can enable it with the right ticket. If they genuinely cannot, isolate their traffic on a dedicated subdomain with p=none. Do not loosen your root domain policy to accommodate a vendor that will not cooperate on authentication.
Does DKIM signing help if the MailFrom domain does not match?
Yes. DKIM and SPF are independent mechanisms. If DKIM alignment passes, SPF failures can be forgiven under your DMARC policy. The ideal state is both passing, but DKIM-only alignment is better than neither.
How long does subdomain delegation take to set up?
DNS propagation is usually minutes to hours. The monitoring period before tightening the DMARC policy takes a minimum of two to four weeks at p=none, then two to four more weeks at p=quarantine. From first contact to p=reject on a delegated subdomain typically runs four to eight weeks.
Should third-party senders be on a delegated subdomain or added to the root domain SPF record?
Delegated subdomain. Adding third-party servers to your root domain SPF record leads to SPF lookup limit exhaustion, which is a separate problem that breaks SPF for your entire domain. Delegated subdomains keep vendor SPF changes isolated.