Fetch live SPF and DMARC records over DNS, or review pasted values, for common structural mistakes before a website or DNS migration.
Enter your site details and calculate.
This free utility is designed for migration planning. Type a domain to fetch its live SPF and DMARC records over public DNS, or paste record values manually, and it turns them into a structured review so you can identify what should be checked before a production change. It only makes read-only public DNS queries — it never connects to your server, registrar account or WordPress database, so it cannot replace a real technical audit.
It can be: type a domain and press “Look up live records” to fetch the published SPF and DMARC records over DNS, or paste values manually. Either way it checks basic structure only — it does not prove that included SPF hosts resolve, that DKIM selectors exist, or that mail is aligned correctly.
Your website host, transactional mail provider, Google Workspace, Microsoft 365, CRM and other senders may all affect SPF design. Copy the exact mechanisms from those providers.
A DMARC policy is effective only when legitimate mail can authenticate and align. Move gradually from monitoring to enforcement after reviewing reports.
DKIM keys and selectors come from the sending platform. If email stays with the same provider during a website migration, those records usually should not be changed.
No. It runs locally in the browser and only evaluates the values you enter, or fetches public DNS records (read-only). It does not log in to WordPress, change DNS, move files or modify hosting.
Use it as a starting checklist. Add the site-specific dependencies discovered during the source audit, including custom plugins, server rules, cron jobs, email, APIs, payment gateways and any third-party services.
Manual planning is appropriate when the site generates revenue, has active customer data, cannot tolerate downtime, uses custom server configuration, has a large database or depends on integrations outside WordPress.
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.
