SPF, DKIM, DMARC: The Cold Email Setup Guide Most Teams Get Wrong
By Brendan Ward
The difference between 90% inbox placement and 30% spam folder usually isn't your copy. It's three DNS records. SPF, DKIM, and DMARC are the authentication trio that decides whether mailbox providers — Google, Microsoft, Yahoo — treat your sending domain as legitimate or suspect.
Most teams either skip one of the three, configure DMARC to p=none and forget it, or copy a generic SPF record from a 2019 blog post that no longer reflects what Google enforces. Below is the exact setup we run across every Growtoro client domain — and the verification steps before the first send.
Why These Records Exist
Mailbox providers face an arms race against spammers. The three protocols answer three different questions:
- SPF (Sender Policy Framework): Is this server allowed to send mail for this domain?
- DKIM (DomainKeys Identified Mail): Has the message been altered in transit, and was it cryptographically signed by the domain owner?
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): What should the receiving server do if SPF or DKIM fails — and where should it report?
Since February 2024, Google and Yahoo require all three for any sender pushing more than 5,000 messages per day. By 2026, the bar has dropped — even low-volume cold senders without DMARC are routinely rejected outright.
SPF: Get the Record Right or Don't Send
SPF is a single TXT record at the root of your sending domain. The structure:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Three rules that catch teams off-guard:
1. The 10-lookup limit. SPF allows a maximum of 10 DNS lookups per evaluation. Each include: burns one (sometimes more, if the included record nests further). Stack four or five sending platforms and you blow past the limit. The record technically exists but fails validation silently.
2. The ~all vs -all debate. Soft-fail (~all) tells receivers "treat unauthorized senders with suspicion." Hard-fail (-all) tells them "reject outright." For a primary corporate domain with marketing, transactional, and internal mail mixed in, ~all is safer. For a dedicated cold sending domain that has exactly one sending source, -all is correct and adds trust.
3. One record per domain. Multiple SPF records on the same domain silently invalidates the whole stack. Merge them into one.
DKIM: The Signature That Builds Reputation
DKIM is generated by your sending platform and added as a TXT or CNAME record. The platform signs every outgoing message; the receiver verifies the signature against your DNS-published public key.
The misconfiguration we see most often: a CNAME record pointing to a stale selector after a platform migration. Every send fails DKIM, the sender wonders why placement collapsed, and nobody checks DNS until reply rate is already in the gutter.
Best practice: rotate keys every 6–12 months, use a 2048-bit key (not the default 1024-bit on older platforms), and verify the selector with a tool like MXToolbox after every change.
DMARC: The Record That Actually Enforces
SPF and DKIM tell receivers what's allowed. DMARC tells them what to do when something isn't.
The phased rollout we use on every new client domain:
Week 1 — Monitor (p=none): Publish the record with p=none and rua=mailto:dmarc@yourdomain.com. This collects aggregate reports without affecting delivery. Read the first week of reports to confirm all legitimate sources are authenticated.
Week 3 — Quarantine (p=quarantine): Move to quarantine. Unauthorized mail starts going to spam. Watch the reports for false positives (forgotten internal sources usually surface here).
Week 6 — Reject (p=reject): Lock it down. Anything that fails authentication is rejected outright. This is the configuration that actually builds domain reputation, because mailbox providers see your domain as one that refuses to allow spoofing.
Most teams stop at p=none. That's not DMARC. That's a DMARC tag pretending to be DMARC.
The Verification Checklist Before First Send
Before sending a single cold email from a new domain, run:
- SPF record validates against MXToolbox SPF checker — no syntax errors, lookup count under 10.
- DKIM selector resolves and decodes to a valid public key.
- DMARC record is published and parses correctly.
- Send a test message to
check-auth@verifier.port25.com— it replies with a full authentication report. - Send a test message to a Gmail and an Outlook inbox you control. View raw headers. Confirm
SPF=PASS,DKIM=PASS,DMARC=PASS.
Any single failure on this checklist means stop, fix, and retest. Sending from a misconfigured domain doesn't just hurt one campaign — it poisons the domain's long-term reputation, which takes 60–90 days to recover.
Authentication Is the Foundation — Not the Strategy
Perfect DNS doesn't fix bad copy, bad targeting, or bad lists. But broken DNS guarantees that great copy never lands. Think of authentication as the table stakes that earn you the right to compete.
For the broader infrastructure picture — domains, IPs, mailbox setup, warm-up — see our guide on building cold email infrastructure from scratch. For the next step after DNS, choosing and deploying dedicated sending domains walks through the volume math. And for an end-to-end pre-flight, the 2026 deliverability checklist covers the operational items DNS alone can't fix.
If you'd rather skip the DNS configuration entirely and have us run the full infrastructure for you, build a campaign in 90 seconds and we'll handle SPF, DKIM, DMARC, dedicated domains, and warm-up as part of the setup.
Ready to launch your next campaign?
Build your outreach campaign in 90 seconds with our AI Campaign Builder.
Build a Campaign