Beamfar
Sign inStart the 14-day trial

Email stops after a DNS change: what to check (MX, SPF, DKIM, DMARC)

By the Beamfar team. Published . Updated . 5 min read.

A client rings to say customers’ emails bounce. Your site is up, so the first reaction is that this is someone else’s problem. It usually is a DNS problem, and it often started with a change you made to the website the week before.

Why website changes break email

A domain’s DNS zone carries the website records and the mail records side by side. A person editing the zone to move the website sees one list of records. A mistake in that list can remove or overwrite the ones that route and authenticate mail. Four record types matter.

MX: where mail is delivered

An MX record names the servers that accept mail for the domain, each with a priority. If the MX records disappear, senders find nowhere to deliver and messages bounce or are delayed. If they point to an old provider, mail goes to a mailbox nobody reads.

SPF: who may send

An SPF record, a TXT record starting v=spf1, lists the servers and services allowed to send mail for the domain (RFC 7208). Two traps are common:

  • More than one SPF record. The standard requires a single SPF record per name. Two records produce a permanent error and receivers may treat all mail as failing. This happens when a new service’s instructions say “add this TXT record” and someone adds it beside the old one instead of merging.
  • Too many lookups. SPF evaluation is limited to ten DNS-querying mechanisms. Each include: adds some. Adding the newsletter, CRM and helpdesk can push a record over the limit.

DKIM: a signature on the message

DKIM (RFC 6376) signs outgoing messages. The public key sits in a TXT record at selector._domainkey.example.com. Delete the selector record, or change the provider that signs, and receivers can no longer verify the signature.

DMARC: what to do when checks fail

A DMARC record at _dmarc.example.com (RFC 7489) tells receivers what to do with messages that fail SPF and DKIM alignment: nothing (p=none), quarantine or reject. A strict policy combined with a broken SPF or DKIM record turns a small DNS mistake into rejected mail.

What a visitor-facing check misses

The site works, the certificate is valid and the alerts are green. None of that tells you whether mail arrives. A website monitor reads the website’s own records; testing mail means sending mail. Hold both facts: you can see that a record changed, but you can only prove that mail works by sending a message and reading the headers on arrival.

A checklist around every DNS edit

Before

  1. Export the whole zone and keep a copy.
  2. List the mail-related records: every MX, every TXT at the apex that starts v=spf1, every _domainkey record and _dmarc.
  3. Ask the client which services send mail as their domain: the mailbox provider, the website’s contact form, a newsletter tool, an invoicing system, a helpdesk. Each must be inside the SPF record.
  4. Note the DMARC policy. A p=reject policy means mistakes are felt immediately.

During

  1. Change only the website records unless the mail records are part of the job.
  2. If a service tells you to add an SPF include, edit the existing SPF record; do not add a second one.
  3. When you move nameservers, import or recreate every record from the old zone before the switch.

After

  1. Send a test message from each service that sends as the domain to a mailbox at a different provider.
  2. Open the message source and read the Authentication-Results header. You want spf=pass, dkim=pass and dmarc=pass.
  3. Send a message to the domain from outside and confirm it arrives.
  4. Write down what you checked, with the date.

When it has already broken

  • Bounces mentioning “no MX” or “domain not found”: MX records or the whole zone are missing. Compare with the exported copy.
  • Mail lands in spam or is rejected for authentication: read the authentication results. Look for duplicate SPF records, a missing include or a missing DKIM selector.
  • Only some senders fail: a service not listed in SPF, or a DKIM key rotated by the provider and not updated in DNS.
  • Everything is correct but mail is delayed: TTLs. A resolver may still hold the old MX for up to the old TTL. Wait, and meanwhile check the authoritative nameservers.

Telling the client

Be specific and short: what stopped, since when, which messages may be affected (anything sent to the domain in that window may have bounced), what you changed and what you will check from now on. See Incident communication to clients for a template.

How Beamfar helps

Beamfar records DNS changes on a site’s timeline, including a changed record on the monitored hostname, so you can tie a client’s report of failure to a change that happened just before. It does not test mail delivery and does not read MX, SPF, DKIM or DMARC records for you; treat the checklist above as the way to cover that.

Questions

Can a website DNS change break email?

Yes. Website and mail records share one zone. Deleting an MX record, replacing the nameservers without copying the zone or adding a second SPF record can stop or reject mail while the website keeps working.

Can a domain have two SPF records?

No. RFC 7208 requires a single SPF record per name. Two records cause a permanent error, so merge new services into the existing record.

What does DMARC p=reject do?

It tells receiving servers to reject messages that fail DMARC checks. It is the strictest policy, so a mistake in SPF or DKIM turns directly into rejected mail.

How can I test that email works after a DNS change?

Send a message from each sending service to a mailbox at another provider, then read the Authentication-Results header for SPF, DKIM and DMARC. Also send a message to the domain from outside and check that it arrives.

Sources

Read on . Standards and vendor pages change; confirm the current text before you rely on it.

Terms used in this guide

  • MX recordAn MX record lists the mail servers for a domain with priorities. What happens to email when it is missing or points to the wrong provider.
  • SPFSPF is a DNS record listing the servers allowed to send email for a domain. The one-record rule, the ten-lookup limit and the mistakes that make mail fail.
  • DKIMDKIM adds a cryptographic signature to outgoing email, verified with a public key in DNS. Where the key lives and what happens when the selector record is removed.
  • DMARCDMARC is a DNS policy that tells receivers what to do with email that fails SPF and DKIM alignment: nothing, quarantine or reject. Why strict policies amplify DNS mistakes.
  • DNS recordA DNS record is one entry in a domain’s zone that maps a name to data such as an address, a mail server or a text value. The common types and what breaks when one changes.

Know first. Know why. Tell your client before they call.

Paste your client list. Both regions start checking.

Start the 14-day trialWhat Beamfar watches

No card for the trial.