When a third-party service — Mailchimp, SendGrid, Salesforce, Zoho — sends email as your domain, DKIM needs to be configured so that messages are signed with your domain's key rather than the provider's. This article explains why that matters for DMARC alignment, how CNAME-delegated DKIM works, the pattern across every major UK-relevant provider, and how to audit the end result.
Imagine a Leeds accountancy sends its marketing newsletter through Mailchimp. By default, Mailchimp's outbound mail server signs every message with Mailchimp's own DKIM key — d=mcsv.net or similar. The message arrives at the recipient with:
From: [email protected] — the visible sender.DKIM-Signature: d=mcsv.net; s=k1; ... — the authenticating domain.DKIM verification passes (the signature is mathematically valid). SPF passes (Mailchimp's servers are in Mailchimp's SPF, and the envelope sender is on a Mailchimp domain). But DMARC fails, because mcsv.net does not align with firm.co.uk.
For a domain publishing p=reject, this means every Mailchimp newsletter gets rejected by Gmail, Outlook and every receiver that honours DMARC. The solution is to configure Mailchimp to sign with d=firm.co.uk — using a key the accountancy controls (or that Mailchimp controls on the accountancy's behalf through CNAME delegation).
DMARC's alignment check is what makes SPF and DKIM meaningful at the From:-header level. Without alignment, an attacker could send a spoofing email that passes SPF on their own domain (which has its own valid SPF) and have DMARC pass trivially. Alignment requires the authenticated domain to match the visible sender.
Two alignment modes:
bounces.firm.co.uk aligns with firm.co.uk because they share firm.co.uk.bounces.firm.co.uk does not align with firm.co.uk.Either way, mcsv.net does not align with firm.co.uk. The only solution is to get the third party to sign with your domain.
The elegant modern solution is CNAME delegation. You publish a CNAME in your DNS pointing at the provider's DKIM record:
k1._domainkey.firm.co.uk. IN CNAME dkim.mcsv.net.When a receiver looks up k1._domainkey.firm.co.uk, DNS follows the CNAME to dkim.mcsv.net, which resolves to the actual DKIM TXT record. The signature itself has d=firm.co.uk, so DMARC alignment works.
Benefits of CNAME delegation over publishing the key yourself:
The trade-off: the provider controls the key material. If you lose trust in the provider, removing the CNAME is effectively the only way to revoke their authority. Most UK businesses accept this — it is the same trust they already extend by letting the provider send email on their behalf.
k1._domainkey and k2._domainkey pointing at Mailchimp's key infrastructure.d=firm.co.uk.d=firm.co.uk.d=firm.co.uk.d=firm.co.uk.d=firm.co.uk.d=firm.co.uk going forward.Microsoft 365 is a hosted provider but sending happens as your own domain — the DKIM setup is two CNAMEs you publish as described in the DKIM setup tutorial. Not a "third-party" pattern in the classical sense, but operationally similar.
For high-volume senders, many providers recommend a dedicated sending subdomain. Rather than signing as firm.co.uk, you send from marketing.firm.co.uk and configure DKIM on that subdomain.
Benefits:
[email protected] and know it is bulk mail rather than human correspondence.p=quarantine while the main domain has p=reject, allowing different risk tolerances per sender class.The trade-off is additional DNS management — one more subdomain to configure and maintain. Most UK marketers consider this worthwhile at moderate or high volume.
A UK business with Microsoft 365 plus Mailchimp plus SendGrid ends up with three DKIM signatures being produced, all signing as firm.co.uk but with different selectors:
selector1._domainkey.firm.co.uk and selector2._domainkey.firm.co.uk — Microsoft 365.k1._domainkey.firm.co.uk and k2._domainkey.firm.co.uk — Mailchimp.s1._domainkey.firm.co.uk and s2._domainkey.firm.co.uk — SendGrid.All six selectors coexist in DNS. Whichever provider signs a particular message, its signature verifies against the correct selector and aligns with firm.co.uk. No conflict between providers.
In practice this works smoothly — selectors are chosen by the signer, checked by the receiver, and the multi-provider setup is invisible to users.
A quarterly audit of your third-party DKIM configuration:
DKIM-Signature header — d= must equal your domain.Authentication-Results on the received test shows dkim=pass.The provider's admin console shows "pending authentication" or similar. The generated records were never added to DNS. Solution: publish the CNAMEs.
Common mistake: the provider says to publish k1._domainkey.firm.co.uk and the admin publishes the record at k1.firm.co.uk (missing _domainkey). DNS lookup fails. Solution: fix the name.
Very occasionally a provider rotates their DKIM infrastructure and asks customers to update CNAME targets. Ignore this at your peril — messages will start failing verification within days.
Some DNS UIs quietly auto-append the zone to CNAME targets that end with a trailing dot, or strip them and auto-append. The resulting CNAME points at the wrong target. Solution: verify with dig.
When a provider rotates, receivers may temporarily see cached responses from old records. Usually resolves within TTL; if not, flush caches or wait.
Some low-cost providers sign all outbound with the same d=provider.com regardless of customer. These services cannot produce DMARC-aligned signatures for your domain. Either migrate to a provider that supports custom domain authentication, or disable the affected channel.
A minority of services simply cannot align. Typical examples:
Three options:
subdomain.firm.co.uk with p=none and use the provider there. The main domain keeps p=reject.Campaign Monitor (UK-founded), dotdigital (UK), and Pure360 all support full custom-domain DKIM authentication. Configuration follows the CNAME-delegation pattern documented above.
Public sector UK senders using GOV.UK Notify sign with d=notifications.service.gov.uk. To achieve alignment, use a subdomain under your organisation's domain and follow the Cabinet Office guidance.
Clinical mail via NHS.net signs with d=nhs.net. Alignment is handled centrally by the NHS mail team; NHS suppliers do not need to configure DKIM for NHS.net traffic.
Academic list server. Lists sign with their own DKIM on the list's domain; subscribers' DMARC policies interact via From-rewriting rather than alignment. See SPF and Email Forwarding.
d=firm.co.uk and your own selectors — no third-party alignment issues. The platform handles SPF, DKIM and DMARC alignment automatically. You get the same behaviour as running your own mail server, without the operational overhead.
All providers sign with d=firm.co.uk, each using their own selectors. Six to ten DKIM selectors in DNS is normal. DMARC aligns on whichever provider signed a given message.
Pros: single DMARC policy, unified reporting, simpler recipient mental model.
Cons: one provider's compromise could allow signing as any department.
Marketing from marketing.firm.co.uk, transactional from invoices.firm.co.uk, staff mail from firm.co.uk. Each subdomain has its own DKIM, SPF and DMARC.
Pros: reputation isolation, different policies per sender class, cleaner recipient distinction.
Cons: more DNS records, risk of users confused by multiple sender domains.
Rarely used: Mailchimp sends from mailchimp.firm.co.uk, signed as that full subdomain. DMARC on the parent permits this via organisational-domain alignment.
Pros: explicit provider attribution in sender address.
Cons: recipients may find sender address odd; not commonly used in UK business mail.
Start with Pattern 1 (one domain, many providers). Graduate to Pattern 2 when marketing volume grows enough that reputation isolation matters (typically 50,000+ messages per month). Pattern 3 is niche and rarely the right choice.
Configuring a third party to sign as your domain authorises them to send mail that will DMARC-align with your domain. That is a meaningful permission. Some implications:
Q: Does CNAME-delegated DKIM count against the DNS lookup limit?
A: No — DKIM verification costs one lookup per DKIM-Signature header, independent of SPF's 10-lookup ceiling. Multiple CNAME-delegated DKIMs from different providers do not compound.
Q: Can I use my own DKIM key for a third-party provider?
A: Only if the provider supports this model (most do not). The industry default is CNAME delegation — the provider manages the key. If a provider does support "bring your own key", you take on the rotation burden.
Q: What happens if I publish DKIM CNAMEs for a provider I later stop using?
A: The DKIM records in DNS become orphaned but harmless. Any message signed with those selectors (from the provider's other customers) will verify. The risk is low — the provider's other customers would be sending as your domain only if they were spoofing, and any spoofing would still fail SPF. Good housekeeping: remove CNAMEs you no longer use.
Q: Can I sign with both my own DKIM key and a third-party's simultaneously?
A: Yes. Each DKIM-Signature header is independent. A common pattern is your main mail platform plus a third-party marketing service — both sign with d=firm.co.uk using different selectors, and DMARC aligns on whichever one applies to each message.
Q: How do I tell whether a received message came from a third-party sending on my behalf?
A: Look at the Received: headers and the selector in the DKIM-Signature header. The selector names typically reveal the signer (mailchimp.k1, sendgrid.s1, selector1 for Microsoft 365). Cross-reference against your documented sender inventory.
Q: Does third-party DKIM authentication cost extra?
A: For most providers, no — it is included in standard plans. A small number of low-tier providers lock custom-domain authentication behind a paid upgrade, which is usually inexpensive and absolutely worth paying for.
Q: What if my DNS provider does not support CNAMEs at non-root names?
A: Any modern UK DNS provider supports CNAME at any depth. If yours does not, migrate. CNAMEs at subdomains like k1._domainkey are universal.
Q: Can I use a wildcard CNAME for DKIM?
A: Not usefully. DKIM selectors need specific records — a wildcard would match every possible selector name, which is ambiguous. Always use explicit named CNAMEs matching exactly the selectors the provider configures.
Q: If DKIM authentication fails at the provider, can I still send through them?
A: The provider still delivers the mail, but without aligned authentication your DMARC policy will cause it to fail on receivers. The mail lands in spam or is rejected. Fix the authentication first, then rely on the channel for meaningful delivery.
Q: Do I need to re-authenticate all third parties after rotating my own domain's DKIM?
A: No. Your main DKIM rotation is independent of third-party CNAME-delegated DKIMs. Each is a separate selector, each rotates on its own schedule.
Q: Can a third party send from my domain without DKIM authentication?
A: Technically yes — the mail is delivered but unaligned, and under DMARC enforcement receivers reject it. Functionally: no, a provider without DKIM authentication cannot produce mail that reaches UK inboxes at any meaningful rate.
Q: What if a provider publishes their DKIM key as TXT rather than via CNAME?
A: Occasionally — notably Zoho and Postmark. You paste the TXT record directly into your DNS. The effect is identical to CNAME-delegation but with a slightly different operational model: the provider cannot rotate the key without asking you to republish. Most modern providers prefer CNAME for this reason.
Q: How does GDPR interact with third-party DKIM?
A: Authorising a third party to sign as your domain is effectively delegating mail-sending authority. Under UK GDPR, third-party senders processing personal data on your behalf are data processors and require a Data Processing Agreement. DKIM delegation is one signal that such a relationship exists — ensure your DPA is in place.
Q: Is a provider who refuses to support custom-domain DKIM worth using?
A: Rarely in 2026. Every reputable mail-sending service now supports it. A provider that does not either has an obsolete product or is not taking deliverability seriously — either way, a poor choice for UK business mail.
Q: What does "shared IP, shared DKIM" mean and should I use it?
A: Some low-end email providers use a single DKIM key signing for all their customers. The resulting signature does not align with any individual customer's domain. Avoid these services; they cannot produce DMARC-aligned mail for your domain.
Q: If my provider publishes multiple CNAME targets, which do I use?
A: Publish all of them. Each CNAME points at a separate selector; the provider rotates between them on its own schedule. Leaving any out means some percentage of your mail fails verification.
Q: Does DMARC alignment work if one of my DKIM signatures aligns and another does not?
A: Yes — DMARC passes if any one DKIM signature aligns. Multiple signatures coexist; only one needs to align.
Q: How long does it take for a third-party DKIM configuration to be verified after DNS publication?
A: Usually minutes to a few hours. DNS propagation at normal TTLs is fast. If the provider's dashboard still shows "pending" after 24 hours, the records are almost certainly at the wrong name or malformed.
Q: What happens if I remove a third-party's DKIM CNAMEs but they continue to try to send as my domain?
A: Their messages lose DKIM alignment. Under DMARC enforcement (p=quarantine or p=reject), receivers treat those messages as unauthenticated and reject or junk them. This is the intended behaviour — revoking DKIM delegation effectively stops the provider from sending authenticated mail as your domain.
Q: Do I need separate third-party DKIM setups for each of my domains?
A: Yes. Each domain is authenticated independently. If you publish marketing from both firm.co.uk and firm-consulting.co.uk, each needs its own set of DKIM CNAMEs or TXT records for each provider that signs on its behalf.
Q: What is the most common third-party DKIM deployment error in UK SMEs?
A: Configuring a provider in its admin console, but never publishing the DNS records the provider generated. The provider's dashboard shows "setup complete" because you clicked the button, but the actual DKIM authentication silently fails. Always confirm both sides: provider admin says verified AND the DNS records resolve correctly when queried with dig.