Website DNS and business email often use different providers. Replacing records for the website can unintentionally remove mail routing and authentication.
What to check
- Record current MX, SPF, DKIM, and DMARC values
- Confirm which provider handles email
- Restore only the records supported by the active provider
What the results mean
Identify the active email provider before restoring MX, SPF, DKIM, or DMARC records. Avoid copying old records without checking that they match the current service.
Separate the website from email
Changing a nameserver can replace the whole DNS zone, including records that route mail. A website may start working on the new host while messages stop arriving because the new zone lacks the business's MX records. Ask where mail was hosted before the change and compare the former zone with the active one. Do not copy records blindly if the mail provider changed too.
Check delivery and authentication
After restoring the correct mail routing, send tests in both directions from an unrelated mailbox. Check SPF, DKIM, and DMARC against the actual sending services, including contact forms or newsletters. A working inbox does not prove outgoing mail will pass authentication. Save a record inventory so the next website move does not interrupt email again.
What if messages were sent during the outage?
Some senders may retry and others may receive a bounce. Review the affected timeframe and ask important contacts to resend anything that did not arrive. DNS repair cannot guarantee recovery of messages already rejected by another server.
