SPF, DKIM, and DMARC for Cold Email: The Minimum You Must Configure in 2026
Three DNS records stand between you and the inbox. Get them right and most of your deliverability problems vanish. Get them wrong and no amount of warmup will save you.
Authentication is non-negotiable in 2026. Gmail and Yahoo enforce SPF and DKIM for bulk senders, Microsoft applies similar pressure, and even small senders without a DMARC policy are deprioritised. The good news: configuring all three takes about 20 minutes if you have access to your DNS.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a TXT record that lists the IP ranges and domains authorised to send mail on your behalf. The record lives at the apex of your domain (no host prefix). For a domain that sends through Google Workspace and a single transactional provider, it might look like:
v=spf1 include:_spf.google.com include:transactional-provider.com ~all
Key rules: only one SPF record per domain (multiple records is an automatic failure), at most 10 DNS lookups in the resolution chain (each include counts as one lookup), and end with ~all (soft fail) for production, then move to -all (hard fail) once you are confident.
DKIM: cryptographic signing
DKIM (DomainKeys Identified Mail) signs each outbound message with a private key. Receivers verify the signature using a public key published in your DNS at a selector-specific subdomain, typically default._domainkey.yourdomain.com or google._domainkey.yourdomain.com depending on your provider.
Generate a 2048-bit key (1024-bit is considered weak in 2026). Most providers do this for you when you enable DKIM signing in their admin console. Copy the public key TXT record they give you into your DNS and wait for propagation, usually under an hour.
DMARC: what to do when SPF or DKIM fail
DMARC tells receivers what to do when SPF or DKIM fail, and where to send aggregate reports. Start at p=none (monitor only) so you do not accidentally block legitimate mail while you debug. After 30 days of clean reports, move to p=quarantine, then eventually p=reject.
Example record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Make sure [email protected] actually exists and somebody reads it, because the aggregate XML reports are how you discover whether anything is spoofing your domain.
MTA-STS and TLS-RPT: the 2026 upgrades
MTA-STS forces TLS encryption on inbound mail to your domain. It is increasingly expected by Gmail and Microsoft as a maturity signal. Publish a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and a TXT record at _mta-sts.yourdomain.com.
TLS-RPT publishes a reporting address for TLS failures. Add a TXT record at _smtp._tls.yourdomain.com pointing to a mailbox you check monthly.
Verifying the setup
Send a test message to a Gmail address you control. Open the message, click the three-dot menu, select 'Show original'. You want to see SPF: PASS, DKIM: PASS, DMARC: PASS. If any of them fail, fix that one before moving on. Free tools like mxtoolbox.com and mail-tester.com will also flag issues.
Having multiple SPF records on the same domain. This is an automatic SPF failure, regardless of how permissive each record is. If you ever consolidate vendors, consolidate the SPF record too.