Can some newsletter tool send email as your CEO? Probably yes.
"Please set up the following TXT record on your domain:
`mailchimp1._domainkey.p-square.digital IN TXT "v=DKIM1; k=rsa; h=sha256; p=MII...."`"
This is a request I have seen hundreds of times come in from external vendors.
And it is good, right? Making my email more secure?
Sort of - but if I put this DNS record into my zone, I have just handed cryptographic signing rights for my entire domain to another company.
That company can now send email as jens.hoffrichter@p-square.digital, or ceo@p-square.digital - without my knowledge, without anyone noticing. Because those emails are legitimate. Cryptographically signed. Passing every check.
Try proving I didn't send them.
What DKIM actually does
What you just published in DNS is the cryptographic public key for DomainKeys Identified Mail (DKIM). The other side - Mailchimp in this example - holds the corresponding private key. They use it to sign outbound emails on your behalf. Receiving mail servers retrieve the public key from DNS, verify the signature, and confirm the email came from an authorized sender.
(DNSSEC should be mandatory here - but that's a separate article.)
DKIM is no longer optional. Google and Microsoft now require it for delivery to Gmail and Outlook.com. If you also run DMARC - as you should - DKIM becomes a hard requirement.
What is not immediately visible, and what most people don't think about: DKIM works on the domain level. You cannot limit signing rights to specific email addresses, and whoever holds the private key can sign mail as *any* address on that domain.
That SaaS vendor should send out e-mails for a single sender address, or for a limited number of addresses - but now they can send out legitimate e-mails from *any* address in your domwin.
Note that I am in no way implying here that Mailchimp as a vendor is doing anything wrong. They make their platform work. It is on the company who uses the service to make sure they don't expose themselves. Mailchimp is only fulfilling what the customers request.
Why the real impact of this change is often hidden
Most teams treat DKIM setup as routine DNS configuration. Marketing requests a record, DNS publishes it, done. Nobody stops to read what they've actually authorized.
I've had this conversation many times during my time as hostmaster and postmaster at a large automotive OEM. Because I was both, I knew the tensions between the different goals here, and could weigh in.
The discussion had been going in circles for months: is it acceptable to share DKIM keys with SaaS vendors? Security said no. Legal said maybe. IT said it depends on the vendor.
The debate ended when I made it concrete: if your SaaS software holds the DKIM private key for your primary domain, they can send authenticated email as your CEO.
Should this vendor be able to do that? No. Would SPF, DKIM, and DMARC all pass? Yes. Would a security team or security tool be able to tell the difference from a legitimate email? No, because you have given them every indication that this is a legitimate e-mail. For all intents and purposes this *is* a legitimate email.
But even your own security team has no way of finding out which mails were sent, to which recipients, how many were there. Because those e-mails never touch your own infrastructure. You get notified when the complaints start pouring in, or the reputation of your e-mail domain drops to nothing.
This was the end of that discussion.
The result was a clear policy: DKIM private keys for primary email domains are to remain exclusively on the company's own SMTP gateway, with no exceptions.
Why the problem persists anyway
Even when the risk is understood, the situation rarely improves on its own. This topic lives in a Bermuda triangle between three teams:
- Email admins don't want to own it - it's not their system sending the mail
- DNS teams treat it as routine - "just another record"
- Marketing is happy - it makes their campaigns work
Nobody audits which vendors currently hold signing authority. Nobody revokes keys from vendors no longer under contract. The number of external parties with signing rights for your primary domain grows quietly over time.
The only acceptable solution
If your primary email domain's DKIM keys belong exclusively on your SMTP gateway, either your own, or your primary e-mail service, external vendors have exactly two options:
Use a subdomain or dedicated sending domain
Run marketing and bulk email from a dedicated domain - news.company.com or company-newsletter.com. This completely isolates signing authority from your primary domain.
Marketing will push back on this - they want to send from a personal, recognizable sender address, and that's understandable, but weigh that preference against handing signing authority for your primary domain to a SaaS vendor's shared infrastructure.
Use an SMTP relay you control
Route external bulk email through an SMTP service you operate, where you control which sender addresses are permitted. Many bulk email platforms support external SMTP, which means the vendor handles delivery logic while your gateway holds the keys.
Microsoft 365 is a poor fit here - it imposes hard limits on bulk sending (around 10,000 emails per hour per address, 1,000 recipients per hour at last check) that conflict with typical campaign volumes, and not all bulk email platforms support external SMTP at all, so this constrains vendor selection.
Neither option is without friction, but both keep signing authority where it belongs.
I have been accused of being radical in my views about this before, that this is a stance which is too extreme. I beg to differ, as the reputation and security of my company and my customers should be protected where there are reasonable alternatives. And those exist here.
So any newsletter tool can send from my domain?
Of course not. Only those you have previously authorized.
But in my time in this very specialized niche, I have yet to come across an audit of these records. They are there, usually they don't hurt anyone. Most of the time, it is not even easily visible who has requested this record.
Leaving it in costs you nothing. Deleting it might break something, and some marketing manager suddenly breathes down your neck because you have broken his campaign.
So the record stays in, because it is the frictionless solution.
Key Takeaways
- Publishing a DKIM key is granting signing authority for your entire domain - any address, any message
- There is no way to restrict DKIM rights to specific email addresses
- Every external vendor with a DKIM key for your primary domain can send authenticated email as anyone in your organization
- The concrete question that ends the debate: should [vendor] be able to send email as your CEO, passing all authentication checks?
- The policy answer is straightforward: DKIM keys for primary domains belong on your own SMTP gateway - external vendors use a subdomain or your relay
- Audit your current DKIM records regularly, to see if they are still in use
Conclusion
Whether or not a vendor should be able to send email as your organization is a policy question, not a configuration detail - and most companies have never asked it explicitly. They've been answering it by default, one TXT record at a time.
Start by finding out which external vendors currently hold DKIM signing rights for your domains.
DKIM Key Custody Audit
We audit the DKIM configuration across your domains: which keys exist, which vendors hold signing authority, and which entries are outdated or no longer needed. Fixed scope, fixed price.