Give the new sender its own subdomain, publish the DKIM key the vendor supplies, add its SPF include to that subdomain alone, send a test and read the headers, then watch DMARC reports for a few weeks. Never add a sender to the main domain record before you know it aligns.
Why this goes wrong
Marketing buys a tool on Tuesday and starts sending as your brand on Wednesday. If DMARC is already enforced, the first campaign lands in spam or is rejected. If it is not, the tool works but is unauthenticated, and you find out later.
The DMARC specification says as much in its rollout advice: in all but the most trivial setups a domain owner can overlook a server or be unaware of a third party sending agreement, which is why aggregate reports exist. A vendor you do not know about is exactly that case.
What the vendor must provide
DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. For a third party, alignment is the question.
| Method | Aligns when | What to ask the vendor |
|---|---|---|
| DKIM | The signing domain matches your From domain | Can we sign with our own domain and selector? |
| SPF | The bounce address domain matches your From domain | Can we set a custom return path on our subdomain? |
DKIM is usually the more reliable route for third parties, because SPF checks the bounce address, and many vendors use their own for it, which will not align with your domain. If the vendor offers just shared domain signing, expect DMARC trouble.
The steps
- Choose the hostname. Use a subdomain for this sender, for example a support or marketing hostname. Reasoning is in our post on separate sending subdomains.
- Publish DKIM. Add the key records the vendor gives you, usually TXT or CNAME entries at a selector under your subdomain.
- Set up the custom return path if offered, so SPF aligns as well.
- Scope SPF. Add the vendor's include to the SPF record of the subdomain, not the apex. Watch the ten lookup limit described in the SPF lookup limit post.
- Send a test to a mailbox you control and open the full headers. Look for dkim=pass and spf=pass, with the domains you expect. See reading authentication results.
- Check DMARC alignment in the same header: dmarc=pass.
- Monitor. Review aggregate reports for the subdomain for at least a few weeks before relying on it.
Guardrails for the process
- Make it a rule that no one connects a sender without a DNS ticket.
- Keep a register: sender, hostname, owner, contract end date, selector names.
- Remove the DNS records when the contract ends. Stale CNAME entries for a vendor you no longer use are a takeover risk, see dangling record audit.
- Rotate DKIM keys on a schedule you can keep.
When the vendor cannot align
Some tools cannot sign as your domain. Options: use a different tool, send from the vendor's domain with a clearly separate identity and accept that it is not your brand, or relax your policy temporarily on that subdomain with a documented end date. Do not lower policy on the whole domain to rescue one tool.
Safeguard's compliance and evidence automation can help you keep records of which third parties handle customer communications. Its focus is software supply chain security, and a free dependency scan is at gold.safeguard.sh/scan.
Quick check
Is SPF enough for a third party sender?
Usually not. SPF aligns when the bounce address uses your domain, which many vendors do not allow by default. DKIM signing with your own domain is more reliable.
Can I add the vendor to my main SPF record?
You can, but it widens who may send as your main domain and eats into the lookup limit. A dedicated subdomain keeps it contained.
Sources
Last reviewed: 19 October 2026.
