DNS for email senders

Your email configuration does not live in your ESP. It lives in DNS: a handful of public text records attached to your domain, readable by anyone, editable by whoever holds the keys to your DNS dashboard. Those keys are usually held by web people (a developer, an agency, an IT contractor, whoever holds the login) who have no idea the email records are load-bearing. That arrangement, working email whose life support is managed by people unaware of it, is the single most common way good setups die. This lesson gives you enough DNS to hold your own.

What DNS actually is

DNS, the Domain Name System, is the internet's public directory. When anything needs to know a fact about yourdomain.com, it asks DNS: what address the website lives at, which servers take your mail, and so on. The answers are records: typed, named entries that you (or your delegates) publish and the whole world can query.

Two properties matter for everything that follows. First, DNS is public. There is no login to view records, only to edit them, and this is why a health check can grade a domain's email setup from the outside in seconds. Second, DNS is authoritative in one place. Somewhere there is one set of servers holding the master copy of your domain's records; everything else is cache.

That master copy is called your zone: the complete set of DNS records for your domain, held on nameservers, the machines that answer queries about it.

Two dashboards, one of which does nothing

One distinction wastes more troubleshooting hours than any other. The registrar is the company you bought the domain from. The DNS host is the company whose nameservers actually hold your zone. They can be the same company. They frequently aren't.

The registrar's one relevant power is deciding which nameservers your domain points at. If you bought yourdomain.com at GoDaddy but someone later pointed the nameservers at Cloudflare, then your zone lives at Cloudflare, and the DNS editing screens inside GoDaddy are disconnected machinery. You can add records there all day. Nothing will happen, no error will appear, and the record "won't validate" for reasons that look supernatural.

We see this constantly with the free checkers: someone adds a record their ESP asked for, waits a day, and the check still says missing. Editing the wrong dashboard is the first thing to rule out, and our troubleshooting guide for records that won't validate puts it at the top of the list for that reason. The check is simple: look up your domain's current nameservers (any "NS lookup" tool will do, and registrars display it under nameserver settings). Whatever company those nameservers belong to is where your zone lives. Edit there and nowhere else.

The record types email cares about

A zone holds many record types. Email leans on five.

An A record maps a name to an IP address (yourdomain.com to 203.0.113.7). This is mostly the website's record, but it makes the list because it's the one web people care about, and because mail servers themselves need one.

An MX record, which you met when we followed a message, names the servers that accept incoming mail for your domain, each with a priority number. No valid MX generally means no incoming mail, and domains that can't receive mail look disposable to filters even as senders.

A TXT record holds free-form text, and it became the junk drawer of DNS: site-verification codes and security policies of every stripe pile up there. Most importantly for us, SPF and DMARC (two of the email authentication records the next module teaches) live in TXT records. This is worth pausing on. The mechanisms that decide whether your mail authenticates are, physically, lines of text in the same list as the website's records, one careless bulk edit away from deletion. Some TXT records also have placement rules: DMARC's record must live at the name _dmarc.yourdomain.com, not at the root, and getting the name wrong is as fatal as omitting the record.

A CNAME record is an alias: this name is answered by that other name. ESPs love CNAMEs for authentication setup because the alias points into DNS they control, and they can rotate the underlying keys without asking you to edit anything again. Two real failure modes from our checker data, both sourced from the providers' own setup docs: with Mailchimp's authentication CNAMEs, some DNS dashboards silently append your domain to the name you paste, so the record ends up answering at k1._domainkey.yourdomain.com.yourdomain.com (some Mailchimp accounts also get k2 and k3 selectors): it exists, and it is useless. And with beehiiv's custom domain records, Cloudflare users leave the proxy (the orange cloud) enabled on the CNAME, which rewrites the answer and breaks verification; those records must be set to DNS-only. Neither failure produces an error message anywhere. The records sit there looking done.

A PTR record runs the whole system in reverse: it maps an IP address back to a name. Reverse DNS lives in the zone of whoever owns the IP block, which for nearly all senders means your ESP or hosting provider, so it's the one email-relevant record you usually can't edit yourself. For now, just register that it exists and that receivers check it; it returns in the ecosystem lesson and again when we cover what mailbox providers require.

TTLs, and why "propagation" is a myth with a true core

Every DNS record carries a TTL, a time-to-live: the number of seconds any server that fetched the answer may keep serving it from cache before asking again. TTLs of 300 (five minutes) to 86400 (a day) are all normal.

When people say a DNS change is "propagating", they're picturing the new value spreading outward across the internet like ink in water. That's not what happens. Nothing is pushed anywhere. Your nameservers began giving the new answer the instant you saved. What takes time is everyone else's caches expiring: any resolver that fetched the old record keeps serving it until that record's TTL runs out, and only then asks again and sees your change. "Propagation delay" is cache expiry, nothing more.

This explains the maddening inconsistency of fresh changes: your phone sees the new record while your laptop still serves the old one, each sitting behind a cache in a different stage of expiry. It also yields a practical trick: before a planned change, lower the record's TTL a day in advance, make the change, then raise it back. The old short TTL means stale caches die quickly. (And when a check disagrees with an edit you just made, the boring explanation, a cache that hasn't expired, deserves consideration before the interesting ones.)

How a website migration breaks email

Now assemble the pieces into the failure this lesson exists to warn you about. Your SPF, your DKIM CNAMEs, your DMARC policy: all TXT and CNAME records in a zone. Who edits that zone in real life? The people doing website work. A site redesign moves hosting; an agency "migrates DNS" to a new provider.

The trap in its purest form: moving a zone to new nameservers copies nothing automatically. Whoever does the move recreates the records at the new host, and they recreate the ones they understand. The A record, obviously. The MX, usually, because "mail will break" is famous. The unlabeled TXT record holding your SPF, the _dmarc record, the odd-looking cname._domainkey entries? Those look like clutter, and clutter gets dropped.

The site comes up fine. Mail even keeps flowing, because sending doesn't require those records to exist; passing authentication does. So nothing visibly breaks on migration day. Your messages just start failing checks they used to pass, placement erodes over the following weeks, and the eventual investigation has to connect this month's open rates to last month's website project. Across the domains we monitor, a DNS change nobody flagged as email-related is the leading cause of that "suddenly going to spam" story; the six-cause breakdown puts it at number one.

Two defenses, both cheap. Keep an inventory: a plain list of every email-relevant record in your zone and why it exists, so no future migrator has to guess what's clutter. And verify after any DNS-adjacent project, from the outside, against what's actually published: the free health check reads your live records and flags what's missing or broken, which turns "I think the agency copied everything" into an answer.

One piece of the map remains before we leave the machinery behind: who is who in email, the cast of companies and servers your messages pass through on their way to a reader.

Terms from this lesson

• DNS (Domain Name System) - the internet's public directory of facts about domain names, queried by every system that needs to reach or evaluate your domain.
• zone - the complete set of DNS records for a domain, held authoritatively on its nameservers.
• nameserver - a server that answers DNS queries for a zone; the ones your registrar points at hold the master copy.
• registrar - the company you bought the domain from; controls which nameservers the domain delegates to.
• DNS host - the company whose nameservers actually hold your zone; edits made anywhere else do nothing.
• A record - maps a name to an IP address.
• MX record - names the servers accepting incoming mail for a domain, in priority order.
• TXT record - free-form text attached to a name; SPF and DMARC are published as TXT records.
• CNAME record - an alias pointing one name at another; the mechanism ESPs use for authentication records they can manage remotely.
• TTL (time to live) - how many seconds a cached DNS answer stays valid; the real cause of "propagation" delay.

Check yourself

1. You add a TXT record at your registrar's DNS page, but a day later every checker says it doesn't exist. What's the most likely cause?

The record is still propagating and needs a weekTXT records need approval from the registrarThe checker only reads records once a monthYour domain's nameservers point at a different DNS host, so you edited a disconnected dashboard

2. What is actually happening during DNS 'propagation' after you change a record?

Caches holding the old answer are expiring as each one's TTL runs outYour new record is being copied to every DNS server in the worldThe registrar is approving and forwarding the changeThe record is waiting for the next daily DNS synchronization

3. Why do ESPs often ask you to add CNAME records for authentication instead of pasting keys directly?

CNAMEs are faster to resolve than TXT recordsCNAME records cannot be deleted by accidentThe alias points into DNS the ESP controls, so it can rotate keys without you editing anything againMailbox providers only trust CNAME records

4. After a website migration to a new DNS host, mail keeps sending but starts failing authentication. Why does this pattern make sense?

Migrations always block outgoing mail for 30 daysSending doesn't require the records to exist, but passing SPF, DKIM, and DMARC checks doesThe new DNS host has to re-verify the domain with each ESPEmail records are automatically copied but take a month to activate