Email Deliverability DNS Records Explained

Most operators treat DNS as a setup task. It is a running system, and the record that was correct on day 1 breaks on day 90 when a vendor quietly adds an IP block to an include you inherited. We run outbound for 50 plus B2B companies, and DNS drift is the most common silent failure in the whole book. Below, every record a sending domain needs in real syntax, the lookup budget that breaks SPF without warning, and the publish order that stops authentication from failing on your first send.

What DNS Records Does a Sending Domain Actually Need?

There is a difference between the records that authenticate you and the records that make the domain function as a real mailbox, and most setup guides only cover the first group. A domain with perfect SPF, DKIM, and DMARC but no MX record still looks like a throwaway to a receiving filter, because a legitimate business domain can accept mail. A domain with a shared tracking link inside the message body still carries somebody else's complaint history in every send.

Here is the whole stack in one place. Everything above the divider is required. Everything below it is the layer that separates a domain that merely authenticates from one that reads as a real business.

TXT record

A DNS record type that holds arbitrary text at a given hostname. SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI are all TXT records. They are distinguished not by type but by the host they sit on and the version tag they open with, which is why 2 different systems can publish 2 TXT records at the same hostname without colliding, and why publishing 2 records that both open with v=spf1 invalidates both.

Selector

The label in front of _domainkey that names one specific DKIM key pair. Google Workspace uses google by default, Microsoft 365 uses selector1 and selector2, and most sending platforms let you pick your own. A selector exists so one domain can hold several active DKIM keys at once, which is what lets you rotate a key or add a second sending platform without a gap in signing.

If you are standing this up from scratch rather than repairing an existing domain, the sequencing sits inside the broader build in how to set up email domains for outbound, and the conceptual version of the 3 authentication records lives in what SPF, DKIM, and DMARC actually do. This page is the syntax and operations layer underneath both.

What Does Each Record Look Like in Real Syntax?

Vendor documentation shows you a copy box and never explains the grammar, so operators paste records they cannot read and then cannot debug. Here is each one written out, field by field.

MX. Google Workspace now uses a single record: host @, priority 1, value smtp.google.com. Microsoft 365 uses host @, priority 0, value yourdomain-com.mail.protection.outlook.com. Publish one set or the other, never both. Two competing MX sets is how replies start disappearing into a mailbox nobody checks.

SPF. A TXT record at the root of the domain:

• v=spf1 opens the record and must come first. Anything before it voids the record.
• include:_spf.google.com imports Google's authorized IP set. One include per sending system.
• ip4:203.0.113.7 authorizes a single IP directly, which costs no DNS lookup.
• ~all closes the record with soft fail. Everything after all is ignored, so all goes last.

Assembled, that reads v=spf1 include:_spf.google.com ip4:203.0.113.7 ~all. The enforcement mode at the end has 4 options and only 2 are sane. Use ~all on a domain that sends mail, because hard fail breaks legitimate forwarding through an alias or a shared inbox. Use -all on a parked domain that should never send anything. Never use ?all, which declares no policy, and never use +all, which authorizes the entire internet to send as you.

DKIM. A TXT record at selector._domainkey.yourdomain.com, holding the public half of the key pair:

• v=DKIM1 opens the record.
• k=rsa names the key algorithm.
• p=MIIBIjANBgkqhkiG9w0B... is the base64 public key itself.

A 2048 bit key runs past the 255 character ceiling on a single DNS string, so it has to be published as 2 quoted strings that the resolver concatenates. Some DNS panels do this for you and some make you split it by hand. A provider that cannot handle split strings is the only acceptable reason to fall back to a 1024 bit key, and per RFC 6376 the signing spec assumes keys of at least 1024 bits with longer keys preferred for anything long lived.

DMARC. A TXT record at _dmarc.yourdomain.com:

• v=DMARC1 opens the record and must come first.
• p=none is the policy for failing mail. The ladder is none, then quarantine, then reject.
• rua=mailto:dmarc@yourdomain.com is the aggregate report address, the field most operators leave off and then wonder why they have no visibility.
• adkim=r and aspf=r set relaxed alignment, which lets a subdomain satisfy the check. Strict is s.
• pct=100 applies the policy to all failing mail, and fo=1 asks for a forensic report whenever either check fails.

Assembled: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100; fo=1. The semicolons are required separators and the whole thing lives on one line.

Tracking CNAME. A CNAME at a subdomain such as track.yourdomain.com pointed at whatever host your sending platform gives you. One record, 5 minutes, and it is the difference between a link domain you own and a shared host carrying thousands of other senders' complaints.

MTA-STS and TLS-RPT. A TXT record at _mta-sts.yourdomain.com reading v=STSv1; id=20260924000000, plus a plain text policy file served over HTTPS at mta-sts.yourdomain.com/.well-known/mta-sts.txt. TLS-RPT is a TXT record at _smtp._tls.yourdomain.com reading v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com. The id field is a version stamp you bump whenever the policy file changes, and forgetting to bump it is why an updated policy never takes effect.

BIMI. A TXT record at default._bimi.yourdomain.com reading v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem. Per the BIMI Group specification, the logo must be SVG Tiny Portable/Secure and the domain must already sit at quarantine or reject, so BIMI is the last record you publish, never the first.

Why Does SPF Break at 10 DNS Lookups?

RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS mechanism lookups per check, plus a separate cap of 2 void lookups. Cross either one and the receiver returns a PermError, which is not a partial failure. SPF is simply off for every message the domain sends, and it stays off until somebody counts the mechanisms by hand.

The lookup budget is spent by include, redirect, a, mx, exists, and ptr. The trap is that the count is recursive. One include:_spf.vendor.com looks like a single line in your record, but if that vendor's record itself contains 4 includes, you just spent 5 of your 10. Nothing in your DNS panel shows you that number, and the vendor can raise it next quarter without telling anyone.

The second cap is the one almost nobody knows. A void lookup is a query that comes back NXDOMAIN or empty. Two stale includes pointing at vendors you stopped using in 2024 will trigger PermError on their own, even with a total mechanism count of 6. Valimail's write up of the lookup limit and EasyDMARC's PermError guide both walk the recursion in detail. A 2026 scan by DMARCguard of 5.4 million domains from the Tranco list found 148,655 SPF enabled domains, roughly 4.8 percent, already over the limit and returning PermError on every send.

There are 3 real fixes and they rank in this order. First, delete. Most records carry 2 or 3 includes for platforms nobody has sent from in a year, and removing them is free. Second, separate. Move transactional and marketing sending onto their own subdomains, each with its own SPF record and its own budget, which is the same reasoning behind a multi domain sending strategy and running a secondary domain. Third, flatten. Resolve each include down to its underlying ip4 ranges and publish those directly, which costs zero lookups but goes stale the moment the vendor renumbers, so a flattened record needs a monthly refresh on the calendar or it becomes a different kind of outage.

What Order Do You Publish the Records In?

The order is not cosmetic. Each record is read in the context of the ones before it, and publishing them out of sequence produces reports that look broken when the configuration is fine, or worse, a policy that tells the world to reject your own mail.

1. Lower the TTL first. Before touching anything, set the TTL on the records you plan to edit to 300 seconds and wait out the old TTL. This is the step everyone skips, and it is why a 1 character typo takes a full day to undo instead of 5 minutes.
2. Publish MX. The domain has to be able to receive before it has any business sending. This also gets bounce handling working before volume starts, which matters for the diagnostics in bounce rate causes and fixes.
3. Publish SPF. One record, every authorized sender, ~all at the end. Count the recursive lookups before you save, not after.
4. Generate and publish DKIM. 2048 bits, published at the selector the platform gives you, then enable signing in the platform only after the record resolves. Signing before the public key is live means every message goes out with a signature nobody can verify.
5. Publish DMARC at p=none. Last of the 4, because DMARC is a policy over SPF and DKIM results. With a rua address attached, this is the moment visibility switches on.
6. Publish the tracking CNAME. Then confirm the platform is actually using it, because most tools keep the shared default until you flip a setting.
7. Send a real test and read the headers. Not a syntax checker. An actual message to an inbox you control at each major receiver.
8. Raise the TTL back and start warmup. DNS is now stable, so put the TTL back to 3600 and begin the ramp described in warming up a new domain. Authentication is the license to send, not the permission to send at volume, which is the distinction email warmup explained covers.
9. Tighten DMARC on a clock. 30 days at none, then quarantine, then reject, moving only when the aggregate reports show clean alignment on essentially all legitimate mail.

Which DNS Mistakes Silently Break Authentication?

Every failure below shares one property: the mail still sends. Nothing bounces, no dashboard turns red, and the only visible symptom is a reply rate that drifts down over 6 weeks while everyone argues about the copy. That is what makes DNS the highest leverage boring work in outbound.

The failure pattern is consistent enough to predict. A domain ships clean for 60 to 120 days. Reply rate sits where it should against the numbers in cold email reply rate benchmarks. Then a vendor renumbers, the lookup count crosses 10, SPF goes to PermError, and placement erodes slowly enough that nobody connects the 2 events. By the time it surfaces in a campaign retro, domain reputation has already taken damage that outlasts the fix, and the recovery work in recovering a burned domain takes far longer than the audit would have.

Do You Need MX, PTR, a Tracking Domain, MTA-STS, and BIMI?

MX is not optional and it is not really about authentication. A domain that cannot receive mail cannot receive a reply, which is the entire point of outbound, and it cannot receive a bounce, which is how you learn a list is bad. Filters also read a missing MX as a signal, because a domain built to send and never listen is what a throwaway looks like.

PTR, the reverse DNS record on the sending IP, is owned by whoever owns the IP. On Google Workspace or Microsoft 365 that is the provider and it is already correct. On a dedicated IP it is yours, and it needs forward confirmed reverse DNS, meaning the IP resolves to a hostname and that hostname resolves back to the same IP. Several receivers reject outright on a missing or mismatched PTR, which makes it the one record in this article that fails loudly instead of quietly.

The tracking CNAME is the highest return 5 minutes in the whole setup. Sending platforms rewrite every link in your message to route through a tracking host, and on the default setting that host is shared across thousands of accounts on the same tool. Their complaints, their spam traps, and their blocklist entries all attach to the link domain sitting inside your message body. A CNAME at track.yourdomain.com moves that onto a domain you own and keeps the link domain aligned with the sending domain, which is one of the checks in inbox placement testing and a recurring cause in blacklist monitoring.

MTA-STS and TLS-RPT protect mail coming to you, so they do not move placement on mail going out. They are still worth publishing on any domain that receives replies, because encryption enforcement is a trust signal and TLS-RPT is the only way to learn about a downgrade attempt. BIMI is genuinely last: it requires DMARC at quarantine or reject, an SVG Tiny Portable/Secure logo, and for Gmail and Apple a Verified Mark Certificate. On an invite domain sending to individual buyers rather than a subscribed list, it is a nice signal and nothing more.

How Do You Verify the Whole Stack Before the First Send?

Syntax checkers tell you a record parses. They cannot tell you a record aligns, and alignment only shows on real mail flow. So the verification sequence is 2 layered passes, never just the first.

1. Query the raw records. Run dig TXT yourdomain.com, dig TXT selector._domainkey.yourdomain.com, and dig TXT _dmarc.yourdomain.com, or use MXToolbox SuperTool if you would rather read it in a browser. You are looking for exactly 1 v=spf1 record, a DKIM key that resolves, and a DMARC record with a rua address.
2. Count the SPF lookups. Use a checker that walks the include chain recursively rather than counting the lines in your record. dmarcian's SPF Surveyor draws the whole tree and gives a real number.
3. Send a real message to Gmail. Open it, use Show original, and read the SPF, DKIM, and DMARC lines in the header. All 3 should say PASS, and the DMARC line should show alignment, not just authentication. Google documents the header view directly.
4. Send a real message to Outlook. Microsoft applies its own logic and it has tightened through 2025 and 2026, so a Gmail pass is not proof of an Outlook pass. Check the authentication results header on the received copy.
5. Wait for the first DMARC aggregate report. Reports arrive daily, so 48 hours after publishing you should have real data listing every IP that sent as your domain. If nothing arrives, the rua address is wrong or the mailbox is rejecting the XML attachments.
6. Register for the postmaster dashboards. Google Postmaster Tools gives you spam complaint rate, domain reputation, and authentication pass rates for your own domain, which is the ground truth behind everything in deliverability monitoring.

Then repeat the whole thing monthly. Not because you changed something, but because your vendors did. The audit takes under 10 minutes per domain once you have the commands saved, and across a 30 domain footprint that is roughly 2 hours a month standing between you and the slow decay pattern that ends most sending infrastructure.

The Practitioner Take on DNS Records in 2026

The enforcement environment stopped being optional. Gmail and Yahoo set the bar in February 2024 with authentication, a one click unsubscribe header, and a spam complaint rate held under 0.3 percent, documented in Google's sender guidelines and Yahoo's sender best practices. Microsoft matched it on May 5, 2025 for anyone sending above 5,000 messages a day to Outlook.com, Hotmail, and Live, and the penalty there is a hard 550 rejection rather than a spam folder, per Microsoft's own announcement. PowerDMARC's cross provider summary lines up all 4 major receivers side by side.

What that changes for a cold email operation is smaller than it sounds. The 5,000 a day threshold is per domain, and a sane sending footprint spreads volume across many domains at low per mailbox volume, so most invite programs never approach it on any single domain. What matters is that the placement scoring rewards full authentication at every volume, and the whole industry has now standardized on the same 4 records. A domain missing one of them no longer looks unconfigured. It looks suspicious.

So treat DNS as running infrastructure with an owner and a cadence. Audit every sending domain monthly. Parse the DMARC reports weekly. Refresh flattened SPF on a 30 day clock and rotate DKIM keys yearly. Drop the TTL before you edit anything and raise it after. None of this is clever, and that is exactly why it gets skipped: there is no version of this work that produces a visible win, only the absence of a silent loss.

The operators who run it as infrastructure keep their placement and blame their copy when the numbers dip, which is usually the right place to look. The operators who set the records once and never return spend a year rewriting subject lines to fix a PermError. Staying out of the spam folder starts here, before the list, before the copy, before anyone argues about a first line.