Cloudflare's DNS scan is a list of common names; generated DKIM names fall outside it

Moving a domain to Cloudflare means changing its nameservers (the servers that answer where the website and the email live) at the registrar. Cloudflare offers to copy the existing records first, with a quick scan. Its reference page, read today, says what the scan is: a list of record types and names that recur across other zones (a zone is the set of records for one domain), matched against yours ¹. It is not a copy of your zone. Records whose names exist only on your domain are the ones that fall through, and on a working domain those are mostly email records.

Yesterday we published a service that does this move with a check on both sides of the switch ¹⁰. This note is the reasoning behind that check, with the script and today's measurements.

The scan matches type and name, not your zone

Cloudflare builds the scan from pairs of record Type and Name that it sees in active zones ¹. The content of the records plays no part, since content differs for every domain; a name like www or mail repeats across millions of zones, and that repetition is the list. The page gives the pairs it usually finds: an A record at the apex (the bare domain), a CNAME or A named www, an MX at the apex, a CNAME named mail, an A named webmail ¹.

The same page names what the scan does not find: a hostname specific to one zone, its example my-store1900, and a DKIM record under a custom name, its example this._domainkey where default._domainkey would be found ¹. Cloudflare's setup page puts the consequence in one line: review the apex, www and the email records yourself before changing the nameservers ².

The full list of names is not published. Whether a fixed name such as google._domainkey is on it is unknown; the page says only that custom names are expected to be missed.

Which mail providers use fixed names, and which generate them

DKIM is a signature on outgoing mail; the receiving server checks it against a public key published in your DNS under <selector>._domainkey.<domain>. The selector is the provider's choice.

A generated token appears in no list of common names, so the three SES records fall outside any scan built the way Cloudflare describes. Microsoft's two fixed names may or may not be on the list; Cloudflare's page does not say. Microsoft's page says signing of a custom domain starts once it detects the two CNAME records in DNS ⁴. A DKIM record that did not come across leaves receivers unable to check the signature; whether the mail still arrives then rests on the SPF record and the domain's DMARC policy.

Ask Cloudflare's nameservers before the registrar points at them

Cloudflare assigns two nameservers when the zone is created ². A query sent to one of them by name is answered from the new zone, whichever nameservers the registrar still lists. That allows a comparison before the switch: snapshot what the old nameservers answer, ask the two new ones the same questions, and diff.

Our script does that ⁶. It asks 92 questions per domain: the apex and www as A, AAAA and CNAME; mail, webmail, smtp, imap, pop, autodiscover and autoconfig; the Outlook _autodiscover._tcp SRV; the apex TXT (where SPF lives), _dmarc, _mta-sts, _smtp._tls; and 32 common DKIM selectors, each as TXT and as CNAME. It also asks the registry (the operator of .com, .net or another ending) for DS records, the sign that DNSSEC (signatures on DNS answers) is on.

python3 tools/dns_move_check.py before example.com
python3 tools/dns_move_check.py compare example.com <ns1>.ns.cloudflare.com <ns2>.ns.cloudflare.com
python3 tools/dns_move_check.py after example.com

compare exits 1 on any mail record that differs. Website records are allowed to differ, since Cloudflare's proxy answers them with its own addresses. Measured 7 November 2026 from Chiang Rai, one run per domain, on four domains already on Cloudflare:

The other three domains took 2.8 s to 4.0 s each. The limit is the one the scan has, in smaller form: a DKIM name outside the 32 is not found by asking. The SES tokens, the one case where the name cannot be guessed, come from the provider's settings page, and that page is read for every domain regardless of what the script finds.

Mail hosts stay DNS only

Only A, AAAA and CNAME records can go through Cloudflare's proxy; MX and TXT are always DNS only ⁷. The proxy answers web requests; a mail host whose A record is proxied answers with Cloudflare's own addresses ⁹, and Cloudflare's email-records page shows that host as DNS only in its example and says port 25, the mail port, is not proxied by default ⁸. One more rule from the proxy page: when one A record on a name is proxied, every A record on that name is treated as proxied ⁷. The quick-scan page does not say which proxy status it sets on what it finds; the orange cloud beside each mail host is read after the scan.

Cloudflare's 24 hours, the registry's 48

Cloudflare's setup page says to wait up to 24 hours while the registrar updates the nameservers, that online checkers lag because they use cached results, and to confirm with dig ns <domain> @1.1.1.1 ². The 24 hours is the registrar's side. On the other side sit the resolvers (the servers that look names up for phones and laptops), and they cache the old delegation for the registry's TTL, the time-to-live on the record. Measured today at the registries' own servers:

For a .com or .net domain that is 48 hours. Four public resolvers asked for one of our .net domains today reported remaining TTLs of 86,252 s (Cloudflare's resolver), 86,400 s (OpenDNS), 43,200 s (Quad9) and 21,600 s (Google Public DNS): what each reported as remaining, lower than the registry's figure and none below six hours. A resolver that looked the domain up just before the switch answers the old nameservers until its copy expires, so the old host's DNS stays as it was, records intact, for two days after the switch, and the old hosting is cancelled after that, not on the day.

Once the zone is on Cloudflare, later changes move faster: proxied records carry a fixed TTL of 300 seconds, and Auto on an unproxied record is 300 seconds too ⁹.

Order of the day

1. Create the zone, run the scan, then read the mail provider's settings page and add every record named there, SES tokens included ¹⁵.
2. Run before against the old nameservers and compare against the two new ones; a GAP line is a record to add ⁶.
3. DNSSEC off at the registrar if before printed DS records; Cloudflare's page says changing nameservers with it on can make the domain unreachable ².
4. Change the nameservers; dig ns <domain> @1.1.1.1 until it answers the new pair ².
5. Run after, send one mail from the domain to an outside inbox and read its authentication headers, and leave the old host's DNS alone for two days.