LongRun
All posts
Deliverability

SPF, DKIM, and DMARC for Cold Email: The Authentication Setup That Keeps Bounce Under 1%

May 27, 20265 min read

You set up cold email, sent a few hundred messages, and now half of them are bouncing or sitting in spam. Your reply rate looks broken, but the copy is fine. The problem is almost always lower in the stack: your domains are not authenticated correctly, so receiving servers either reject your mail or quietly file it under junk. This is not a copy problem. It is a DNS problem.

This is the authentication setup we run across every sending domain in a pilot. It is the reason our average inbox placement sits at 98.5% against a roughly 60% industry baseline on shared infrastructure, and the reason bounce stays in the 0.15 to 0.9% range. No theory, no glossary. Here is what to put in DNS and why.

Why authentication is the floor under your bounce rate

SPF, DKIM, and DMARC are three DNS records that together tell a receiving mail server one thing: this message is really from the domain it claims to be from. When they are missing or misconfigured, Google and Microsoft do not give you the benefit of the doubt. They reject outright (a hard bounce) or route to spam. A bounce above 2 to 3% on a fresh domain is almost never a bad list problem first. It is an authentication or reputation problem.

The records are not optional for cold email. Since February 2024, Google and Yahoo require SPF, DKIM, and a published DMARC policy for any sender pushing meaningful volume. If you skip DMARC, you are not just losing placement, you are failing a stated requirement at the two largest mailbox providers. Get the three records right and you remove the entire category of failure that authentication causes, which is what pulls bounce down toward the low end of that 0.15 to 0.9% band.

SPF: authorize every server that sends as you, and stay under 10 lookups

SPF (Sender Policy Framework) is a TXT record listing which servers are allowed to send mail for your domain. A receiving server checks the sending IP against that list. If the IP is not authorized, the message fails SPF.

A clean record looks like v=spf1 include:_spf.google.com ~all for Google Workspace, with the relevant include swapped for Microsoft or Azure. The two mistakes that quietly break things: more than one SPF record on the same domain (only one is allowed, a second invalidates both), and exceeding the hard limit of 10 DNS lookups. Every include counts. Chain four or five tools together and you blow the limit, which causes a permerror that some receivers treat as a soft fail. Use ~all (soft fail) rather than -all (hard fail) while you are warming, then tighten later. We run 52 mailboxes across Google, Microsoft, and Azure, and each provider gets its own correctly scoped SPF on its own sending domain rather than one overloaded record trying to cover everything.

DKIM: sign every message so it cannot be forged or altered

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message using a private key held by your sending platform. The matching public key lives in a DNS TXT record at a selector subdomain, for example google._domainkey.yourdomain.com. The receiver fetches that key, verifies the signature, and confirms two things: the message really came from your domain and nothing was tampered with in transit.

Use a 2048-bit key where your provider supports it. 1024-bit still passes but is weaker and some receivers now flag it. The most common failure we see on handover audits of a previous setup: DKIM was enabled in the sending tool but the public key was never published in DNS, or it was published on the root domain instead of the selector. Both mean the signature cannot be verified, so the message is treated as unsigned. Each sending domain needs its own selector record, published and verified, before a single cold email goes out. This is the kind of thing we check on every domain in our deliverability setup rather than trusting the platform UI's green checkmark.

DMARC: the policy that ties it together (and the one most people skip)

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the instruction layer. It tells receivers what to do when SPF or DKIM fails, and it requires alignment: the domain in your visible From address has to match the domain that passed SPF or DKIM. You can pass both SPF and DKIM and still fail DMARC if nothing aligns to your From domain. That alignment check is what stops spoofing, and it is what the 2024 requirements are really enforcing.

Publish a record at _dmarc.yourdomain.com. Start with v=DMARC1; p=none; rua=mailto:[email protected]. The p=none policy enforces nothing yet but turns on aggregate reports, so you can see which sources are passing and failing before you tighten. Once the reports are clean, move to p=quarantine and eventually p=reject. Skipping straight to reject before your sources are aligned is how people accidentally null-route their own legitimate mail. Set this up once, per domain, and it becomes part of an owned system you keep. When a pilot ends, the domains, the DNS, and these records all stay with you. We never run cold email on your primary domain, which keeps your main domain's reputation insulated from outreach entirely. You can see how this fits the full build in the 3-month pilot.

Verify before you send, then watch the numbers

Authentication is not a set-and-forget toggle. Before any domain goes live, confirm all three records resolve and pass: send a test to a checker or to a Gmail address and inspect the headers for spf=pass, dkim=pass, and dmarc=pass with alignment. If any one says fail or none, fix it before sending volume. A single misconfigured selector across a batch of mailboxes will drag your whole domain's reputation down within days.

After that, the signal that matters is the trend. We hold bounce in the 0.15 to 0.9% range by validating every record at setup and monitoring placement continuously, not by reacting after a campaign tanks. Before you send a word of copy, run it through a free spam words checker so trigger phrases are not undoing clean authentication. Authentication gets you in the door. Clean copy and clean lists keep you there.

FAQ

Questions, answered.

Do I need separate sending domains for cold email, or can I use my main domain?
Use separate sending domains. Cold outreach carries reputation risk, and you do not want that touching the domain your customers and invoices run on. We register dedicated sending domains, authenticate each one with its own SPF, DKIM, and DMARC, and warm the mailboxes before sending. Your primary domain stays insulated. If outreach reputation ever takes a hit, your real business email is unaffected.
My SPF and DKIM both pass but DMARC still fails. Why?
That is almost always an alignment problem. DMARC does not just check that SPF or DKIM passed, it checks that the passing domain matches the domain in your visible From address. If your sending platform signs with a different domain than the one in From, both checks can pass while DMARC fails. Fix it by configuring DKIM to sign with your sending domain and making sure the return-path and From domains align. Start with p=none and read the aggregate reports to see exactly which source is misaligned.
How long after fixing authentication will bounce actually drop?
DNS changes propagate within minutes to a few hours, so authentication failures stop almost immediately once the records resolve correctly. Bounce caused by misconfiguration drops right away. Bounce caused by bad or decayed list data is a separate issue that authentication will not fix, you need verification and waterfall enrichment for that. If your bounce is still high after the records pass, the problem has moved from your DNS to your data.

Want this built and run for you?

LongRun builds the outbound system, runs it, and hands it over at day 90. Book a strategy call to scope yours.