The 6-record cold email DNS stack
- MX — point to Google or Microsoft, remove all old records.
- SPF — exactly one TXT, ends with ~all, under 10 lookups.
- DKIM — 2048-bit key, generated in the provider console.
- DMARC — start at p=none, ramp to quarantine, end at reject.
- MTA-STS + TLS-RPT — enforce TLS, get encryption reports.
- A record on apex — point to a real landing page.
1. What DNS records cold email actually needs
Marketing posts list four records (MX, SPF, DKIM, DMARC). Real cold-email infrastructure uses eight. Here is the full set, ordered by how much each one moves inbox placement in 2026 — based on what mailbox providers like Google and Microsoft now publicly weigh in their authentication reports and what the Yahoo/Google February-2024 sender requirements forced everybody to adopt.
| Record | Required? | What it does |
|---|---|---|
| MX | Required | Routes inbound mail to your provider |
| SPF (TXT) | Required | Authorizes which servers can send as you |
| DKIM (TXT/CNAME) | Required | Cryptographically signs every message |
| DMARC (TXT) | Required | Tells receivers how to handle SPF/DKIM failures |
| MTA-STS | Recommended | Enforces TLS on inbound mail |
| TLS-RPT | Recommended | Reports TLS failures so you can debug them |
| A / AAAA (apex) | Recommended | Hosts a real landing page so the domain looks legitimate |
| PTR | Provider-managed | Reverse DNS — handled by Google/Microsoft |
| BIMI | Optional | Renders your logo in Gmail when DMARC is at reject |
BIMI is the only record on this list that is purely cosmetic. Everything else compounds: MX without SPF still routes mail, but SPF without DKIM gets you flagged, and DMARC without alignment is decoration. Treat the table as an ordered checklist, not a menu. For the underlying strategy, our companion piece on cold email infrastructure covers domain selection, mailbox count, and warmup pacing.
One mental model that helps: think of DNS records as the difference between identity (who you claim to be) and authorization (what receivers should do with messages claiming to be you). MX is purely operational routing. SPF, DKIM and DMARC together form a three-part assertion: SPF says "this IP is allowed to send for me", DKIM says "this exact message was signed by me", and DMARC says "and here is what to do if either of those fails." MTA-STS and TLS-RPT then layer transport security on top. The point of the stack is defense in depth — a single failed check should not topple delivery, but a coherent set of passing checks should clear the inbox bar at every major receiver. Cold email is harder than transactional mail precisely because you do not have a relationship with the recipient, so every authentication signal you can produce buys you margin against the spam filter's prior.
2. MX records — Google Workspace and Microsoft 365 (real values)
MX records tell the world where to deliver mail addressed to your domain. The single most common cold-email DNS bug we see is leftover MX records from a previous provider creating dual-MX routing, which silently breaks DKIM alignment and tanks DMARC pass rates.
Google Workspace (current 2026 single-host setup)
Google deprecated the five legacy ASPMX hosts in 2023. The modern single-host record is the default for new Workspace tenants — but most tutorials still show the old five-record setup, which still works but is no longer required.
See our Google Workspace setup guide and StackMail for Google Workspace for full provisioning steps.
Microsoft 365
Microsoft uses dashes where the original domain has dots (example-com.mail.protection.outlook.com for example.com). See the StackMail for Microsoft 365 page for end-to-end setup.
Watch out: Do not keep both Google and Microsoft MX records active at once. Receivers will pick the lowest priority and silently route around the other — DKIM will fail alignment because the outbound and inbound providers do not match.
3. SPF — what to publish, common mistakes, include vs all
SPF (Sender Policy Framework, defined in IETF RFC 7208) is a single TXT record at your domain apex listing every server allowed to send as you. Receivers do a DNS lookup, expand the includes, and verify the connecting IP is in the resulting set.
The canonical SPF record
That is it for a Google-only domain. For Microsoft 365:
For a domain that sends through Google plus a sequencer plus a transactional sender, merge into one record:
The 10-DNS-lookup limit (the #1 SPF killer)
Every include:, a, mx, ptr, exists and redirect mechanism counts toward a hard limit of 10 DNS lookups during SPF evaluation. Cross it once and SPF returns PermError, which Gmail and Outlook treat as a fail. include:_spf.google.com alone resolves to four lookups. Stack two ESPs and a payment provider and you are over the line.
Audit your record with our SPF checker. If you are over the limit, in priority order: (1) drop unused includes, (2) replace include: with explicit ip4: ranges, (3) only as a last resort use SPF flattening — flattened records become stale the moment the upstream provider rotates IPs and you will not be notified.
~all vs -all
~all means soft-fail ("treat unauthorized senders as suspicious") and -all means hard-fail ("reject unauthorized senders"). Start with ~all for the first 30 days while you discover legitimate senders you forgot about (calendaring, helpdesk, payroll, billing). Once your DMARC reports come back clean for two weeks, flip to -all.
4. DKIM — key generation, 1024 vs 2048, rotation
DKIM (DomainKeys Identified Mail) signs every message you send with a private key held by your mailbox provider. Receivers fetch the public key from a TXT record at selector._domainkey.yourdomain.com and verify the signature. If the signature is valid and the From: domain matches the signing domain (alignment), DKIM passes.
1024 vs 2048 — always pick 2048
1024-bit RSA keys are factorable on commodity hardware in days and Google now flags them in the Postmaster Tools authentication report. 2048-bit keys are the modern standard and the only meaningful cost is that the public key wraps across multiple 255-character TXT chunks — every registrar handles that automatically. Use 2048.
Google Workspace DKIM (TXT record)
Generate the key in Google Admin under Apps → Google Workspace → Gmail → Authenticate email. After publishing the TXT record and waiting for propagation, return to that page and click "Start authenticating" — the switch only flips after the public key resolves.
Microsoft 365 DKIM (CNAME records)
Rotation policy
Rotate DKIM keys every 6–12 months. Always keep two selectors live during rotation (selector-2026a and selector-2026b) so signing never gaps. Microsoft handles rotation automatically with the dual selector1/selector2 CNAMEs. For Google, generate a new key alongside the existing one, switch the active selector in Admin, and remove the old TXT record after 30 days. Verify with our DKIM checker after every rotation.
5. DMARC — p=none, p=quarantine, p=reject
DMARC is the policy layer that ties SPF and DKIM together. It tells receivers what to do when a message fails authentication AND it asks them to send you reports so you can see who is sending as your domain. Read the primary spec at dmarc.org. The record lives at _dmarc.yourdomain.com.
The three policies
- p=none — monitoring only. Failures are reported to you but delivered normally. Always start here.
- p=quarantine — failures land in spam. Move here once your reports show 95%+ pass rates for two consecutive weeks.
- p=reject — failures are bounced at the SMTP layer. Ultimate protection against spoofing; required for BIMI; required by Yahoo/Google for high-volume bulk senders since February 2024.
When to move from each policy to the next
- Publish p=none with rua reporting. Wait 14 days, parse reports.
- Identify legitimate senders missing from SPF/DKIM (helpdesk, calendaring, payroll). Add them.
- Once aggregate reports show ≥ 95% SPF or DKIM alignment for 14 days, move to
p=quarantine; pct=25. - Ramp pct over 4 weeks: 25 → 50 → 75 → 100.
- After 14 days at quarantine pct=100, switch to
p=reject.
Recommended cold-email DMARC records
RUA vs RUF reports
RUA (aggregate) reports are XML files sent daily by every major receiver summarizing pass/fail counts per source IP. They are the workhorse — every DMARC monitoring service is built on parsing these. RUF (forensic) reports are full message-level redacted samples sent on individual failures. Most receivers do not send RUF anymore for privacy reasons, so do not over-rely on them. Validate your policy with our DMARC checker.
6. MTA-STS — should you bother?
MTA-STS (Mail Transfer Agent Strict Transport Security) is the email equivalent of HSTS for HTTPS. It forces inbound mail to be delivered over TLS or rejected. For cold email sending domains the impact is mild — you mostly receive bounces, not real mail — but it is now part of the Yahoo/Google sender-requirements baseline and Google Postmaster actively scores it. So yes, publish it. The setup is fiddly but one-time.
You need three things: a TXT record at _mta-sts.yourdomain.com, a policy file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and a TLS-RPT record at _smtp._tls.yourdomain.com for failure reports.
If you are not running your own web server, point an A record for mta-sts.yourdomain.com at a static host (Cloudflare Pages, GitHub Pages) and serve the policy file from there. StackMail handles all of this automatically — see automated domain DNS setup.
7. Step-by-step: configure DNS at each registrar
The DNS values are identical at every registrar — only the UI differs. Below are the exact click paths for the four registrars that cover ~95% of cold-email domains.
Cloudflare
- Dashboard → select the domain → DNS → Records.
- Click Add record. Set Type, Name (use @ for apex), Content, TTL=Auto, Proxy=DNS only.
- For long DKIM TXT values, paste the full string — Cloudflare auto-chunks above 255 chars.
- Save. Records propagate in seconds because Cloudflare runs its own resolver edge.
GoDaddy
- My Products → Domains → DNS next to your domain.
- Scroll to Records → Add.
- Type the record. For host, GoDaddy uses @ for apex. TTL default 1 hour is fine.
- Save. Propagation typically 15–30 minutes; long DKIM may need a manual edit if it gets truncated.
Namecheap
- Domain List → Manage → Advanced DNS.
- Click Add new record, pick the type from the dropdown.
- Host = @ for apex, or the subdomain name (e.g. google._domainkey).
- Save (green checkmark). Namecheap propagates in 5–30 minutes.
Google Domains / Squarespace Domains
- (Google Domains migrated to Squarespace in 2024.) Squarespace → Domains → your domain → DNS.
- Add record → choose type, host, value, TTL.
- Squarespace handles long TXT records automatically.
- Propagation 5–10 minutes.
For a deeper provisioning walkthrough that covers domain purchase plus DNS plus Workspace seat creation, see our Google Workspace setup guide. Agencies running 30+ domains should look at our agency setup page.
8. How to verify DNS propagation
Three layers of verification, in order of trust:
Authoritative check with dig
Always pass @1.1.1.1 or @8.8.8.8 to bypass your local resolver cache. If the record returns at the authoritative nameserver but not at 1.1.1.1, you are still inside the TTL window.
StackMail validators
Receiver-side verification
Send a test message to a Gmail address you control and view the original (More → Show original). The Authentication-Results header should show spf=pass, dkim=pass, and dmarc=pass. Then enroll the domain in Google Postmaster Tools for the authoritative ongoing view. mxtoolbox.com is also useful for a second-opinion external check.
9. Troubleshooting — top 10 DNS errors and fixes
- Two SPF records. RFC 7208 forbids it. Merge into one.
- SPF PermError (over 10 lookups). Drop unused includes or replace with ip4: ranges.
- DKIM not signing despite TXT being live. You forgot to flip the toggle in Google Admin / Microsoft 365 admin center after publishing the record.
- DKIM truncated to 255 chars. Some legacy registrars clip the public key. Switch DNS to Cloudflare or use the registrar's "long TXT" / "DKIM-aware" option.
- DMARC reports flooding inbox. Route rua= to a dedicated mailbox or a parser like Postmark / Dmarcian / Valimail.
- DMARC alignment fails despite SPF and DKIM passing. Your From: domain does not match the signing or envelope domain. Check alignment mode (adkim/aspf — strict vs relaxed).
- MX records pointing to two providers. Pick one. Remove the other.
- Wildcard MX from old DNS templates.
*.yourdomain.com MXbreaks subdomain delivery. Delete it. - TTL set too high during migration. Drop to 300s 24 hours before the change, then raise back to 3600s once verified.
- CAA record blocking your TLS cert. If you are setting up MTA-STS hosting and Let's Encrypt fails, check your CAA — a stale CAA record from a previous CA blocks issuance.
A practical debugging workflow when something is wrong: start at the authoritative nameserver with dig, confirm the record exists exactly as published, then walk outward. Query 1.1.1.1 and 8.8.8.8 to check public resolver propagation. Send a test message to a Gmail account, view the original, and read the Authentication-Results header line by line — Gmail tells you the precise reason every check passed or failed, including the exact selector it queried for DKIM and the policy it found for DMARC. Most "DNS broken" tickets are actually alignment bugs at the application layer (a sequencer sending with one envelope-from but a different header From:) or transient propagation, not the DNS configuration itself. Always give a freshly published record at least one full TTL before declaring it broken.
Watch out for one more silent failure mode: copy-paste corruption. Long DKIM TXT values are notorious for picking up zero-width spaces, smart quotes, or line breaks when pasted from a rich-text source. The record looks identical visually but the public key fails to parse and DKIM silently fails. If everything seems right but DKIM still will not pass, regenerate the key in the provider console, paste it directly into a plain-text editor first, and only then into the DNS record field.
10. FAQs
How long does DNS propagation take for cold email records?
Most authoritative DNS changes are visible within 5–30 minutes, but worst-case TTL plus resolver caching can push it to 24–48 hours. For cold email DNS setup, lower the TTL to 300 seconds before making the change so propagation is fast, then raise it back to 3600 once verified.
Can I have multiple SPF records on the same domain?
No. RFC 7208 explicitly forbids multiple v=spf1 TXT records on the same domain — receivers will return PermError and your SPF will fail. If you need to authorize Google plus a sequencer plus a transactional sender, merge them into one record: v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.mailprovider.com ~all.
How many DMARC aggregate reports will I receive?
Expect 5–50 reports per day for an active sending domain — one per receiver (Gmail, Yahoo, Microsoft, Mail.ru, etc.) per 24 hours. Send them to a dedicated mailbox like dmarc@yourdomain.com or a parser such as Postmark, Dmarcian, or Valimail to make them readable.
Should I use a 1024-bit or 2048-bit DKIM key?
Use 2048-bit. 1024 is now considered weak, Google flags it in the Postmaster Tools authentication report, and the size difference (a single TXT record split across 255-char chunks) is irrelevant on modern DNS. Rotate keys every 6–12 months and keep two selectors live during rotation so signing never gaps.
Where should I host DNS for cold email — Cloudflare, registrar, or mailbox provider?
Cloudflare is the best default: free, low TTL granularity, full TXT length support, fast UI, and DNSSEC available. Registrar-hosted DNS (GoDaddy, Namecheap) works but is slower to update and sometimes truncates long DKIM values. Avoid letting your mailbox provider also host DNS — coupling the two makes migration painful later.
What is the SPF 10-DNS-lookup limit and how do I avoid it?
Every include:, a, mx, ptr, exists and redirect mechanism in your SPF counts toward a hard limit of 10 DNS lookups per evaluation. Exceed it and SPF returns PermError, which most receivers treat as a fail. Audit with our SPF checker, drop unused includes, and use SPF flattening only as a last resort because flattened records become stale when providers rotate IPs.
Do I need separate MX records for each cold email mailbox?
No. MX records are per-domain, not per-mailbox. One set of MX records covers every mailbox at that domain. If you run cold email across 30 sending domains, you configure 30 sets of MX records — one per domain — but each domain only needs one set regardless of mailbox count.
Do I need an A record for my cold email sending domain?
Strictly, no — MX, SPF, DKIM and DMARC do not require an A record. But Gmail and Microsoft penalize domains that fail to resolve in a browser, so always point the apex to a real landing page (a one-pager about your company is enough). Naked domains that 404 look thrown-together to spam filters.
Do PTR records matter for cold email?
Yes for self-hosted SMTP, no for Google Workspace or Microsoft 365. When you use a managed provider, the PTR record is set on the provider's sending IP and you have no control over it (and don't need any). PTR only matters when you operate your own MTA and the receiver checks reverse DNS against the HELO hostname.
What is the difference between SPF soft fail (~all) and hard fail (-all)?
~all tells receivers 'unauthorized senders should be marked suspicious but not rejected outright' — a safe default during setup. -all tells receivers 'reject anything not in this list.' Use ~all while you are still discovering legitimate senders, then move to -all after 30 days of clean reports. DMARC enforcement makes the SPF qualifier almost moot, but -all is the gold-standard end state.