Quick multi-ESP DKIM reference
A single domain that sends from multiple email service providers (marketing ESP, transactional ESP, Google Workspace or Microsoft 365, internal MTAs) needs a separate DKIM selector for each sender. Selectors are independent namespaces under the same domain. Each ESP signs with its own selector and the receiver validates each signature independently.
| Why this is needed | Each ESP signs with its own private key. The receiver must find the matching public key in DNS, which lives at a selector-specific subdomain |
| Key concept | One domain, many selectors, each with its own DKIM public key in DNS |
| Typical setup | 3 to 6 selectors for a midsize B2B sender (marketing, transactional, employee mail, support, sales tooling, occasional batch sends) |
| SPF coordination | SPF must include all sending sources too, which is the harder constraint (10 DNS lookup limit) |
| DMARC implication | Each sender must align with the parent domain (or an authorized subdomain) for DMARC to pass |
The scenario: one domain, many senders
A modern company rarely sends all its email from one place. A realistic mid-size B2B sender typically uses:
- Google Workspace or Microsoft 365 for employee mail (alice@example.com, bob@example.com)
- A transactional ESP for product notifications, password resets, receipts (often Mailgun, Postmark, Amazon SES, Resend)
- A marketing ESP for newsletters and campaigns (often Mailchimp, Klaviyo, Brevo, Customer.io)
- A sales engagement tool for outbound sequences (Outreach, Salesloft, Apollo, Lemlist)
- A support platform for ticket replies (Zendesk, Intercom, Help Scout)
- Occasionally an analytics or product platform sending event-driven mail (Customer.io, Iterable, sometimes branded as the marketing ESP)
All of these send mail “from example.com” but each operates its own infrastructure with its own DKIM keys, its own IP ranges, and its own deliverability profile. The challenge is to make DMARC pass cleanly for all of them without breaking when you add or remove an ESP.
The DKIM selector concept
A DKIM signature includes two parameters that identify which public key to use for verification: the domain (d=example.com) and the selector (s=mailgun_2024). The receiver constructs a DNS query at selector._domainkey.domain (so mailgun_2024._domainkey.example.com) and fetches the public key from there.
Selectors are independent. There is no limit on the number of selectors a domain can have; each one is just a different DNS record at a different name. Each ESP publishes a key under its own selector, and the same domain can have dozens of selectors active simultaneously.
This is the key insight: you do not need to combine keys, share keys between ESPs, or pick “the one DKIM key for the domain”. You add a selector per sender, and DKIM scales horizontally.
Setup walkthrough: a 3-ESP example
Say you are setting up DKIM for example.com sending from Mailgun (transactional), Mailchimp (marketing), and Google Workspace (employees).
Step 1: Get the DKIM keys from each ESP
Each ESP provides DNS records to add. The format varies slightly:
- Mailgun: Selector typically
k1or a custom name you choose; the ESP shows you “Add this TXT record atk1._domainkey.example.com“. - Mailchimp: Selector is
k1by default. CNAME pointing to a Mailchimp-hosted DNS record (so Mailchimp can rotate keys without your involvement). - Google Workspace: Selector is typically
google(default) or20240101(year-based when you regenerate). TXT record atgoogle._domainkey.example.com.
Step 2: Choose unique selectors
If two ESPs both default to k1, you have a conflict. Rename one to something distinct: mailgun_2026, mailchimp_main, google_default. Most ESPs let you customize the selector name; if not, ask their support.
Step 3: Publish the DKIM TXT records
Three TXT records at three different names:
mailgun_2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb..."
mailchimp_main._domainkey.example.com. CNAME k1.mailchimpkeys.example.com.
google_default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."Step 4: Test each one
Send a test message from each ESP to a Gmail or Yahoo address you control. Check the message’s raw headers for the DKIM-Signature: field. Then check Authentication-Results: for the corresponding dkim=pass d=example.com entry. If any one fails, the public key DNS record is wrong (most common cause: typo in the key or the record was added at the wrong name).
Step 5: Add to SPF
DKIM is now passing for each sender, but DMARC also requires SPF alignment for the message to fully pass. Update your SPF record at example.com to include each ESP’s SPF directive:
example.com. TXT "v=spf1 include:_spf.mailgun.org include:servers.mcsv.net include:_spf.google.com ~all"Be careful about the SPF 10-DNS-lookup limit: each include: counts as one lookup, and many ESPs’ included records themselves include more, so a 4-ESP setup can easily exceed 10. See our future SPF flattening guide for how to handle this.
Step 6: Monitor with DMARC reports
Once SPF and DKIM are configured for all senders, your DMARC aggregate reports should show every legitimate source passing. Watch reports for 2 to 4 weeks; any source still failing is either a misconfiguration (the most common case) or unauthorized mail (a security issue).
DMARC alignment for multi-ESP setups
DMARC requires alignment between the From header domain and either the SPF authenticated domain or the DKIM signing domain (it only needs one to align, not both). For multi-ESP setups, this means:
- DKIM alignment: If each ESP signs with
d=example.com(your domain), DKIM aligns automatically. This is what you want. - SPF alignment: The envelope sender (Return-Path) must be at example.com (or a subdomain in relaxed mode). Many ESPs use their own Return-Path by default (bounces@mailgun.org, etc.) which fails SPF alignment. To fix: configure a custom Return-Path domain like
bounces.example.comthat points to the ESP’s bounce-handling infrastructure.
In practice, you get DKIM alignment for free when each ESP signs with your domain. SPF alignment requires the additional step of setting up custom Return-Path domains, which is well-documented at most ESPs but often forgotten. If your DMARC reports show “spf=pass” with a non-aligned domain (the ESP’s bounce domain), you have this gap.
DKIM key rotation strategy
DKIM keys should be rotated every 12 months at minimum, more often for high-security domains. The pattern that scales for multi-ESP setups:
- Each ESP rotates its own keys independently. You don’t synchronize across ESPs.
- Use date-based selector names. Instead of
mailgun_2026, when rotating usemailgun_202607for the July 2026 key. This makes the next rotation a fresh selector, not an overwrite. - Add the new selector before removing the old one. ESPs that handle rotation natively (Mailchimp via CNAME, Google Workspace) do this automatically. For self-managed records, publish the new key, wait 48 hours for propagation, switch the ESP to sign with the new selector, run for another 48 hours, then remove the old TXT record.
- Watch DMARC reports during rotation. If
dkim=failrate spikes for that ESP, the rotation didn’t propagate cleanly; investigate before continuing.
10 common multi-ESP DKIM mistakes
- Two ESPs using the same selector name. Both default to
k1; you publish one TXT record and break the other. Rename one selector before publishing. - Typo in the public key. DKIM keys are long base64 strings. A single character off and validation fails silently (no error, just
dkim=fail). Always copy-paste from the ESP’s UI, never retype. - Publishing the key at the wrong subdomain. Must be at
SELECTOR._domainkey.DOMAIN. Common errors:SELECTOR._dkim.,_domainkey.SELECTOR., or justSELECTOR.alone. - Forgetting to update SPF. DKIM passes but SPF fails, breaking DMARC alignment. SPF and DKIM are companion checks; both need to be coordinated.
- Exceeding the SPF 10-DNS-lookup limit. Each ESP’s SPF include can cascade into multiple lookups. A 5-ESP setup easily exceeds 10 and SPF starts failing across all sources.
- Default Return-Path domain at the ESP. The bounces go to
bounces@mailgun.orginstead of your domain, which fails SPF alignment. Configure a custom Return-Path domain at each ESP that supports it. - Removing an old selector before fully migrating. Old messages in transit still reference the old selector. Wait 48+ hours after switching before deleting the old record.
- Not testing each ESP independently. Send a test from each one and check headers. Don’t trust the ESP’s “DKIM is configured” green checkmark; verify with a real send.
- Mixing 1024-bit and 2048-bit keys. Not strictly wrong, but inconsistent. Most modern ESPs offer 2048-bit; pick that for all unless your DNS provider has strict size limits.
- Not monitoring DMARC reports for new sources. A new department signs up for a SaaS that sends email “from your domain” without DKIM. Your DMARC reports flag it; if you don’t read them, you don’t know.
Multi-ESP DKIM FAQ
Can multiple ESPs share the same DKIM key?
Technically yes (you could give the same private key to every ESP), but practically no. Each ESP manages its own private key as part of its security model. Sharing a key creates audit and rotation problems, and most ESPs won’t let you import an external key. The right pattern is one selector per ESP, each with its own key pair.
How many DKIM selectors can a domain have?
No protocol limit. Each selector is a separate DNS record. Typical mid-size B2B senders run 3 to 6 selectors; large enterprises with many tools can have 20 or more. DNS providers handle this fine; the practical constraint is operational discipline (tracking what each selector is for, when to rotate, when to remove).
What happens if one ESP’s DKIM fails but others pass?
Messages from the failing ESP fail DKIM (and potentially DMARC), while messages from the other ESPs continue to pass. The impact is per-source, not per-domain. Fix the failing ESP’s selector and DMARC reports return to clean. This is one of the reasons multi-ESP setups are more robust than single-ESP setups: a problem with one provider doesn’t affect mail from the others.
How do I know which selector signed a given message?
Look at the message’s raw headers. The DKIM-Signature: field includes s=SELECTOR; d=DOMAIN. So a header showing s=mailgun_2026; d=example.com tells you the message was signed by Mailgun using your domain’s mailgun_2026 selector. This is the fastest way to trace a deliverability issue back to a specific sending source.
Should I use 1024-bit or 2048-bit DKIM keys?
2048-bit. The cryptographic advantage is real, modern DNS providers handle the longer record without issue, and most major receivers prefer or require 2048-bit since 2020. 1024-bit still validates but is deprecated. New deployments should always use 2048-bit; existing 1024-bit deployments should rotate to 2048-bit at the next scheduled key rotation.
How do I clean up old DKIM selectors after switching ESPs?
Wait at least 7 days after fully migrating mail to the new ESP (in case any retries or queued messages still use the old selector). Then delete the old TXT record. Watch DMARC reports for the next week to confirm no source is still trying to sign with the deleted selector. If you see dkim=fail with the old selector, some forgotten system is still using it; track it down before assuming the cleanup is complete.
Final words
Multi-ESP DKIM is not a complicated topic technically; it is mostly bookkeeping. The number of selectors grows with the number of senders, and the discipline you need is the discipline of tracking what each selector is for, who owns it, when to rotate it, and when to remove it. A DNS hygiene problem rather than a cryptography problem.
The systemic risk in multi-ESP setups is not DKIM itself but SPF and DMARC alignment. Watch the SPF 10-lookup limit, watch for non-aligned bounce domains at each ESP, and read DMARC aggregate reports monthly. The reports surface every sender failing alignment, including ones you didn’t know existed.
For broader context, see our guides on DKIM, SPF, DMARC, and the Deliverability hub.
Clean your list before you send.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
