The first marketing campaign usually works. So does the new payroll platform. Then the security team moves DMARC to enforcement. Then an invoice, password reset, or support reply disappears.
That’s the third-party sender problem in miniature. Organizations want to stop attackers from spoofing their domains without blocking the vendors that keep the business running. The answer isn’t to choose between security or deliverability, but to prove each legitimate mail stream is authorized to use the domain recipients see.
A reliable program starts with a complete inventory, gives each sender an alignment strategy, and raises enforcement only after real traffic confirms the design works.
Authentication passes aren’t the same as DMARC alignment
SPF, DKIM, and DMARC answer related but different questions. Third-party implementations go wrong when a team sees “pass” beside SPF or DKIM and assumes the message is protected.
SPF checks the sending path
SPF asks whether the sending IP is authorized for the domain in the envelope-from address, often shown as the Return-Path. A vendor can pass SPF using its own bounce domain. That proves the vendor authorized the IP, but it doesn’t necessarily connect the message to your visible From domain.
DKIM checks the signature
DKIM uses a cryptographic signature to associate a message with the domain in the signature’s d= value. It often survives forwarding better than SPF because it doesn’t depend on the last sending IP. But a valid signature under the vendor’s domain may still do nothing for your DMARC result.
DMARC checks the identity recipients see
DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. You need at least one aligned pass, but not necessarily both.
Relaxed alignment allows a subdomain and its organizational domain to align; strict alignment requires an exact match. Relaxed alignment gives most organizations the flexibility they need to segment third-party mail by subdomain.
Practical takeaway: For most vendors, aligned DKIM under a domain you control is the most durable foundation. Add aligned SPF when the vendor can support a custom Return-Path cleanly.
Find the senders your configuration spreadsheet missed
You can’t authenticate a sender you don’t know exists. Vendor lists are a start, but they rarely capture every application, regional account, test environment, and business-led tool using the company’s domain.
Build the inventory around mail streams, not just vendor names. One platform may produce marketing campaigns, transactional messages, and employee notifications with different From addresses and authentication behavior.
For each stream, record:
- The business purpose and owner
- The visible From domain and address pattern
- The envelope-from or Return-Path domain
- The DKIM signing domain and selector
- Whether the vendor supports custom DKIM, a custom Return-Path, dedicated subdomains, and key rotation
- Whether a gateway or downstream service rewrites headers, links, footers, or message bodies
- The stream’s volume, audience, and impact if mail is delayed or blocked
Then test reality. Send a message through each production path and inspect the headers received by representative mailbox providers. DMARC aggregate reports can reveal sources at scale, but a header sample tells you how a specific message authenticated after every relay and rewrite.
Practical takeaway: Treat the inventory as a living control. Give every stream an owner, a review date, and an offboarding step so abandoned vendors don’t remain authorized forever.
Use subdomains to contain risk and simplify ownership
A purpose-built subdomain gives a third-party stream room to operate without sharing every control and reputation signal with your primary domain. Marketing might use marketing.example.com, product notifications might use notify.example.com, and billing might use billing.example.com.
Segmentation makes several jobs easier. Teams can publish narrower SPF records, assign DKIM selectors to a single platform, monitor a stream separately, and change policy without disturbing unrelated mail. If a vendor account is compromised or misconfigured, the impact is less likely to spread across every sender using the brand.
A new subdomain may need a measured volume ramp while mailbox providers build reputation signals. That’s a migration issue, not a reason to avoid segmentation. Keep the From identity, cadence, and content stable, and avoid moving a high-volume program in one abrupt cutover.
Practical takeaway: Don’t put unrelated vendors on the same subdomain just because it’s convenient. A subdomain works best when its purpose, owner, and sender set are clear.
Delegate only what the vendor needs
Third parties need enough DNS configuration to authenticate their mail, but they don’t need a blank check over your domain.
Keep SPF narrow
SPF evaluation allows no more than 10 DNS-querying mechanisms. A parent-domain record packed with vendor include statements can cross that limit and become hard to audit. Use one SPF record per domain, remove sources that no longer send, and publish vendor-specific authorization at the subdomain used by that stream when possible.
A custom Return-Path under your domain can provide SPF alignment. If the vendor can’t support one, don’t build a fragile workaround just to force SPF to align. Make DKIM the primary DMARC path.
Sign with a domain you control
Configure the vendor to sign with your domain or purpose-built subdomain in the DKIM d= value. Vendors often call this custom DKIM or domain authentication. You publish the public key in DNS while the vendor holds the corresponding private key and signs the messages it sends for you.
Track each selector, vendor, owner, key length, and rotation status. Rotate keys with an overlap period so the new public key is available before the sender switches. Remove old selectors when the transition is confirmed.
Protect the signature after it’s applied
A valid DKIM signature can break if a downstream system changes signed content. Gateways that add disclaimers, mailing lists that modify subject lines, and services that rewrite message bodies can all create failures. Sign as late as practical, minimize downstream modification, and test the full route.
Raise DMARC enforcement without a leap of faith
DMARC enforcement should follow evidence. Begin by collecting reports and identifying legitimate sources. Remediate each stream until critical mail consistently passes through an aligned SPF or DKIM path. Then increase policy in controlled stages.
- Prioritize password resets, identity messages, invoices, payroll, and customer support before lower-impact campaigns.
- Choose a change window outside peak sending periods.
- Use DMARC reports, delivery metrics, and received headers together; no single view tells the whole story.
- Define a rollback trigger, but diagnose the failing stream before weakening policy for the entire domain.
- Keep temporary exceptions narrow, owned, monitored, and time-bound.
Forwarding can break SPF because the forwarder’s IP isn’t authorized by the original sender. DKIM may survive if the message remains unchanged, which is another reason to prioritize a strong aligned DKIM path.
Practical takeaway: Enforcement is the finish line for a well-understood sender program, not the opening move.
What to look for in a delivered message
Open the raw headers from a message that traveled through the real production path. The receiver’s Authentication-Results header should show dmarc=pass for the visible From domain. Behind that result, confirm at least one of these paths:
- spf=pass and the envelope-from domain aligns with the visible From domain.
- dkim=pass and the DKIM d= domain aligns with the visible From domain.
Also compare the From, Return-Path, and DKIM-Signature headers with the design you documented. Multiple DKIM signatures can be normal, but at least one aligned signature must remain valid at delivery.
If DKIM fails, look for content changes after signing, selector mismatches, or missing DNS records. If SPF passes but DMARC fails, check alignment rather than adding more IPs. If authentication changes between test and production mail, find the additional route or platform configuration responsible.
Make every sender earn the right to use your domain
Third-party authentication becomes manageable when each stream has a clear identity and owner. Discover the real senders, segment them by purpose, give each one an aligned DKIM or SPF path, and verify the result in delivered mail. Then raise DMARC enforcement based on evidence.
That approach protects inbox placement and makes impersonation harder without forcing teams into a false choice between security and business-critical email.
Valimail helps teams discover third-party senders, monitor authentication changes, and move domains toward DMARC enforcement with fewer delivery surprises. Get started with Valimail Monitor for free.
Frequently asked questions
Should we rely on SPF or DKIM alignment for a vendor?
Use the method the vendor can support reliably. Aligned DKIM is usually the stronger primary path because it isn’t tied to the last-hop IP and can survive forwarding. Configure aligned SPF as a second path when the vendor supports a custom Return-Path without adding unnecessary complexity.
Will moving mail to a subdomain hurt deliverability?
A new subdomain may begin with limited reputation, so an abrupt high-volume migration can cause fluctuations. Ramp volume thoughtfully and keep sending patterns stable. Over time, segmentation can protect the reputation of critical mail and make authentication easier to manage.
What if a vendor can sign only with its own domain?
If the vendor can’t provide an aligned DKIM domain or Return-Path, mail using your visible From domain can’t pass DMARC through that setup. Ask about a supported custom-domain tier, use a properly delegated subdomain, change the visible From identity, route through infrastructure you control, or choose a vendor that supports your enforcement requirements.
What’s the most common enforcement mistake?
Moving to quarantine or reject before the sender inventory is complete. The missing source is often an old regional tool, an internal application, or a second transactional path hidden behind a familiar vendor name.
