What DNS records does cold email require?
Cold email infrastructure rests on seven DNS record types. Four are mandatory at every modern receiver, two are increasingly expected, and one is optional but signals brand maturity. Skipping any of the mandatory four guarantees inbox placement problems regardless of warmup, copy quality, or sending volume.
| Record | Purpose | Example value | Status |
|---|---|---|---|
MX Mail Exchange | Routes inbound email to your mailbox provider's servers. | 1 ASPMX.L.GOOGLE.COM | Required |
SPF Sender Policy Framework | Lists which servers are authorised to send mail as your domain. | v=spf1 include:_spf.google.com ~all | Required |
DKIM DomainKeys Identified Mail | Cryptographically signs each message so receivers can verify it was not modified. | v=DKIM1; k=rsa; p=MIGfMA0GCSqG... | Required |
DMARC Domain-based Message Authentication | Tells receivers how to handle mail that fails SPF or DKIM, plus where to send reports. | v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com | Required |
MTA-STS Mail Transfer Agent Strict Transport Security | Forces TLS on inbound SMTP and prevents downgrade attacks. | v=STSv1; id=20260504T000000Z | Recommended |
TLS-RPT SMTP TLS Reporting | Receives daily reports about TLS negotiation failures from major receivers. | v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com | Recommended |
BIMI Brand Indicators for Message Identification | Displays your verified logo next to inbox messages on Gmail, Yahoo, and Apple Mail. | v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem | Optional |
What each record actually does
The acronyms hide simple ideas. Here is each record explained without jargon, with the example value you would actually paste into a registrar.
MX — where inbound mail goes
The MX record tells the world which servers accept mail for your domain. It has two parts: a priority number (lower wins) and a hostname. Cold email sending domains still need MX records — receivers do reverse lookups, and missing MX is a strong spam signal even on outbound.
yourdomain.com. MX 1 ASPMX.L.GOOGLE.COM yourdomain.com. MX 5 ALT1.ASPMX.L.GOOGLE.COM yourdomain.com. MX 5 ALT2.ASPMX.L.GOOGLE.COM yourdomain.com. MX 10 ALT3.ASPMX.L.GOOGLE.COM yourdomain.com. MX 10 ALT4.ASPMX.L.GOOGLE.COM
SPF — who is allowed to send
SPF is a TXT record listing IP ranges and hostnames authorised to send as your domain. The receiver checks the connecting server's IP against this list. SPF has a hard limit of 10 DNS lookups — every include: counts, including nested ones. Exceed 10 and SPF returns permerror, which fails authentication entirely.
yourdomain.com. TXT "v=spf1 include:_spf.google.com ~all"
DKIM — cryptographic signing
DKIM publishes a public key under selector._domainkey.yourdomain.com. The mail server signs each outbound message with the matching private key. Receivers fetch the public key and verify the signature. The selector lets you rotate keys without breaking historical mail. 2048-bit RSA is the modern default. See the DKIM Wikipedia article for the full specification.
google._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
DMARC — policy and reporting
DMARC unifies SPF and DKIM under a policy: what should receivers do if a message fails both? Options are p=none (monitor only), p=quarantine (route to spam), and p=reject (drop). The rua tag is the address that receives daily aggregate reports — invaluable for spotting unauthenticated senders. See DMARC.org and RFC 7208 (SPF).
_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r"
How long manual setup takes vs automated
Concrete time math, measured against a fresh domain on Cloudflare with Google Workspace as the mailbox provider.
Manual: 45 to 90 minutes
- Provision Google Workspace tenant and verify TXT — 10 min
- Generate DKIM key in admin console, copy and paste — 8 min
- Compose SPF, check 10-lookup budget — 5 min
- Author DMARC, decide on policy and reporting address — 8 min
- Set up MTA-STS HTTPS endpoint and policy file — 15 min
- Configure TLS-RPT mailbox and TXT record — 5 min
- Verify each record across multiple resolvers — 10 min
- Debug typos, missing semicolons, wrong selectors — 10 to 30 min
Automated with StackMail: 30 seconds
- Connect domain via registrar API (one-time per registrar) — 10 sec
- StackMail provisions Google Workspace tenant — 8 sec
- All seven records written in parallel via API — 4 sec
- Multi-resolver propagation poll begins — 8 sec to first green
- Domain marked ready, mailbox creation unlocked — instant
For a 30-domain agency setup, that is 22 hours of manual work compressed into 15 minutes.
Common DNS mistakes that kill deliverability
Every one of these has been the root cause of a "my emails are going to spam" support ticket. Most are silent failures — your mail looks fine to you, but receivers reject it.
SPF exceeds 10 DNS lookups
The single most common cold-email DNS bug. Each include: counts as one lookup, and every include can recursively add more. include:_spf.google.com alone consumes four lookups internally. Add SendGrid, Mailgun, and a CRM and you are at 14. Result: SPF returns permerror and authentication silently fails. Use our SPF lookup checker to see your current count, then flatten with a single ip4: block if needed.
DKIM record missing or never rotated
Either DKIM was never published (Google Workspace requires you to manually generate the key in the admin console — it is not on by default) or the key has been the same for three years. Modern receivers expect rotation every 6 to 12 months. Verify with our DKIM checker to confirm a valid public key is published under the correct selector.
DMARC stuck at p=none forever
p=none was meant to be a temporary monitoring phase, not a permanent policy. Gmail and Yahoo's 2024 sender requirements treat p=none as the bare minimum for high-volume senders, and bottom-tier reputation. Move to p=quarantine within 30 days. Verify policy with our DMARC checker.
Wrong MX priority or stale legacy records
When migrating from a legacy provider, old MX records left in place cause split-routing. Mail bounces intermittently. The fix is to delete every MX record before adding the new ones. With Google Workspace, the canonical setup is one priority-1 record (ASPMX.L.GOOGLE.COM) and four backups at priority 5 and 10.
SPF record with hard fail (-all) on a domain that uses third-party tools
-all tells receivers to reject any non-listed sender. If you forget to add a single tool to SPF, every email it sends goes to spam — including transactional resets and Stripe receipts. Use ~all (softfail) until you are 100% confident your SPF is comprehensive.
MTA-STS and TLS-RPT — when to add them
MTA-STS forces inbound SMTP to use TLS and prevents protocol-downgrade attacks. TLS-RPT publishes an address where receivers can send daily reports about TLS negotiation failures. Together they signal that your domain is operationally serious about transport security.
They are not strictly required for cold email deliverability today, but Google, Microsoft, and Yahoo all read MTA-STS policies and the trend is toward expectation rather than option. Adding them costs nothing in send-side performance and provides positive reputation signal.
The friction is the HTTPS endpoint. MTA-STS requires a policy file served from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid TLS certificate. Doing that manually means provisioning a subdomain, configuring HTTPS, and hosting a file. StackMail handles the entire HTTPS layer automatically.
Add MTA-STS when you have at least 3 production domains and DMARC at p=quarantine or higher. Skip on disposable test domains.
BIMI — should you bother for cold email?
BIMI shows your verified logo next to inbox messages on Gmail, Apple Mail, and Yahoo. It looks impressive in screenshots. For cold email specifically, it is almost always not worth the effort.
The hard requirements: a Verified Mark Certificate (VMC) from Entrust or DigiCert at roughly 1,200 to 1,500 USD per year, a registered trademark for the logo (think 1 to 2 years and several thousand dollars to obtain), DMARC at p=quarantine or p=reject, and an SVG logo file hosted on the domain.
For a primary brand that sends transactional and marketing mail at scale, BIMI is a strong investment. For cold-outreach domains — which are typically lookalikes used for 6 to 12 months and rotated — the math does not work. The trademark requirement alone disqualifies most cold sending strategies, where domains like getyourcompany.com would not have their own trademark.
Verdict: deploy BIMI on your apex brand domain only. Do not deploy on cold email domains.
DNS propagation — what 24 to 48 hours actually means
The "DNS takes 24 to 48 hours to propagate" advice is mostly outdated folklore inherited from the 1990s when zone transfers between authoritative servers were slow and ISP resolvers cached aggressively. Today, with TTL set to 300 seconds and modern anycast resolvers, the reality looks different.
What actually happens when you change a record: your registrar's authoritative nameservers update within seconds. Cloudflare's anycast network propagates globally in 5 to 30 seconds. Google Public DNS (8.8.8.8) and Quad9 typically reflect changes within 60 seconds. The major mailbox providers (Gmail, Outlook, Yahoo) query through these resolvers — they see your new records within a couple of minutes.
What still takes 24 to 48 hours: legacy ISP resolvers (some Tier-2 telecoms in Asia, smaller European ISPs) that ignore TTL and cache for a fixed window. None of these are in the path between you and a Gmail or Outlook receiver, so they do not affect cold email deliverability.
How to verify: query at least four resolvers from different providers and confirm they all return the same record. StackMail polls Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, OpenDNS 208.67.222.222, plus four regional resolvers in Europe, Asia-Pacific, and Latin America. The domain is marked ready when all eight agree. You can replicate this manually with dig @1.1.1.1 yourdomain.com TXT and rotating the resolver IP.
Domain selection guide — which TLDs work for cold email
TLD choice has a measurable effect on inbox placement. Spam filters use TLD reputation as a signal, and some corporate gateways block entire TLDs by default. Domain age is a separate but smaller factor — a 2-year-old domain warms faster than a 7-day-old one.
| TLD | Recommendation | Reasoning |
|---|---|---|
| .com | Prefer | Highest trust signal at receivers. Default expectation for B2B. |
| .io | Prefer | Strong B2B and SaaS association. No deliverability penalty. |
| .co | Prefer | Widely accepted as a .com alternative. Good for lookalike domains. |
| .net | Acceptable | Older TLD, neutral reputation. Not as trusted as .com. |
| .ai | Acceptable | Premium pricing but increasingly accepted by B2B receivers. |
| .app | Acceptable | HTTPS-only requirement adds operational friction; deliverability is fine. |
| .info | Avoid | Disproportionately associated with spam. Many filters down-weight by default. |
| .xyz | Avoid | 1 USD promo pricing attracted bulk spam registrations. Most filters penalize. |
| .top, .click, .work | Avoid | Cheap TLDs with poor reputation. Many corporate filters block outright. |
| ccTLDs (.de, .fr, .uk) | Conditional | Excellent within-country deliverability, weaker cross-border. Use for regional outreach. |
Domain age impact: a domain with 60+ days of clean history will warm noticeably faster than a brand-new one. Receivers run silent reputation models that weight age. If buying lookalike domains for outreach, look for drop-catches with prior legitimate history rather than freshly registered.
Subdomain strategy — separate sending domain or subdomain?
The strongest pattern for cold email is a separate registered domain — a lookalike of your brand. If your company is acme.com, you might send cold from getacme.com, tryacme.com, or acme.co. This isolates outreach reputation completely from your corporate domain.
The reasoning: cold email reputation is volatile. A bad list, an aggressive sequence, or a spike in spam complaints can tank a domain's reputation in days. If that is your apex brand domain, you also lose internal mail, sales emails, support replies, and SaaS notifications. Recovery takes months. With a separate sending domain, you simply rotate to the next one and keep going.
If you must use the same brand domain, send from a subdomain like mail.yourbrand.com or go.yourbrand.com. DMARC alignment can be relaxed (adkim=r, aspf=r), so the subdomain still aligns with the apex DMARC policy. But understand that subdomain reputation does bleed back to the apex over time. A subdomain disaster does affect the brand domain.
Operational rule: never burn the apex on cold outreach. Use a separate domain or, at minimum, a dedicated subdomain. StackMail provisions multiple sending domains in parallel and rotates them automatically when complaint rates spike.
Multi-registrar workflow
StackMail connects to every major registrar via API or nameserver delegation. Authentication and time-to-first-record vary.
| Registrar | Authentication | Time | Notes |
|---|---|---|---|
| Cloudflare | Global API Token (scoped to Zone:Edit) | 30 seconds | Fastest. Zero TTL changes propagate within seconds. |
| GoDaddy | API key + secret (Production tier) | 60 seconds | Requires 50+ domain account or paid API tier. |
| Namecheap | API key + whitelisted IP | 90 seconds | API access requires 20+ domains or 50 USD account balance. |
| Google Domains / Squarespace | Nameserver delegation to StackMail | 5 minutes | API was deprecated; we delegate via NS records instead. |
| Porkbun | API key + secret | 45 seconds | Clean API, no minimum account requirements. |
| Name.com | API token | 60 seconds | Stable API, supports bulk operations. |
| Hover, Dynadot, others | Nameserver delegation | 5 minutes | No public API — delegate NS to StackMail's anycast nameservers. |
Setup checklist
Six steps from blank domain to inbox-ready. Follow in order.
- 1
Connect or buy your domain
Register a new domain through StackMail or connect an existing one from Cloudflare, GoDaddy, Namecheap, or Google Domains using API key, OAuth, or nameserver delegation.
- 2
Choose mailbox provider
Select Google Workspace or Microsoft 365 as the mailbox backend. StackMail provisions the underlying tenant and DKIM keys before writing DNS.
- 3
Apply MX, SPF, DKIM, DMARC
StackMail writes all four core records simultaneously. SPF is flattened to stay under the 10 DNS lookup limit. DKIM keys are 2048-bit by default.
- 4
Apply MTA-STS and TLS-RPT
An HTTPS-hosted MTA-STS policy is published at mta-sts.yourdomain.com along with the matching TXT records. TLS-RPT routes reports to a monitored mailbox.
- 5
Verify propagation
StackMail polls eight global resolvers every 30 seconds. The dashboard shows green when every record is visible from Cloudflare, Google, Quad9, OpenDNS, and four regional resolvers.
- 6
Warm up before sending
Wait at least 14 days of warmup before sending production volume. StackMail enrols the mailbox in its warmup pool automatically once DNS is verified.
TL;DR checklist
- Cold email requires four mandatory records (MX, SPF, DKIM, DMARC) and benefits from three more (MTA-STS, TLS-RPT, optionally BIMI).
- Manual setup takes 45 to 90 minutes per domain. StackMail does all seven records in roughly 30 seconds via registrar API.
- The most common deliverability-killing mistakes are SPF lookups exceeding 10, missing DKIM rotation, and DMARC stuck at p=none.
- Propagation to major resolvers usually completes in 5 to 15 minutes, not the 24 to 48 hours commonly quoted.
Frequently asked questions
Common questions about DNS for cold email — propagation timing, key length, policy choices, and registrar specifics.
How long does DNS propagation actually take for cold email?+
Most major resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9) refresh within 5 to 15 minutes when TTL is set to 300 seconds. The often-quoted 24 to 48 hour window applies to legacy ISP resolvers and registrars that cache aggressively. For cold email, what matters is whether Gmail, Outlook, Yahoo, and the major B2B receivers can resolve your records — that is almost always under one hour. StackMail polls eight resolvers every 30 seconds and marks the domain ready only when all eight return matching values.
Should I use a 1024-bit or 2048-bit DKIM key?+
Use 2048-bit. 1024-bit keys are still accepted by every major receiver but are considered weak by modern cryptographic standards and have been factored in academic settings. Google Workspace generates 2048-bit by default. Some legacy DNS hosts split the public key into two TXT chunks because of the 255-character record limit — StackMail handles this automatically. There is no deliverability advantage to 1024-bit, only a marginal compatibility benefit with very old MTAs that virtually nobody runs in 2026.
Can I have multiple SPF records on one domain?+
No. RFC 7208 forbids it and receivers will return a permerror, which means SPF effectively fails for every message. You must merge all sources into a single record using include: mechanisms. A common mistake: adding Google Workspace SPF, then later adding a marketing tool's SPF as a second record. The fix is one record like v=spf1 include:_spf.google.com include:sendgrid.net ~all. Watch the 10-lookup limit — every include counts.
Should DMARC be set to quarantine or reject?+
Start at p=none for two weeks while you collect aggregate reports and confirm every legitimate sender is aligned. Move to p=quarantine for at least four weeks. Only progress to p=reject once you have zero unauthenticated legitimate mail in your reports. For cold email specifically, p=quarantine is usually sufficient — the goal is signaling commitment to authentication, not absolute enforcement. Many domains rank perfectly well at p=quarantine indefinitely.
Is BIMI worth the VMC cost for cold email?+
Probably not, unless you already operate a recognised consumer brand. A Verified Mark Certificate from Entrust or DigiCert costs roughly 1,200 to 1,500 USD per year and requires a registered trademark. For a cold-outreach domain that may be rotated every six to twelve months, the math does not work. BIMI also requires p=quarantine or p=reject DMARC, which is a higher bar than most cold senders are at. Skip BIMI on outreach domains and reserve it for your primary brand domain.
Do I really need MTA-STS for cold email?+
Not strictly required, but increasingly expected. Microsoft, Google, and Yahoo all publish MTA-STS policies and use them when available. Adding it has zero downside, signals operational maturity, and provides downgrade-attack protection. The barrier is publishing the policy file over HTTPS at the mta-sts subdomain — annoying to do manually, trivial when automated. StackMail provisions the HTTPS endpoint and the TXT records together.
Should cold email use the root domain or a subdomain?+
Use a separate sending domain entirely, not a subdomain of your primary brand. Most cold senders register a lookalike domain (yourcompany.co, getyourcompany.com, tryyourcompany.io) to isolate sending reputation from the corporate domain. If you must use the same brand domain, send from a subdomain like mail.yourbrand.com — DMARC alignment still works because alignment can be relaxed, and a subdomain blowup will not poison the apex. Never burn the apex on cold outreach.
What is a registrar lock and does it matter for cold email?+
Registrar lock (clientTransferProhibited) prevents your domain from being transferred without explicit unlock. It is enabled by default at most registrars and you should leave it on. The only time it matters is when migrating registrars in bulk — StackMail's bulk-connect flow uses API authorization rather than transfer, so lock state is irrelevant. Watch out for the separate 60-day ICANN transfer lock that fires after registration or change of registrant.
Does DNS over HTTPS affect cold email deliverability?+
No. DoH is a client-resolver protocol; receiving mail servers still resolve your DNS normally over UDP/TCP port 53. Cold email infrastructure is entirely server-to-server and unaffected by what end users do on their browsers. The one tangential impact: some DoH providers (Cloudflare 1.1.1.1, Google 8.8.8.8) are excellent test resolvers because they are fast and globally consistent — useful for verifying propagation.
Should DKIM be a TXT record or a CNAME?+
Either works. Google Workspace and Microsoft 365 publish DKIM as TXT directly. Some providers (SendGrid, Mailgun, Amazon SES) prefer CNAME records that point to provider-managed TXT, which lets them rotate keys without touching your DNS. For cold email through StackMail on Google or Microsoft, you will see TXT. The CNAME pattern is more common for transactional senders. Both produce identical authentication results on the receiver side.