Setting up DKIM for one domain is a short task. You generate a key pair, publish the public half at a selector hostname, enable signing on the mail platform, send a test message, read the headers, done. Twenty minutes if the DNS panel is slow.
Doing it across a portfolio of domains is a genuinely different job, and the difference is not arithmetic. The failure modes that never show up on one domain become the dominant cost on twenty: keys that exist but sign nothing, selectors that were named inconsistently two years apart, records that a DNS panel silently mangled, and no reliable way to tell which domains are actually finished.
This is a field guide to doing it once, correctly, at scale.
What should you decide before you touch DNS?
Three conventions, applied to every domain in the portfolio. Deciding them up front is the whole difference between a portfolio you can audit and one you have to re-investigate every time something breaks.
- Selector naming. Pick one scheme and never deviate. Something that encodes the year or the rotation generation is far more useful than something that encodes the vendor, because vendors change and rotations are forever. The critical property is that you can look at any domain's DNS and know instantly which selector is current.
- Key length. 2048-bit, universally. Mixed key lengths across a portfolio mean mixed record-splitting behaviour, which means the domains that needed splitting are exactly the ones most likely to be broken.
- One key pair per domain. Sharing a pair across domains saves a few minutes of generation and costs you the ability to rotate or revoke anything independently.
Why do private keys need a home before you generate anything?
Because the generation step produces a secret, and secrets that are produced before there is a place to put them end up in a home directory, a chat message, or a ticket attachment. Decide where private keys live, who can read them, and how they are backed up — before the first key exists rather than after the twentieth.
The practical requirements are unglamorous: readable only by the account that runs the signing process, stored outside any directory the web server can serve, and backed up somewhere that is not the same machine. That last one matters more than it sounds. A key you cannot restore is a key you will have to rotate under pressure, on every domain, on the worst possible day.
What actually goes wrong when you publish the records?
Almost all of it is one problem wearing different hats: the public key is long, DNS TXT strings are limited to 255 characters each, and something between you and the authoritative server has to split it.
The DNS specification handles this cleanly — a TXT record may contain multiple character strings, and a resolver concatenates them with nothing in between. The trouble is that DNS control panels vary wildly in how they accept the split. Some want you to paste the whole value and split it themselves. Some want pre-quoted strings. Some accept pre-quoted strings and then helpfully insert a space at every join, which produces a record that looks right in the panel and is cryptographically worthless.
Related mangling to watch for:
- A trailing dot appended to the selector hostname, producing a record one level deeper than intended.
- The domain name auto-appended to a name you already wrote in full, giving you
selector._domainkey.example.com.example.com. - Whitespace or line breaks preserved from a copy-paste out of a terminal.
- The key published with the PEM header and footer lines still attached.
None of these produce an error at publish time. All of them produce a domain that fails DKIM verification while looking configured.
How do you verify a portfolio rather than a domain?
Manual verification does not survive contact with twenty domains. What you need is a check that runs the same way every time and produces a list rather than an impression. Three checks, in this order:
- Does the selector record resolve at all? Query the selector hostname directly. A missing record here means the publish step did not land — wrong zone, wrong name, or a panel that discarded it.
- Does the resolved value parse as a key? This is the check that catches injected spaces and stray headers. The record can resolve perfectly and still contain a value no verifier can use.
- Does real outbound mail carry a matching signature? This is the only check that proves the loop is closed. Send to a mailbox you control, read the raw headers, and confirm the
DKIM-Signatureheader carries ad=matching the domain and ans=matching the selector you published.
Skipping the third check is the classic portfolio mistake. It is entirely possible — and, in our experience, common — to have a full set of correct DNS records for domains where nothing is signing. The DNS side and the mail-platform side are configured by different people at different times, and nothing forces them to meet.
What order should you roll the portfolio out in?
Not alphabetically. Order by consequence:
- Start with a domain that sends little or nothing. The first domain is where you discover that your DNS panel mangles split strings. Discover that somewhere it does not cost you customer mail.
- Then do your highest-volume transactional domain. That is where the delivery benefit is largest and where a problem surfaces fastest.
- Then the long tail. By this point the procedure is mechanical and the verification is scripted.
Parked and non-sending domains deserve a mention. They do not need DKIM keys, because they should not be sending at all — but they very much need an SPF record that authorises nothing and a DMARC record set to reject. An unused domain with no policy is a free identity for anyone who wants to send as your brand.
What breaks after you finish?
Three things, all of them silent.
Key rotation on the platform side. A managed sending platform may rotate its signing key on its own schedule. If the public key lives in your DNS rather than theirs, rotation breaks signing until you republish.
Zone migrations. Moving DNS hosting copies the records that the migration tool understands. Long split TXT values are exactly the kind of record that arrives subtly different on the other side.
People. Someone tidying up "unused" TXT records is a real and recurring cause of DKIM failure. Selector hostnames look like clutter to anyone who does not know what they are.
All three share a shape: nothing appears broken, nobody gets an error, and mail quietly starts failing authentication somewhere you cannot see. That is the argument for continuous monitoring over a completed checklist. The checklist proves you did it. Monitoring proves it is still true.