DNS setup for email means creating six or seven records, several of them long strings where a single wrong character produces a failure that looks nothing like a typo. A DKIM key is a few hundred characters of base64. An SPF record is a mechanism list where the order matters and the terminator changes the meaning. DMARC lives at a subdomain name people get wrong on the first try.
Do that DNS setup once and you'll probably get it right. Do it for forty client domains and you won't — and the failures won't surface until a month later when somebody's invoice lands in spam.
Automatic DNS setup removes the typing. There are two routes: an authorise-and-return flow for a single domain that needs no credentials at all, and a scoped API token that runs the DNS setup for a hundred domains in one pass. Both show you every change before writing anything.
What Email DNS Setup Actually Requires
| Record | Type | Job | Required? |
|---|---|---|---|
| MX | MX | Where inbound mail is delivered | Yes — no MX, no incoming mail |
| SPF | TXT at the root | Which servers may send as your domain, per RFC 7208 | Yes |
| DKIM | TXT at a selector | Public key that verifies your outbound signature | Yes in practice |
| DMARC | TXT at _dmarc | What to do when SPF and DKIM disagree, and where to send reports | Yes in practice |
| MTA-STS | TXT + a hosted policy | Requires TLS on inbound delivery | Recommended |
| TLS-RPT | TXT at _smtp._tls | Reports on failed TLS delivery attempts | Recommended |
| autoconfig / autodiscover | CNAME | Lets mail apps configure themselves from the address alone | Optional, saves a lot of support |
"Required in practice" is doing real work in that table. Neither DKIM nor DMARC is required by any RFC. Both are required by Google and Yahoo for bulk senders as of 2024, and by an increasing number of corporate receivers for everyone. A domain without them isn't broken; it's just quietly disadvantaged at every filter it meets.
Four Mistakes Hand-Written DNS Setup Makes
Two SPF records. The most common and the most damaging. A domain may publish exactly one SPF record. Add a second because you now use a new sender and you haven't extended your policy — you've made it invalid, and every evaluator will treat the result as permerror. Both records stop working. The fix is to merge the mechanisms into one record; see SPF record examples.
DKIM keys mangled on paste. A 2048-bit key exceeds the 255-character limit for a single TXT string, so it has to be split into chunks that the resolver reassembles. Some DNS panels do this automatically, some expect you to do it, and some silently truncate. A truncated key produces a signature that fails verification with no obvious cause.
DMARC at the wrong name. It belongs at _dmarc.example.com. Put it at the root and it does nothing at all, silently, forever.
Too many SPF lookups. SPF permits ten DNS lookups during evaluation. Every include: costs at least one, and nested includes count too. Add your mail host, a CRM, a marketing tool, and a helpdesk and you're over the limit — at which point the record is a permerror and stops protecting anything. This one is nasty because it appears months after setup, when someone adds one more tool. See the SPF lookup limit.
Automated DNS setup eliminates the first three by construction and warns about the fourth by merging rather than appending.
Route 1: One-Click DNS Setup, No Token
For a single domain whose DNS is at Cloudflare, this is the shortest path and it requires no credentials.
- Open the domain's DNS & Health tab.
- Click Set up DNS automatically.
- You're redirected to Cloudflare, which shows exactly which records are about to be created.
- Click Authorize.
- You land back on TrekMail. The records exist and verification has already started.
The requirement is that the domain's nameservers point at Cloudflare. If the domain is registered at Cloudflare but its DNS is served elsewhere, this route is unavailable — the record write has to happen where the zone actually lives.
Route 2: DNS Setup With a Scoped API Token
For many domains, or when Domain Connect isn't available, a scoped token runs the same DNS setup across every zone in the account.
Create the token in Cloudflare from the Edit zone DNS template, with permission Zone → DNS → Edit. Under Zone Resources, pick All zones for everything or Specific zone to limit it. Leave IP filtering and TTL alone. Copy the token — Cloudflare shows it once — and paste it back.
What that scope can and can't do is the point:
| The token can | The token can't |
|---|---|
| Read and write DNS records in the zones you selected | Change nameservers |
| Touch billing, WAF, page rules, workers, or SSL settings | |
| Transfer or delete a domain | |
| See zones you didn't include |
The token is encrypted at rest and never written to logs, and you can disconnect it at any time — from our side per domain, or from Cloudflare's side by revoking the token, which takes effect immediately.
Once connected, your Cloudflare zones are listed with what the DNS setup will do to each: Setup DNS for a domain already in your account, or Add + DNS for one that gets added and configured in the same pass. Domains not on Cloudflare don't appear, because there's nothing to write to.
The Preview, and Its Five Verdicts
Nothing is written before you've seen it. Every record gets one of five verdicts:
| Verdict | Meaning | Needs your decision? |
|---|---|---|
| Will be added | Nothing is there; the record is created | No |
| Will be merged | An SPF record exists and will be extended to include us, keeping what is already there | No |
| Already set up | The correct value is already present | No |
| Will be replaced | An existing record conflicts — a DMARC policy that differs, an autodiscover CNAME pointing at your old provider | Yes — choose Replace or Keep |
| Skipped | You unchecked it | You already did |
Every record also has a checkbox, so you can apply MX and SPF now and come back for DKIM later, or permanently skip a record you manage elsewhere. Anything unchecked isn't touched.
The conflict cases are the ones worth reading rather than clicking past. An existing p=none DMARC policy isn't wrong — it may be a deliberate monitoring phase you're halfway through, and replacing it with p=quarantine before you've read the reports is how legitimate mail starts disappearing. Keep it, finish the rollout, then tighten. The reasoning is in choosing a DMARC policy.
Why SPF Gets Merged, Never Replaced
SPF is the one record where blind replacement is guaranteed to break something, because it's the only one that's a shared list.
If your domain already publishes:
v=spf1 include:_spf.google.com ~all
then something is sending mail through Google — Workspace, or a marketing tool routed through it. Replacing that with our own include doesn't add a sender; it removes one, and the mail that was working yesterday starts failing SPF today.
So an existing SPF record is merged:
v=spf1 include:_spf.trekmail.net include:_spf.google.com ~all
Both senders authorised, one record, the qualifier preserved. That's the only safe transformation, and it's why SPF gets its own verdict in the preview rather than being lumped in with the rest.
Two things to watch afterwards. Merging adds an include:, which costs a DNS lookup against the limit of ten — worth checking if your record was already long. And if the old sender is genuinely retired, remove its include by hand later; nothing will remove it for you, because nothing can tell whether it's dead or merely quiet.
DNS Setup in Bulk
With a token scoped to all zones, the wizard walks every compatible domain: adding the ones that are new, configuring DNS for each, and reporting per-domain results. Up to 50 domains per batch, and new domains count against your plan's domain limit — 10 on Nano, 50 on Starter, 100 on Pro, 1,000 on Agency.
For an agency onboarding a client with a dozen domains, bulk DNS setup is the difference between an afternoon and a coffee. It's also the point at which the preview stops being a formality: across twelve domains you'll typically find two with a conflicting DMARC record and one with an autodiscover CNAME still pointing at a provider they left in 2023.
Blast Radius
Reasonable question to ask before handing anything write access to your DNS.
Only email records are created or updated: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and the mail-autoconfiguration CNAMEs. A records, CNAMEs for your website, TXT records for other services, and nameserver settings aren't touched — and the token scope can't reach nameservers even if something tried.
The one genuinely destructive operation available is replacing a conflicting record, which is exactly why it's the only verdict that stops and asks. Everything else either creates something absent or extends something present.
If DNS still shows pending afterwards, that's propagation, not failure. Changes can take up to 48 hours to be visible everywhere, verification re-runs automatically, and Verify DNS on the domain page forces a check. If it's still failing a day later, DKIM troubleshooting is the usual next stop.
Frequently Asked Questions
Do I need a Cloudflare account for one-click DNS setup?
Your domain's DNS has to be served by Cloudflare, which means having an account there. What you don't need is an API token — you authorise the change in Cloudflare's own interface and no credential is stored.
What if my DNS isn't at Cloudflare?
Then automatic DNS setup isn't available for that provider yet, and the records have to be created by hand. The domain's DNS page lists every record with copy buttons, and there are provider-specific walkthroughs in DNS setup for popular providers.
Will automatic DNS setup break my website?
No. DNS setup only creates or updates email records. A records, website CNAMEs and unrelated TXT records are left alone, and the token scope doesn't permit changing nameservers.
What happens to my existing SPF record?
It's merged, not replaced — our include is added to what is already there and the qualifier is kept. Replacing it would silently break whatever else was sending on your behalf.
Can I apply only some records?
Yes. Every record in the preview has a checkbox. Uncheck anything you manage elsewhere and it's left untouched.
How many domains can one DNS setup run cover?
Up to 50 per batch, bounded by your plan's total domain limit. New domains added by the wizard count toward that limit.
Is my API token safe?
It's encrypted at rest and never logged. Its Cloudflare scope covers DNS records only — no billing, no WAF, no nameservers, no domain transfers. Revoke it in Cloudflare at any time and access ends immediately.
Why did it say "already set up" for a record I have never created?
Usually because a previous provider created it, or a one-click setup was run earlier. Compare the existing value against what is proposed — if they match, there's genuinely nothing to do.