Journey
NoteDNSemailinfra

Moving the phone book without dropping the mail

Moving a domain to a new DNS provider sounds like a settings change. It is — except for the one thing that breaks silently and that you won't notice for hours: email.

Two directions, different records

Mail has an inbound side and an outbound side, governed by different records — and some are checked on someone else's server, not yours.

Ingress — mail coming in

  • Governed by MX — "deliver our mail here"
  • Read by the sender's server, not ours
  • Miss it and inbound mail just stops

Egress — mail going out

  • Governed by SPF + DKIM + DMARC
  • Checked by the recipient's server (Gmail, Outlook)
  • Miss it and your mail lands in spam

The footgun that waits weeks

The nastiest one isn't email — it's the HTTPS padlock. A CAA record lists which certificate authorities may issue your cert. Get the list wrong and nothing breaks today; the next auto-renewal weeks later quietly fails, and the padlock dies for every visitor.

What we'd tell ourselves

Do

  • Write down MX / SPF / DKIM / DMARC before you touch anything
  • Recreate them on the new provider, all DNS-only (grey cloud)
  • Send yourself a test email before declaring victory

Don't

  • Assume the import caught every record
  • Add DKIM as a TXT record
  • Hand-type a CAA list and trust it's complete

The move itself took minutes. The care around it — the records, the test email, the one-CA CAA — is the part that let us sleep.

Sources

  1. pangaea.id — the repository