Why did email stop working after a DNS change?

`dig example.com MX +short` — the servers that accept your incoming mail, with their preference values. An empty answer means mail is not being delivered.

`dig example.com TXT +short` — look for a record beginning `v=spf1`. Exactly one must exist; zero means no policy and two means a broken one.

`dig _dmarc.example.com TXT +short` — the DMARC policy. Losing it does not stop mail, and it removes the protection against your domain being forged.

`dig <selector>._domainkey.example.com TXT +short` — the DKIM key. The selector is not discoverable from DNS; it appears in the headers of any message your domain has sent.

Compare each against what your mail provider's documentation specifies, rather than against memory.

Missing MX records cause a bounce at the sender's end. You receive nothing and no notification, and the first symptom is someone mentioning they never heard back.

Missing SPF or DKIM does not stop messages leaving. They arrive, and a share of them land in spam folders or are rejected by stricter receivers.

A DMARC policy of `reject` combined with broken SPF and DKIM is the harshest version: mail is refused outright because it now fails every check.

None of this appears on the website, in a web server log, or in any monitoring aimed at the site.

Moving to a new DNS provider and importing only the records the website needs, because the export was filtered or the import was manual.

A hosting control panel that offers to reset the zone to its defaults when a domain is attached, which is how a working zone becomes a template.

Adding a CNAME at a name that also carried MX records. A name with a CNAME may hold no other records, and the mail routing becomes unusable.

Replacing the apex A record set with a provider's flattening alias, which some implementations apply more broadly than intended.

Deleting TXT records that looked like leftover verification strings and were actually SPF or a DKIM key.

Republish MX first, with the same targets and preference values your provider documents. Delivery resumes as soon as caches expire.

Republish exactly one SPF record. Two records beginning `v=spf1` mean the domain has no valid policy at all, which is a common outcome of restoring hastily.

Republish DKIM under the same selector, which matters: a key under a different selector does not validate signatures already in flight.

Republish DMARC last, and consider setting `p=none` briefly while the other two are confirmed, so a strict policy does not reject your own mail during the repair.

Senders retry for days, so mail sent during the outage usually arrives once MX is restored.

Export the full zone before any change and keep it. A text file of the previous state turns a two-day investigation into a five-minute restore.

Change records individually rather than replacing a zone, whenever the provider allows it.

Keep a written note of the DKIM selectors in use, since they are the one record you cannot rediscover from DNS alone.

VeriFixScan reports `email.mx.present`, `email.mx.resolution`, `email.spf.present`, `email.spf.single` and `email.dmarc.present` from a live lookup, which turns this whole check into one pass.