After a DNS change, email often stops working because mail delivery does not rely on the website alone. In many hosting setups, the domain’s DNS controls where inbound mail is delivered, how outgoing mail is authenticated, and which services are allowed to send on behalf of the domain. If one or more mail-related records are missing, incorrect, or still propagating across Europe and beyond, messages may bounce, be delayed, or disappear into spam folders.
This usually happens after common changes such as moving a website to a new hosting platform, switching nameservers, updating MX records in Plesk, or changing the A record for the domain. In a managed hosting environment, the website may come online quickly while email continues to fail because the mail configuration was not migrated with the DNS zone.
Why email breaks after a DNS change
Email uses several DNS records, not just one. If you changed only the website records, mail may still depend on the old settings. If you changed the whole DNS zone, the mail records may no longer point to the correct service. The most common reasons are:
- MX records changed or were removed and mail is now delivered to the wrong place.
- Mail A or CNAME records still point to the old server.
- SPF, DKIM, or DMARC records were not copied to the new DNS zone.
- Nameserver changes are still propagating, so some mail systems see the old zone and others see the new one.
- The mailbox moved, but the DNS did not, or the DNS changed, but the mailbox stayed on the previous platform.
- The hosting control panel created new defaults that conflict with your existing email provider.
In practice, a DNS change can affect both incoming and outgoing email. Incoming mail depends mainly on MX records, while outgoing mail depends on authentication and the server used to send messages.
What to check first
If email stopped working immediately after a DNS update, start with the records that control mail routing and authentication. In a control panel such as Plesk, these are usually visible in the domain’s DNS settings.
1. Check the MX records
MX records tell the internet where to deliver mail for your domain. If they are missing, incorrect, or set to a web server instead of a mail server, inbound email will fail.
Verify that:
- MX records point to the correct mail host.
- The priority values are correct if you use more than one mail server.
- There are no old MX records left over from a previous hosting provider.
- The mail host name resolves to a valid A or CNAME record.
If your email is handled by your hosting platform, the MX record usually points to a mail service provided by that platform. If you use an external email provider, the MX records must match their published values exactly.
2. Check the mail-related A and CNAME records
Some setups use a subdomain such as mail.example.com for webmail, SMTP, IMAP, or POP access. If that hostname still points to the old server, users may not be able to connect even if the mailbox itself is still active.
Review any records such as:
mailwebmailsmtpimappop
Make sure these records point to the current mail service, not the previous hosting environment.
3. Verify SPF
SPF helps receiving mail servers confirm which systems are allowed to send email for your domain. If SPF is missing or outdated after a DNS change, outgoing messages may be rejected or marked as suspicious.
Common signs of SPF issues include:
- Messages landing in spam more often than before.
- Bounces mentioning SPF fail or softfail.
- Email sent from your website forms not being accepted by recipients.
Ensure your SPF record includes the new sending server or your external email provider. Avoid publishing multiple SPF records; use one record with all required senders combined.
4. Verify DKIM
DKIM adds a cryptographic signature to outbound email. If your DNS change removed the DKIM public key record, messages may no longer be authenticated correctly.
Check that:
- The DKIM record still exists in the DNS zone.
- The selector name matches the mail system or control panel configuration.
- The private key on the mail server matches the public key in DNS.
In Plesk, DKIM is often managed automatically, but if the DNS zone was moved to a different provider, you may need to publish the DKIM record there manually.
5. Check DMARC if you use it
DMARC does not deliver mail, but it tells receiving servers how to handle messages that fail SPF or DKIM. If your DNS change broke those records, DMARC can make the problem more visible by causing messages to be rejected or quarantined.
If you already have a DMARC policy, review reports for signs of:
- Alignment failures
- SPF fail after migration
- DKIM fail after migration
How DNS propagation affects email
DNS changes do not update everywhere at once. Across the EU and the rest of the world, resolvers may continue to use cached data for minutes, hours, or occasionally longer depending on TTL values and cache behavior.
This means:
- Some senders may deliver mail to the new server.
- Others may still send to the old destination.
- Outbound mail tests may pass from one network and fail from another.
If the change was recent, wait for propagation to complete before making repeated modifications. Frequent changes can extend the period of inconsistency.
Typical scenarios and how to fix them
Scenario 1: Website moved, email stayed on the old host
This is common during migration. The website may now point to the new hosting account, but MX records still point to the old provider. If that provider is no longer active, incoming mail will bounce.
Fix: Update the MX records to the correct mail host, then confirm the mail host itself has a valid A or CNAME record.
Scenario 2: You changed nameservers and lost the mail records
When nameservers are switched, the new DNS zone must contain all records from the old zone, not only the website records. If the email-related entries were not copied, email stops working even though the domain resolves in the browser.
Fix: Recreate MX, SPF, DKIM, DMARC, and any required mail host records in the new DNS zone.
Scenario 3: External email provider is no longer recognized
If you use Microsoft 365, Google Workspace, or another external mail provider, a DNS update may accidentally replace their required records with hosting defaults.
Fix: Restore the provider’s exact MX and verification records. Remove conflicting MX entries from the hosting platform’s DNS zone.
Scenario 4: Outgoing mail fails after switching to a new mail server
Sometimes users can still receive email, but messages they send are rejected or go to spam. This usually means the server changed, but SPF and DKIM were not updated.
Fix: Add the new sender to SPF, publish the correct DKIM record, and test mail again. If a website contact form sends mail, make sure it uses authenticated SMTP rather than basic PHP mail where possible.
Scenario 5: Webmail or mail app cannot connect
If users can receive mail on one device but not another, the mail client may be connecting to a hostname that still points to the old server.
Fix: Update the mail client settings to the current IMAP, POP, and SMTP server names. Check that the DNS records for those hostnames resolve correctly.
Step-by-step troubleshooting checklist
Use the following checklist to isolate the issue quickly:
- Confirm whether the problem affects incoming mail, outgoing mail, or both.
- Check the domain’s current DNS zone and confirm the MX records.
- Verify that the mail host resolves correctly in DNS.
- Review SPF and make sure it includes the current mail service.
- Check whether DKIM is still published in the active DNS zone.
- Review DMARC if you use it and look for alignment failures.
- Wait for propagation if the change was recent and compare results from multiple networks.
- Test with a mailbox outside your domain to confirm external delivery.
- Check spam, quarantine, and server-side filters.
How to check DNS in a hosting control panel
In a hosting control panel such as Plesk, the DNS zone for a domain is usually managed from the domain’s DNS settings. Depending on your setup, the panel may automatically create records for web and mail services.
Look for:
- MX records for the domain.
- A or CNAME records for the mail host.
- TXT records for SPF.
- DKIM records, often published as TXT.
- DMARC record under
_dmarc.
If your provider manages DNS externally, changes in the control panel may not be enough. You must update the authoritative DNS zone where the domain actually points.
Also check whether the hosting platform is set to host mail for the domain. In some environments, the panel can either manage email locally or leave mail delivery to a third-party service. Mixing both configurations often causes routing errors.
Common DNS record mistakes that break email
- Pointing MX to the web server instead of the mail server.
- Using an IP address in MX instead of a hostname, where the provider expects a hostname.
- Leaving old MX records active after migration.
- Publishing two SPF records instead of one combined record.
- Removing DKIM during migration and forgetting to restore it.
- Changing the root A record but forgetting that mail hostnames also need updates.
- Using a mail host name that no longer resolves in the active DNS zone.
Best practice during migration
Before changing DNS, export or document the full DNS zone. Do not copy only the website records. For a safe migration in a managed hosting setup, keep the following in sync:
- Website A and CNAME records
- MX records
- SPF record
- DKIM record
- DMARC record
- Any mail service hostnames used by mail clients
If possible, lower TTL values before the migration so updates propagate faster. After the change, verify mail from both a local mailbox and an external mailbox. This helps confirm that routing and authentication are correct.
When to contact support
Contact your hosting provider or email administrator if:
- The DNS zone looks correct, but mail still fails after propagation.
- You are not sure whether DNS is managed inside the hosting control panel or at the registrar.
- Your mail provider uses records that are difficult to interpret.
- Messages are bouncing with server-level errors you cannot identify.
- The mailbox exists, but the server does not accept login or SMTP connections.
When you open a support request, include the domain name, the time of the DNS change, the affected mailbox, the mail provider, and any bounce messages or error codes. That information helps isolate whether the issue is DNS, mail routing, or authentication.
FAQ
How long can email stop working after a DNS change?
It depends on propagation and cached DNS data. In many cases, issues resolve within a few hours, but some resolvers may keep old records longer if the previous TTL was high.
Why can I still receive some emails but not others?
Different sending systems may use different DNS resolvers. Some may see the new MX records, while others still use cached old data. This is a strong sign of propagation or inconsistent DNS records.
Why do outgoing emails go to spam after changing DNS?
That usually points to missing or outdated SPF, DKIM, or DMARC records. The sending server may not be properly authenticated for your domain anymore.
Do I need to update DNS if I only changed the mailbox server?
Yes, if the mailbox server hostname changed or if the domain’s mail service depends on records that point to that server. The MX record and related mail hostnames must match the new server.
Can website DNS changes affect email even if I did not touch mail settings?
Yes. If you changed nameservers or replaced the entire DNS zone, email records may have been removed or overwritten even when you did not intend to change them.
What should I verify in Plesk after a migration?
Check the domain’s DNS zone, confirm that mail is enabled for the domain if it should be hosted locally, and verify MX, SPF, DKIM, and any custom mail hostnames used by your users.
Conclusion
Email issues after a DNS change are usually caused by missing, outdated, or conflicting mail records rather than by the mailbox itself. The fastest way to restore service is to verify MX, SPF, DKIM, and any mail hostnames in the active DNS zone, then confirm that the configuration matches the actual mail service in use. In most hosting migrations, keeping website DNS and email DNS aligned is the key to avoiding delivery problems.