At five domains, DNS is a task. At fifty, it is a system, and the difference is not effort but failure mode. A mistake on one of fifty domains does not announce itself. It shows up weeks later as a campaign that underperforms for no apparent reason.
This is about how to manage DNS across a large sending estate without that happening.
Why hand-editing stops working
Three specific things break, and they all break quietly.
Partial updates. You add a new sending IP and update SPF on the domains you remember. Eleven get missed. Those eleven now fail SPF, and because failures are silent, you find out from a placement drop rather than an error.
Drift. Domains added at different times get slightly different records. Six months on, no two domains are configured the same way and nobody can say which is correct.
Lookup limits. SPF allows 10 DNS lookups. Every include: costs at least one. Add providers over time and you cross the limit, at which point the record returns permerror and most receivers treat it as an outright fail. Nothing warns you.
The records you are managing
| Record | Purpose | Changes when |
|---|---|---|
| SPF (TXT) | Authorises sending sources | You add or remove a sending provider |
| DKIM (TXT) | Signs messages cryptographically | You rotate keys or add a provider |
| DMARC (TXT) | Policy and reporting | You change policy or reporting address |
| MX | Where inbound mail goes | You change mailbox provider |
| PTR / rDNS | Reverse lookup on the sending IP | You change IPs, set with your host, not your registrar |
| Tracking CNAME | Custom tracking domain | Per domain, at setup |
Six record types across fifty domains is three hundred configurations. That is the scale of the problem, and it is why a template plus an audit beats care and attention.
A safe process for bulk changes
- Write the template first. One canonical definition of what a correctly configured sending domain looks like. Everything else is compared against it.
- Lower TTL a day ahead. Drop to 300 seconds on the records you are about to change so a mistake can be reverted in minutes rather than hours.
- Change a canary group first. Three or four domains, not the whole estate. Verify authentication passes on a live send before touching the rest.
- Roll out in batches. Ten at a time, verifying between batches. Slower, and it means a bad template affects ten domains rather than fifty.
- Audit after, not just before. Pull the live records back and compare against the template. Do not trust that the change applied everywhere, confirm it.
- Restore TTL. Back to 3600 once you are confident.
The canary step is the one people skip and the one that saves you. A template with a typo, applied to fifty domains at once, takes a whole outbound programme offline.
Keeping SPF under the lookup limit
The most common way to breach it is accumulation: a mailbox provider, a sequencer, a tracking service, a CRM, all added over a year. Three practical fixes:
- Remove what you no longer use. Most estates carry includes for tools that were cancelled months ago.
- Prefer
ip4:overinclude:where you know the sending IPs. An IP costs zero lookups. - Flatten as a last resort. It works, but it breaks when the provider changes their IPs and you do not notice, so only flatten what you monitor.
Our SPF record generator builds a valid record and warns you before you cross the limit, which is easier than discovering it from a bounce.
The three options at scale
Registrar API. Workable if you are comfortable scripting and all domains sit with one registrar. You own the tooling and the mistakes.
DNS provider with templates. Cloudflare and similar let you apply a record set across zones. Good middle ground, though DKIM still needs per-domain values.
Infrastructure that owns DNS. The sending platform holds the zones and publishes records when a domain is added, then pushes changes across every domain in one action. This removes the failure mode rather than making it faster to recover from, which is the meaningful difference.
Outboundry takes the third route. Buy the domain in-app up to $14 per TLD, and SPF, DKIM, DMARC and MX are published correctly on creation, with bulk updates across the estate when something changes. There is no partial-update state to end up in.
A quarterly audit worth doing
- Every sending domain has SPF, DKIM, DMARC and MX, and they match your template.
- No SPF record is over 10 lookups.
- DKIM keys are 2048-bit and unique per domain.
- DMARC reporting goes to an address someone actually reads.
- No includes remain for tools you have stopped using.
- PTR is set for every sending IP.
Twenty minutes a quarter, and it catches the drift that otherwise surfaces as an unexplained deliverability problem.
Next: MX records across multiple sending domains, or the plain-English guide to SPF, DKIM and DMARC.
Frequently asked questions
How do I update SPF records across many domains?
Manually it means editing each domain at your DNS host, which is slow and error-prone past about ten domains. The reliable options are your registrar’s API, a DNS provider that supports templates, or infrastructure that owns DNS for your sending domains and can push a change to all of them at once.
How long do DNS changes take to propagate?
Usually minutes to a few hours, governed by the TTL on the record. Set TTL to 3600 or lower on records you expect to change. Before a planned migration, drop the TTL to 300 a day ahead so the switch is fast.
What is the SPF 10-lookup limit?
An SPF record may trigger at most 10 DNS lookups when evaluated. Every include: adds at least one. Exceed it and the record returns permerror, which most receivers treat as a failure. It is the single most common silent SPF fault at scale.
Should every sending domain have the same DNS setup?
The SPF and DMARC pattern should be consistent so you can reason about them, but DKIM keys should be per domain rather than shared. Consistency is what makes bulk updates safe; shared keys are what makes one compromise everyone’s problem.
How do I check DNS is correct across all domains?
Audit rather than assume. Pull SPF, DKIM, DMARC and MX for every sending domain into one view and compare them against your intended template. Anything that differs is either intentional or a fault, and you should know which.