The DNS Checklist to Run Before You Point a Domain at Production

DNS is invisible until it fails, and when it fails it fails expensively: password-reset emails land in spam, attackers spoof your domain, or a forgotten subdomain gets taken over. Most of it is a one-time setup you can verify in an afternoon.

The email trio: SPF, DKIM, DMARC

Three records, three different jobs. What each one actually proves is the long version; this is the checklist form.

• SPF — lists which servers may send mail for your domain. Exactly one record, and no more than ten DNS lookups when it is evaluated. Mind how it ends: ~all and -all mean something, ?all and +all largely do not.
• DKIM — publishes a public key so receivers can verify a signature your sending service adds to each message. Your provider gives you the record; the failure mode is forgetting to publish it, or publishing it on the wrong selector.
• DMARC — tells receivers what to do when SPF and DKIM fail, and where to send reports. Start at `p=none` and move to `p=reject` once the reports show your own mail passing.

Lower your TTLs before you move anything

The single most useful thing to do before a migration, and it has to happen in advance. A record with a 24-hour TTL can be cached by resolvers for a full day after you change it, so a cutover you planned for a quiet Sunday morning is still half-propagated on Monday.

Drop the TTL on the records you intend to change to 300 seconds at least a day ahead — the old TTL governs how long the old value lingers, so lowering it the hour before the move achieves nothing. Raise it back afterwards once the new value is confirmed everywhere.

Beyond email

• CAA records — restrict which certificate authorities can issue certs for your domain.
• Dangling CNAMEs — a subdomain pointing at a deprovisioned service is a subdomain-takeover waiting to happen.
• Correct A/AAAA records and sane TTLs so a future migration is not gated on a day-long cache.

The part everyone forgets: can the domain receive mail?

Sending is set up carefully because a broken password reset is loud. Receiving is set up by nobody, because nothing breaks visibly. If your domain has no MX record and your footer publishes hello@yourdomain.com, every message to that address bounces at the sender's server — you never see it, and the symptom is simply that nobody ever contacts you. The contact address on your site might be silently bouncing covers how to test it in about a minute.

Pre-launch checklist

1. Confirm SPF, DKIM and DMARC all resolve and validate for the domain you send from.
2. Confirm there is exactly one SPF record and exactly one DMARC record — a second copy of either disables it entirely.
3. Send a test message to an address at a large mailbox provider and read the received headers: they will tell you plainly whether SPF, DKIM and DMARC passed.
4. Confirm the domain can receive mail at whatever address your site publishes.
5. Audit every subdomain for dangling CNAMEs pointing at deprovisioned services.
6. Set a CAA record if you have not already.

ShipReady resolves these records live and validates their contents rather than just their existence — a malformed SPF record, a DMARC policy that parses but enforces nothing, a domain that publishes a contact address it cannot receive mail at. It does not check blocklists; for that, query the domain against a reputation service directly.