What breaks
If the MX records are deleted, senders have nowhere to deliver and messages bounce or are delayed. If they point to a former provider, mail goes to a mailbox no one reads. A website DNS change that replaces the zone or the nameservers is the usual way MX records are lost.
How it fits with authentication
MX decides where mail is delivered. SPF, DKIM and DMARC decide whether mail sent as the domain is trusted. A migration that changes one should be checked for the others.
An example
example.com. 3600 IN MX 10 mx1.mailhost.example. and example.com. 3600 IN MX 20 mx2.mailhost.example.: senders try mx1 first, because 10 is the lower number, and mx2 only if the first is unreachable. dig MX example.com +short lists them. An MX that points at the website’s own address, left over from an old setup, is a sign that mail may be delivered to a server that runs no mail service.
After any change of mail provider, send a test message from an outside account to the domain and one back out, then read the headers of both: delivery shows the MX records are right, and the authentication results show that SPF, DKIM and DMARC still hold.
What to check
The list of MX records and their priorities against the mailbox provider’s current instructions, and a real test message sent from outside to the domain.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 7208, Sender Policy Framework (SPF) (www.rfc-editor.org)