If business email stopped immediately after moving a WordPress site or changing nameservers, check the active DNS zone before installing another SMTP plugin. The website can work while the new zone lacks the records that direct incoming mail to your existing email provider.
First establish the scope. Can an outside sender reach a normal staff mailbox? Can staff send outbound mail? Is only the WordPress contact form failing? Those answers separate domain-wide delivery problems from application notifications.
Find the Authoritative DNS Provider
The registrar, website host, DNS provider, and mail provider can be four different companies. Editing records in the old hosting panel will not fix delivery if the domain now delegates DNS elsewhere.
Use your domain in these read-only checks:
dig +short NS example.com
dig +short MX example.com
dig +short TXT example.com
Compare the nameservers with the account where you are making changes. Ask the DNS administrator to check answers from the authoritative nameservers as well as a public resolver. A stale recursive answer and an incorrect authoritative zone are different problems.
Restore the Provider's Exact Records
Retrieve the expected records from the existing mail provider's admin console or a trusted pre-migration zone export. Preserve priority values and the precise domain or subdomain being configured. Do not add a random collection of MX records from different providers.
For Google Workspace, the official MX setup guide documents both the current configuration and support for legacy values. Do not replace working legacy records just because an example uses a newer value. Other providers have their own settings.
Check that TXT and CNAME records used for sender authentication and domain verification were transferred too. Avoid publishing a second independent SPF policy to fix a missing sender. Have the email administrator reconcile the authorized senders into the provider-approved configuration.
Verification record for Business Email Stopped After Moving Your WordPress Site? Check DNS First. Fill in your own evidence.
Use a Four-Way Delivery Test
| Test |
What it distinguishes |
| External mailbox to staff address |
Inbound routing and mailbox acceptance |
| Staff address to external mailbox |
Outbound service and authentication |
| Another staff address to affected address |
Internal routing only |
| WordPress form to controlled recipient |
Application notification path |
Use a unique subject reference and record the message time. Internal mail succeeding does not establish that internet senders can find the right destination. Preserve a bounce's diagnostic code without publishing addresses or message content.
If the provider never sees an inbound test, investigate DNS and sender delivery evidence. If it accepted the message, inspect routing, quarantine, aliases, mailbox capacity, and account status. Google's receiving-mail troubleshooting guide illustrates that DNS is only the first checkpoint.
Finish the Migration Without Hiding the Problem
DNS caches can retain earlier answers until their relevant cache lifetime expires. Record the correction time and observed answers rather than promising instant global propagation. Do not keep changing nameservers during the observation period without a specific recovery reason.
Once ordinary mail works, test the WordPress form notification path. Restoring MX records does not automatically repair a form's sender identity or SMTP connection.
Update the migration checklist with every non-website DNS record and its owner. For a mixed hosting and email incident, HandL WP can help trace the failed path. Share record names, timestamps, and redacted errors through the support process, not mailbox passwords.
References checked September 29, 2026. Diagrams and examples are explanatory, not measured customer results.