Multiple Email Vendors on One Domain: How to Manage SPF, DKIM and DMARC Without Breaking Anything

Running multiple email vendors on one domain is the normal state of most companies, not an exception. A marketing platform sends newsletters, a CRM sends sales sequences, a helpdesk sends ticket replies, a transactional provider sends receipts and password resets, and the office mailbox sends everything else. Each tool was added by a different person at a different time, and each one asks you to paste something into DNS. This guide shows how we keep SPF, DKIM and DMARC working across all of them, so that adding or removing a vendor never turns into a deliverability incident.

Why multi-vendor sending goes wrong

Nothing about authentication stops you from using many vendors. What goes wrong is the slow accumulation of unmanaged DNS. A new tool is connected in a hurry, someone adds a second SPF record because the first one looked untouchable, a vendor is cancelled but its records stay, and nobody remembers who owns the marketing CRM account. Months later, mail from one tool starts failing and the cause is something that changed three vendors ago.

The common failure patterns are predictable, and each one has a clear fix in the rest of this guide.

Failure pattern	What you see	Where this guide fixes it
Two SPF records on the same name	SPF returns a permanent error for every message from that domain	SPF include budgeting
Too many includes	SPF permerror once a vendor adds a nested include	SPF include budgeting
Shared DKIM selector name	One vendor overwrites another vendor key and signatures fail	One DKIM selector per vendor
SPF passes but DMARC fails	The vendor uses its own envelope domain and does not sign with your domain	DMARC alignment per vendor
Unknown sender in reports	Mail you did not authorize passes or fails under your domain	Discovering unknown senders
Orphaned records after cancelling a vendor	Stale includes, selectors and CNAMEs that nobody maintains	Offboarding old vendors

If you need the basics first, our guide to authenticating a sending domain with SPF, DKIM and DMARC covers each record on its own. Here we focus on what changes when there are many senders.

Start with a sender inventory

You cannot manage what you have not listed. Before touching DNS, we build a simple inventory of every system that sends mail using your domain, whether in the From address, the envelope sender or a signature. Keep it in a shared document or sheet, and treat it as the source of truth that DNS must match.

Field	Why it matters	Example value
Vendor and product	Tells you which documentation and console to use	Helpdesk platform
Business owner	The person who can approve changes or cancel the service	Head of customer support
Mail type	Marketing, transactional, support, internal or sales	Support replies
From domain or subdomain	The visible domain DMARC compares against	support.example.com
Envelope (Return-Path) domain	The domain SPF is checked against	Vendor-owned or custom subdomain
DKIM selector and signing domain	Needed to confirm alignment and to rotate keys	Selector s1 for support.example.com
SPF include or IP ranges	Needed for the lookup budget	One include, counted below
Last verified date	Shows when someone last tested a real message	2026-09-30

Do not rely on memory. Ask finance for the list of software subscriptions, ask each team which tools email customers, and check your existing DNS for includes and selectors you cannot explain. Then run a DMARC reporting period, described below, to catch whatever is still missing.

Give vendors their own subdomains

The simplest way to avoid conflict between vendors is to stop sharing a name. If marketing sends from news.example.com, transactional mail from mail.example.com and support from support.example.com, then each name has its own SPF record, its own DKIM selectors and its own reputation history. A complaint spike on newsletters does not drag down receipts, and a broken helpdesk record does not affect the sales team.

• Separate lookup budgets. SPF is evaluated per domain name, so each subdomain gets its own 10-lookup allowance.
• Separate reputation. Mailbox providers track behavior by domain as well as by IP address, so isolating streams protects the important ones. See transactional versus marketing streams.
• Cleaner reports. DMARC reports break down by header From domain, so each vendor becomes easy to read on its own.
• Easier offboarding. Retiring a vendor means deleting records on one subdomain rather than editing the busy apex record.

Keep the office mailbox on the main domain, since that is where people expect to hear from colleagues, and move the high-volume or automated tools to subdomains. Our guide to the sending subdomain strategy goes deeper on naming and brand questions. Remember that a subdomain still needs its own warm-up if it is new, as explained in the warm-up guide.

SPF include budgeting and the 10-lookup limit

SPF is where multi-vendor setups most often break. RFC 7208 allows a domain to publish only one SPF record, and it limits evaluation to 10 terms that cause DNS queries. The include, a, mx, ptr and exists mechanisms and the redirect modifier all count, and so does every lookup inside an included record. The ip4, ip6 and all terms are free. A vendor include that looks like one lookup may expand into three or four, and that expansion can change without notice.

We treat the limit like a budget and spend it deliberately.

1. Resolve each include one level at a time and write down the real lookup cost of every vendor.
2. Total the cost, and keep at least two lookups of headroom for vendor changes.
3. Remove includes for vendors that no longer send, and for mailbox features you do not use.
4. Move high-volume vendors to subdomains so the apex record stays small.
5. Avoid ptr completely, since RFC 7208 discourages it, and avoid mx and a unless they are needed.

RFC 7208 also limits void lookups, meaning queries that return no data, to two. A stale include that points at a name which no longer exists is a good way to hit that limit. If you are already over budget, our guide to fixing the SPF permerror for too many lookups has the repair steps.

What an apex SPF record can look like

This invented example shows a single record for the main domain, where only the office mailbox and one other tool send. Vendor names and include hostnames are placeholders, so use the exact values your vendors publish.

; Apex domain: only the office mailbox and the CRM
example.com.            TXT  "v=spf1 include:_spf.mailbox-provider.example include:spf.crm-vendor.example -all"

; Marketing platform on its own subdomain
news.example.com.       TXT  "v=spf1 include:spf.marketing-vendor.example -all"

; Transactional provider on its own subdomain
mail.example.com.       TXT  "v=spf1 include:spf.transactional-vendor.example -all"

; Helpdesk on its own subdomain
support.example.com.    TXT  "v=spf1 include:spf.helpdesk-vendor.example -all"

Many vendors send with their own envelope domain, so the record on your From domain is not even checked for their mail. Read the vendor setup page before you add an include that is not needed. Adding unnecessary includes only spends budget.

One DKIM selector per vendor

DKIM keys live at a name made of a selector, the label _domainkey and the signing domain, for example s1._domainkey.support.example.com. The selector lets one domain publish many keys at once, which is exactly what a multi-vendor setup needs. Each vendor should sign with a selector of its own, and you should record that selector in the inventory.

• Never reuse a selector name between vendors. Two vendors cannot occupy the same DNS name, and the second record will overwrite or conflict with the first.
• Follow vendor values exactly. Many platforms give you CNAME records so they can rotate the key for you. Others give you a TXT record with a public key. Copy whichever they provide without editing it.
• Sign with your domain. A signature made with the vendor domain does not align with your From domain, so it does not help DMARC.
• Plan rotation per vendor. Separate selectors let you rotate or revoke one key without disturbing the rest. The process is in DKIM key rotation, selectors and key length.

Pick selector names that make ownership obvious, such as a short vendor tag plus a date or number. A name like mkt2026a tells the next administrator more than a name like default.

DMARC alignment, vendor by vendor

DMARC passes when either SPF or DKIM passes and the passing domain aligns with the domain in the visible From header. With several vendors, alignment is the part that differs most from one platform to the next, so we test each one separately instead of assuming. The rules are explained in DMARC alignment: relaxed versus strict.

Vendor behavior	SPF result	DKIM result	DMARC result
Uses your custom return-path domain and signs with your domain	Pass, aligned	Pass, aligned	Pass
Uses vendor envelope domain but signs with your domain	Pass, not aligned	Pass, aligned	Pass through DKIM
Uses your custom return-path domain but signs with the vendor domain	Pass, aligned	Pass, not aligned	Pass through SPF
Uses vendor envelope domain and signs with vendor domain	Pass, not aligned	Pass, not aligned	Fail

The last row is the dangerous one. The vendor reports success, the mail is delivered today, and DMARC quietly fails. It becomes a real problem the moment you move your policy to quarantine or reject. For vendors that support custom return-path and tracking domains, see custom return-path and tracking domains.

To test a vendor, send one real message to a mailbox you control, open the full headers and read the authentication results. Look for spf, dkim and dmarc results and the domains named beside them. Record what you find in the inventory so the next person does not have to repeat it.

Find unknown senders with DMARC aggregate reports

A sender inventory is only as good as what people remember. DMARC aggregate reports show what the world actually sees. Publish a DMARC record with a rua address, and mailbox providers send daily XML summaries listing the sending IP addresses, the volumes and the SPF and DKIM results for mail claiming to be from your domain.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

Start with p=none so that nothing is blocked while you learn. After a few weeks of reports, group the sources and work through each one.

1. Match every sending IP address or reverse DNS name to a vendor in your inventory.
2. For unmatched sources, find the owner. Ask the teams, check old invoices and search mailboxes for sample messages.
3. If the sender is legitimate, add it to the inventory and fix its authentication so it aligns.
4. If it is not legitimate, leave it failing, and use the policy stage later to block it.
5. Repeat monthly, because new tools appear all the time.

A report reader or processing service saves a great deal of time, since raw XML is hard to scan. Once every legitimate source aligns, you can move toward enforcement with the steps in reading DMARC reports and moving to p=reject.

Change control for DNS

Authentication records are small, but a single typo can break mail for a whole department. A lightweight change process costs little and prevents most incidents.

• Request. Every change starts with a ticket naming the vendor, the owner and the reason.
• Review. A second person checks the exact record text, the host name and the lookup count of the resulting SPF record.
• Test. Run the checks before and after, and send a real message through the affected vendor.
• Record. Save the old value, the new value, the date and the person responsible.
• Roll back. Keep the previous value ready, and lower the TTL before a risky change so a rollback takes effect quickly.
• Limit access. Restrict DNS editing rights, and use individual accounts rather than a shared login.

Offboarding a vendor properly

Cancelling the subscription is not the end of the job. Left behind, an old include keeps spending your lookup budget, an old DKIM key remains valid for anyone who may still hold the private key, and an old CNAME can leave a name pointing at a service you no longer control. We follow the same order every time.

1. Stop the sending. Disable campaigns, automations, integrations and API keys inside the vendor account.
2. Watch the reports. Confirm for at least a few weeks that the vendor sources have disappeared from your DMARC data.
3. Remove the SPF include from the relevant record and recount the lookups.
4. Delete the vendor DKIM selector records, and any CNAMEs for tracking, bounce or return-path hosts.
5. Revoke credentials, API keys and user seats at the vendor, and export any data you need to keep.
6. Update the inventory, and keep the old record values in your change log.

Check that a dangling CNAME does not point at a vendor hostname you no longer own, because that kind of record can be misused. Removing it is the safest option.

DNS record hygiene

• One SPF record per name, one DMARC record at the _dmarc name, and no duplicates.
• Use clear, consistent selector names and keep a comment or inventory entry for each.
• Keep TXT values within DNS limits. Long DKIM keys may need to be split into quoted strings, so use your DNS provider guidance.
• Review the whole zone twice a year and compare it with the inventory.
• Use reverse DNS and HELO checks for any servers you run yourself.

A worked example

Take an invented company with five senders on example.com: an office mailbox, a CRM, a helpdesk, a transactional provider and a marketing platform. Its single apex SPF record includes all five. Resolving them gives these costs: the mailbox include costs 3 lookups, the CRM 2, the helpdesk 2, the transactional provider 3 and the marketing platform 2. The total is 12, so SPF returns a permerror and mail from every tool is at risk of failing SPF.

Step	Action	Apex lookups after the step
Start	All five includes on the apex record	12 (over the limit)
1	Move marketing to news.example.com with its own record	10
2	Move the transactional provider to mail.example.com	7
3	Move the helpdesk to support.example.com	5
Result	Apex keeps only mailbox and CRM; each subdomain has its own budget	5 on the apex, with headroom

The company then gives each vendor its own DKIM selector on its subdomain, tests alignment for each one and publishes a p=none DMARC record with a reporting address. After three weeks the reports show one extra source, a forgotten event registration tool sending about 400 messages a month. The owner is found, the tool is authenticated properly, and the company later moves the policy to quarantine with confidence. Total effort: a few hours of DNS work, plus the weeks of observation that made the change safe.

A short checklist

1. A current sender inventory exists, with an owner for every vendor.
2. High-volume and automated vendors send from their own subdomains.
3. Each name has exactly one SPF record, with at most 10 lookups and some headroom.
4. Each vendor signs with its own DKIM selector using your domain.
5. Each vendor has been tested, and DMARC passes with alignment through SPF or DKIM.
6. DMARC aggregate reports are collected and reviewed at least monthly.
7. DNS changes follow a written process with a rollback value.
8. Cancelled vendors have had their includes, selectors, CNAMEs and credentials removed.

This article is general information about email authentication, not legal or compliance advice.

Further reading and sources

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)