Email DNS records: the complete checklist

Deliverability starts in DNS. Before warmup, before a single campaign, your sending domain needs a small set of records that tell Gmail, Outlook and everyone else that mail claiming to be from you really is from you. This page is the map: every record, what it does, and what Warmerly does and does not check. Each record also has a step-by-step guide of its own, linked below.

#The whole set, in one table

One row needs emphasis because it is the one people skip: your domain needs working MX records even if you only intend to send. A sending-only domain with no inbound mail path looks disposable, and it means replies from the prospects you worked to win simply bounce.

#Do them in this order

1. MX first. Connect the mailbox at your provider and confirm mail arrives. Everything else authenticates mail from a mailbox that already works.
2. SPF. One TXT record at the root, listing your provider. See SPF & DMARC.
3. DKIM. Get the selector and key from your provider and publish it. See Setting up DKIM, plus click-by-click guides for Namecheap, IONOS, GoDaddy and Cloudflare.
4. DMARC, starting at p=none. Monitor first, tighten later. See SPF & DMARC.
5. Tracking CNAME, if you want links on your own domain. See Custom tracking domain.
6. Then warm up. How warmup works explains why this order matters.

#What each record looks like

#SPF

Type:  TXT
Name:  @
Value: v=spf1 include:_spf.google.com ~all

Exactly one SPF record per domain. Two SPF records is not twice the protection. It is a permanent error, and it is the single most common SPF mistake. If you send through more than one provider, merge them into one record with several include: terms.

~all (softfail) is the sane default while you are setting things up; -all (hardfail) is stricter and worth moving to once you are certain every sender is listed.

#DKIM

Type:  TXT
Name:  selector1._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...

The selector is whatever your provider tells you, google, selector1, k1, zoho, onemail1, something custom. Some providers (Microsoft 365, Mailchimp, Livemail) have you publish CNAME records pointing at their infrastructure instead of the TXT record itself; that is equally valid, and the public key lives on their side.

#DMARC

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

Start at p=none. It changes nothing about delivery and starts the reports flowing, which is how you find out what is actually sending as your domain before you tell the world to reject it. Move to p=quarantine, then p=reject, once those reports are clean.

#MX

Type:     MX
Name:     @
Value:    (your provider's host, e.g. aspmx.l.google.com)
Priority: 1

Use your provider's published list, in their priority order. Do not mix MX records from two mail providers on one domain.

#Tracking CNAME

Type:  CNAME
Name:  track
Value: (the target Warmerly shows you)

Then make sure HTTPS works for that name. Warmerly does not issue the certificate, so the domain has to sit behind a service that does, such as Cloudflare with the proxy on. The tracking domain guide covers it, and it catches people out.

#What Warmerly actually checks

Warmerly runs its own DNS check per mailbox domain and shows it on the mailbox, and the same check drives campaign readiness. It looks at four of the records above, SPF, DKIM, DMARC and MX, and reports each as pass, none, fail or error:

Two limits are worth knowing, because both produce a scary-looking result on a domain that is genuinely fine:

• DKIM selectors are guessed. Warmerly tries a long list of common selector names (default, google, selector1, k1, zoho, onemail1, and many more). It cannot discover an arbitrary custom selector. If yours is not on that list the check reports none while your mail is signed perfectly well, enter your real selector on the mailbox (Accounts → the mailbox → Settings → DKIM selector) and re-check. Full explanation in Troubleshooting.
• The tracking CNAME is checked separately, in the mailbox's Settings tab under Custom tracking domain. A green DNS panel is not a statement about it.

Over the API the same data is available as GET /accounts/{id}/dns, and POST /accounts/{id}/dns re-runs the check on demand.

#After you save a record

• Propagation takes minutes, occasionally hours. Your DNS host's TTL decides it. Re-check rather than re-adding; a duplicate record is worse than a slow one.
• Check the name your host actually saved. Many control panels append the domain automatically, so typing selector1._domainkey.yourdomain.com produces selector1._domainkey.yourdomain.com.yourdomain.com. If the record will not resolve, this is the first thing to look at.
• Quote the value if your host requires it, and never break a long DKIM key across lines yourself.
• Check the domain, not the subdomain. Mail DNS for mail@yourdomain.com lives on yourdomain.com, not on www.yourdomain.com.

#Common mistakes, in the order we see them

1. Two SPF records on one domain (reports fail).
2. A custom DKIM selector Warmerly cannot guess (reports none, mail is fine).
3. The host silently appending the domain to the record name.
4. No DMARC record at all: the easiest win on this page, and p=none costs nothing.
5. No MX records on a send-only domain, so every reply bounces.
6. A DMARC policy tightened to p=reject before the reports were read, which starts rejecting legitimate mail from a tool nobody remembered was sending as the domain.

#Check it from outside

You can check any domain's setup (yours or a prospect's) with the public deliverability checker, which runs the same SPF/DKIM/DMARC logic and needs no account. Programmatically that is POST /api/v1/public/deliverability-check, the one endpoint in the API that takes no credentials (10 requests per hour per IP, see Errors & rate limits).

#Related

• Setting up DKIM · SPF & DMARC · Custom tracking domain
• Connecting a mailbox: SMTP/IMAP settings, app passwords, Microsoft 365 errors
• Troubleshooting: when a record exists but Warmerly disagrees