The Pre-Send DNS Checklist: 8 Records to Verify Before Day One

Most deliverability problems on a brand new sending domain are not mysterious. They are a missing DKIM key, two SPF records where there should be one, or a DMARC record with a typo. All of them are cheap to catch before the first send and expensive to discover after a campaign has gone out.

Work through these eight records in order. Every example uses example.com and documentation IP addresses from the 203.0.113.0/24 range; replace them with your own values and the ones your mailbox provider gives you.

1. MX: can the domain receive mail?

A sending domain that cannot receive replies looks like a throwaway, and replies to cold email are the whole point. Make sure the domain has MX records pointing at your mailbox provider.

example.com.  3600  IN  MX  10 mx1.mailprovider.example.
example.com.  3600  IN  MX  20 mx2.mailprovider.example.

Lower numbers are tried first. Use exactly the hostnames your provider documents.

2. SPF: one record, under ten lookups

SPF lists the servers allowed to send for your domain. Two rules break more setups than anything else:

• Only one SPF record per domain. Two v=spf1 TXT records cause a permanent error, and SPF fails for both.
• At most 10 DNS lookups. Every include, a, mx, exists and redirect counts, including the ones nested inside includes. Go over and SPF returns an error.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.mailprovider.example ip4:203.0.113.25 -all"

End with ~all (softfail) or -all (fail). Never use +all, which authorises the entire internet.

3. DKIM: 2048-bit where you can

DKIM publishes a public key under a selector your provider chooses. Use a 2048-bit key if your provider and DNS host support it; 1024-bit is still accepted but is the weaker option.

s1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

A 2048-bit key is longer than the 255 characters allowed in a single TXT string. Most DNS panels split it automatically; some need you to paste it as several quoted strings. If the checker cannot parse your key, this is usually why.

4. DMARC: start at p=none, then tighten

DMARC tells receivers what to do when a message fails SPF and DKIM alignment, and where to send reports. Start in monitoring mode with a reporting address:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Read the aggregate reports for a few weeks. Once every legitimate source is passing and aligned, move to p=quarantine, and later to p=reject if you are confident. Gmail and Yahoo require at least p=none from bulk senders, and Microsoft now expects the same for high-volume senders to Outlook.com; see the sender requirements guide for details.

5. PTR: reverse DNS that matches forward DNS

If you send from a dedicated IP, the IP needs a PTR record pointing to a hostname, and that hostname needs an A record pointing back to the same IP. This is called forward-confirmed reverse DNS, and Gmail lists it as a requirement for all senders.

25.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.example.com.
mail.example.com.           3600  IN  A    203.0.113.25

PTR records are set by whoever controls the IP block, usually your sending provider or host, not in your normal DNS panel. On shared infrastructure the provider handles this for you.

6. Root domain: send visitors somewhere real

Prospects, and some filters, will visit the domain in your From address. A domain that resolves to nothing, or to a parked page, looks disposable. Point it at your main site with a redirect:

example.com.      3600  IN  A      203.0.113.80
www.example.com.  3600  IN  CNAME  example.com.
; the web server at 203.0.113.80 returns a 301 redirect to your main website

Many registrars offer URL forwarding that does the same thing without running your own server.

7. Custom tracking domain: a CNAME of your own

If you track opens or clicks, links are rewritten through a tracking domain. Using your sending tool's shared default means your links carry everyone else's reputation. Set up a custom subdomain instead:

track.example.com.  3600  IN  CNAME  tracking.sendingtool.example.

Make sure it serves HTTPS. Many cold senders also choose to turn open tracking off entirely, which removes the pixel and one more structural signal.

8. MTA-STS and TLS-RPT (optional)

These two protect mail coming into your domain by telling other servers to require encrypted connections, and give you reports when that fails. They do not directly improve placement for outbound cold mail, so treat them as good hygiene rather than a priority.

_mta-sts.example.com.    3600  IN  TXT  "v=STSv1; id=20260918"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
; plus a policy file served at https://mta-sts.example.com/.well-known/mta-sts.txt

How to verify all eight

1. Query each record with the DNS lookup tool and compare against what you intended to publish.
2. Run the domain through the SPF and DKIM checker to catch duplicate SPF records, lookup overruns and malformed keys.
3. Send a test message to a personal Gmail and Outlook address and confirm SPF, DKIM and DMARC all show pass in the headers.
4. Run an inbox placement test before warmup moves on to real sends.

Do not treat this as a one-time job. Re-run the checks whenever you add a new sending tool, change mailbox provider or edit any TXT record, because those are exactly the moments when a second SPF record or a dropped DKIM selector sneaks in. A short monthly pass over every sending domain catches the rest, and DMARC aggregate reports will tell you if something starts failing between checks.

When you add a domain in Sendbox, it shows the exact records to publish and checks them before mailboxes go live, so a missing key is caught at setup rather than in a bounce report. Either way, once the records are clean, move on to the first 30 days plan.