Export the existing zone first
Before editing DNS, capture every existing record and its value. This gives you a recovery reference and exposes email, verification, subdomain and third-party records that are easy to miss.
Build a clean DNS migration worksheet for A, CNAME, MX, SPF and DMARC records before changing nameservers or hosting.
Verify every record with the actual provider before publishing.
This is a planning estimate based on the values you enter. Real WordPress environments can be affected by disk speed, database size, cache behavior, provider limits, plugin architecture, active traffic and third-party services. Verify the production environment before making a live change.
Before moving nameservers, export or document the existing zone. MX, SPF, DKIM, DMARC, verification records and third-party subdomains can be unrelated to the website but still break if they are omitted from the new DNS zone.
Use the calculator as a planning aid, then validate the result against the actual WordPress installation, hosting account and production traffic. These notes explain the technical assumptions behind the result and the checks I would make before acting on it.
Before editing DNS, capture every existing record and its value. This gives you a recovery reference and exposes email, verification, subdomain and third-party records that are easy to miss.
A/AAAA and selected CNAME records usually direct web traffic. MX and TXT records often control email or external services. Treat record ownership as a dependency map instead of changing the entire zone together.
A domain should normally publish one SPF policy record that contains the required mechanisms. Creating multiple independent SPF records can cause SPF evaluation problems.
Do not invent a DKIM public key. Generate or obtain it from the actual mail service, then publish the exact selector and value it provides.
No. It is an estimate based on the inputs available in a browser. Production WordPress sites can have custom code, unusual server limits, third-party integrations and traffic patterns that change the real requirement.
The calculator runs in your browser. The page does not need an account or a database to calculate the result. Avoid pasting passwords, API keys or private customer information into any planning field.
Use a manual review when the site generates revenue, has active users, contains a large database, uses memberships or subscriptions, has custom integrations, or cannot tolerate an extended rollback window.
The useful part of a planning tool is not the number by itself. It is understanding which assumptions produced the result, which production conditions can change it, and what should be checked before you act. Use this tool as part of a wider migration or infrastructure review rather than as an automatic go/no-go decision.
A domain can carry website routing, mail delivery, verification records, subdomains, third-party SaaS records and security policies. Review the full zone before changing nameservers or replacing records.
Recursive resolvers and client caches do not all update at one exact moment. Lower TTL before a planned cutover when possible, then keep the old origin available long enough to absorb straggling traffic.
MX, SPF, DKIM and DMARC should be checked independently of the website. A migration can appear successful in the browser while business email is silently misrouted or authentication begins failing.
Not necessarily. TTL influences caching, but resolver behavior and previously cached answers vary.
Yes if the new DNS zone does not reproduce the required MX and authentication records.
Usually for a reasonable overlap period, especially while DNS propagation and cached traffic settle.