The Three Records That Protect Your Deliverability
SPF, DKIM, and DMARC are the three DNS records that tell receiving mail servers whether to trust your email. Every major provider (Gmail, Outlook, Yahoo, Apple) now requires all three to avoid spam folder placement — some require them to deliver at all.
This reference gives you copy-paste record templates for the most common scenarios, the exact values to publish, and what to do when authentication fails.
Keep this open in a tab while configuring new sending domains. The record formats are unforgiving — one missing character, one extra space, and authentication silently breaks.
SPF — Sender Policy Framework
What it does. SPF tells receivers which IP addresses are allowed to send email from your domain. Receivers check the sending IP against your SPF record — if it doesn't match, the email is flagged.
Record type. TXT record on the root domain (not a subdomain).
Record name. Your domain itself (e.g., yourdomain.com) — in most DNS UIs you enter @ or leave the name field blank.
Record value — basic.v=spf1 include:_spf.google.com ~all (Google Workspace)v=spf1 include:spf.protection.outlook.com ~all (Microsoft 365)v=spf1 include:_spf.coldrelay.com ~all (ColdRelay)
Record value — multiple senders.v=spf1 include:_spf.google.com include:_spf.coldrelay.com ~all
Critical rules.
- Exactly ONE SPF record per domain. Multiple SPF records = automatic failure.
- Under 10 DNS lookups total across all includes. Each include: counts as a lookup.
- End with ~all (softfail) or -all (hardfail). Use ~all for cold email — -all is strict and can cause problems during migrations.
- Publish on the root domain. Subdomains inherit partial SPF but it's cleaner to publish per-subdomain if you send from subdomains.
Verify with: dig TXT yourdomain.com or MXToolbox SPF lookup.
DKIM — DomainKeys Identified Mail
What it does. DKIM signs every outgoing email with a cryptographic signature. Receivers verify the signature against a public key published in your DNS. Signed emails prove the sender is authorized and the content wasn't modified in transit.
Record type. TXT record on a selector-specific subdomain.
Record name. selector._domainkey.yourdomain.com where selector is the key name. Each provider uses different selectors:
- Google Workspace: google._domainkey.yourdomain.com
- Microsoft 365: selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com
- ColdRelay: provided per-domain during setup
Record value format.v=DKIM1; k=rsa; p=[long public key string]
Example (shortened):v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5HjZl7Kvpz...
Critical rules.
- Use 2048-bit keys. 1024-bit keys are deprecated and increasingly rejected.
- Publish the FULL public key — DKIM keys are long (200+ characters). Some DNS providers split long TXT records into multiple quoted strings; copy the split format exactly.
- One selector per provider. If you switch sending providers, either add a new selector or replace the old key.
Verify with: dig TXT selector._domainkey.yourdomain.com or check email headers for DKIM-Signature and dkim=pass in Authentication-Results.
DMARC — Domain-based Message Authentication
What it does. DMARC is the enforcement layer on top of SPF and DKIM. It tells receivers what to do when authentication fails (nothing, quarantine, or reject) and provides reporting on who's sending from your domain.
Record type. TXT record on a DMARC subdomain.
Record name. _dmarc.yourdomain.com
Record value — monitoring only (safe start).v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; fo=1
Record value — production (after monitoring).v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s
Record value — strict (high-security).v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s
Critical tags.
- p= policy. none = monitor only. quarantine = spam folder. reject = bounce.
- pct= percentage of mail to apply the policy to. Start at pct=10 and ramp to 100 over 2 weeks.
- rua= aggregate reports destination (statistics).
- ruf= forensic reports destination (individual failure reports — optional, high volume).
- adkim= DKIM alignment. s = strict. r = relaxed (default).
- aspf= SPF alignment. Same values.
Ramp progression (2–4 weeks).
1. Week 1: p=none — monitor reports.
2. Week 2: p=quarantine; pct=10 — start enforcement on 10% of mail.
3. Week 3: p=quarantine; pct=50 — increase enforcement.
4. Week 4: p=quarantine; pct=100 or p=reject; pct=100 — full enforcement.
Verify with: dig TXT _dmarc.yourdomain.com, check email headers for dmarc=pass, or use Postmark DMARC (free) to aggregate reports.
Reverse DNS (PTR) and BIMI
PTR (reverse DNS). Maps your sending IP back to a hostname. Many providers (especially Microsoft) downgrade deliverability or reject mail from IPs without matching PTR records.
How to configure. Request PTR records from your hosting provider or sending infrastructure. The PTR should point to a hostname on your sending domain (e.g., mail.yourdomain.com).
Verify with: dig -x 203.0.113.1 should return your sending hostname.
BIMI (Brand Indicators for Message Identification). Displays your logo next to authenticated messages in Gmail and Yahoo. Requires DMARC at p=quarantine or p=reject, a VMC (Verified Mark Certificate), and a BIMI-compliant SVG logo.
BIMI record format.v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem
BIMI considerations. VMC certificates cost $1,000–$2,000/year from DigiCert or Entrust. BIMI is valuable for consumer brands but rarely worth it for cold email — only consider if you've got a strong brand identity to project.
Common Authentication Failures and Fixes
SPF `softfail` or `fail` in headers. SPF record missing or includes wrong sender. Fix: add the correct include: for your sending platform. Verify with dig.
DKIM `none` in headers. DKIM not signing at all. Cause: wrong selector name, key not published, or provider not enabled. Fix: check provider settings, republish selector TXT record.
DKIM `fail` in headers. Signature doesn't match key. Cause: record truncated during DNS publish, key was regenerated but DNS not updated. Fix: copy the full key from the provider, re-publish.
DMARC `fail` with SPF and DKIM passing. Alignment issue. The envelope-from domain or DKIM signing domain doesn't match the visible from domain. Fix: ensure your sending setup uses the same domain across all three layers.
"Too many DNS lookups" SPF error. You have more than 10 include: references (including nested). Fix: flatten your SPF record or remove unused includes.
PTR mismatch. Receiving server rejects with reverse-DNS error. Fix: request PTR from your infrastructure provider to match your sending hostname.
All three records correct but still spam foldering. Authentication is only part of deliverability. Check content, reputation, and volume patterns — see the deliverability audit template.
Frequently Asked Questions
Do I really need all three?
Yes. Gmail and Yahoo now require all three for senders over 5,000 messages/day. Microsoft and most corporate mail servers treat missing DMARC as a strong spam signal. Without all three, you're delivering to spam folders by default.
How long do DNS changes take to propagate?
TTL-dependent. Most DNS providers use 1-hour TTL by default — global propagation takes 1–4 hours. If you configured a low TTL before changing, it's faster. Verify with `dig` from a neutral resolver (1.1.1.1 or 8.8.8.8) before testing sends.
Can I publish multiple SPF records?
No. Publishing two SPF records breaks SPF entirely — receivers will fail both. If you need to authorize multiple senders, combine them into one SPF record with multiple `include:` clauses.
Does ColdRelay configure these automatically?
Yes. ColdRelay provisions SPF, DKIM, and DMARC records automatically when you add a domain. You just add the provided records to your DNS — no manual key generation, selector naming, or policy ramping required.