Most cold email deliverability problems get diagnosed as a copywriting issue when they're actually a DNS issue. A team rewrites subject lines, shortens the message, cuts the call-to-action — and reply rates barely move, because the emails were never reaching the inbox in the first place. Gmail and Microsoft's 2024 bulk sender requirements made SPF, DKIM, and DMARC non-negotiable for anyone sending outbound at volume, and the mailbox providers have only gotten stricter since. A sequence with a 40% open rate and one with a 4% open rate can be word-for-word identical — the difference is almost always authentication, not messaging.
This is the guide we point our own onboarding customers to before they send a single prospecting email. It covers what each record actually does, how to configure it correctly for cold outreach specifically (not just transactional mail, which has different needs), and the mistakes that quietly cap deliverability even after the records are "set up."
Mailbox providers run authentication checks before they run any content or engagement analysis. If a message fails SPF and DKIM, Gmail and Outlook don't need to read the subject line to decide it's suspicious — an unauthenticated sending domain impersonating legitimate mail is exactly what these systems were built to catch. Pass authentication cleanly and the message moves on to the next layer of filtering, where engagement history, spam-trigger language, and sending patterns take over.
That ordering matters for how teams should prioritize their setup. A well-warmed domain with airtight authentication and a mediocre email still lands in the inbox more often than a brilliantly written email sent from a domain missing a DKIM record. Fix the infrastructure first. Optimize the copy second. Teams that skip straight to A/B testing subject lines while their DMARC record is missing are optimizing the wrong variable.
Sender Policy Framework is a DNS TXT record that lists which mail servers are authorized to send on behalf of a domain. When a receiving server gets a message, it checks the sending server's IP against the domain's SPF record — if the IP isn't listed, the message fails the check.
A typical SPF record for a domain sending through a dedicated cold email platform looks like this:
`
v=spf1 include:_spf.yoursendingtool.com ~all
`
Three details trip up most teams setting this up for outbound:
- Only one SPF record per domain is allowed. If a domain already has an SPF record for another tool — a CRM, a marketing platform, a transactional email service — the new sending source has to be added to the existing record with an include mechanism, not a second TXT record. Two SPF records is the single most common self-inflicted deliverability error we see when auditing new customer domains.
- Stay under 10 DNS lookups. SPF caps the number of nested include statements at 10 total lookups. Domains that have accumulated integrations over the years — five, six, seven include statements — can silently exceed this limit, which causes the entire SPF check to fail (a "permerror") regardless of whether the sending IP is actually authorized.
- ~all vs -all matters for cold outreach specifically. ~all (softfail) tells receiving servers to accept but flag mail from unlisted sources; -all (hardfail) tells them to reject it outright. For a domain running cold outreach, ~all is the safer default — it gives some tolerance for edge cases in sending infrastructure without materially weakening protection.
DomainKeys Identified Mail attaches a cryptographic signature to each outgoing message, generated with a private key held by the sending server. The receiving server looks up the corresponding public key — published as a DNS TXT record — and verifies the signature matches. If it does, the receiving server knows two things: the message genuinely came from an authorized sender, and nothing was altered between sending and delivery.
Setup requires generating a key pair (almost always handled by the sending platform, not manually) and publishing a TXT record at a selector-specific subdomain, typically formatted as:
`
selector._domainkey.yourdomain.com
`
The selector is an arbitrary string the sending platform assigns — it lets a domain run multiple DKIM keys simultaneously, which matters for a specific cold outreach scenario: rotating keys periodically without a gap in coverage. A domain sending high volumes of prospecting email should rotate its DKIM key roughly every 6-12 months. Because the selector allows multiple keys to coexist, the rotation can happen without a window where mail goes unsigned — publish the new key under a new selector, switch the sending platform over, then remove the old record once traffic has fully shifted.
The most common DKIM mistake in cold outreach setups isn't a missing record — it's a mismatched one. Copying a DKIM value with extra whitespace, a truncated key, or quotation marks left in from a copy-paste produces a record that looks present in a DNS lookup tool but fails validation on every send. Always verify with a dedicated DKIM checker after publishing, not just a generic DNS lookup.
Domain-based Message Authentication, Reporting and Conformance ties SPF and DKIM together and adds a policy layer: it tells receiving servers what to do with mail that fails both checks, and it gives the domain owner visibility into who's sending mail using that domain — including any spoofing attempts.
A DMARC record for a domain in active cold outreach should start conservative and tighten over time:
`
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100
`
Starting at p=none (monitor only, no enforcement) for the first few weeks lets a team review DMARC aggregate reports and confirm every legitimate sending source is passing before moving to enforcement. Jumping straight to p=reject on a domain with an incomplete SPF include list or an unrotated DKIM key can silently blackhole legitimate outbound mail — messages that fail DMARC don't bounce back with a clear error, they simply disappear at the receiving server, which makes this failure mode unusually hard to diagnose from the sending side.
For domains used specifically for cold prospecting rather than customer-facing transactional mail, we generally recommend holding at p=quarantine rather than pushing to p=reject. Quarantine routes failing mail to spam rather than rejecting it outright, which gives more tolerance for the inevitable infrastructure changes that come with rotating sending domains and mailboxes — a common practice in cold outreach that customer-facing transactional systems don't need to account for.
Authentication records don't exist in isolation — how a domain is structured for sending changes what "correct" DMARC alignment even looks like. We cover the mechanics of building out sending subdomains in our mailbox warmup playbook, but the authentication-specific takeaway is this: a dedicated prospecting subdomain (outreach.yourdomain.com or similar) should carry its own SPF include and its own DKIM selector, separate from the root domain used for corporate email. This isolates any reputation damage from an aggressive cold sending campaign away from the domain a company depends on for internal and customer communication, and it lets DMARC policy be set more aggressively on the root domain than would be safe on a domain actively running high-volume outreach.
The broader deliverability fundamentals — warmup pacing, sending volume ramp, list hygiene — are covered in our cold email deliverability guide, and the ongoing monitoring layer in our deliverability monitoring guide. Authentication is the foundation those practices sit on top of — get it wrong and no amount of careful warmup pacing will fully compensate.
Before sending any cold outreach campaign from a domain, confirm:
- One SPF record, under 10 DNS lookups, including every legitimate sending source
- DKIM signing active on every sending platform touching the domain, verified with a dedicated checker (not just a DNS lookup)
- DMARC published at minimum p=none with reporting enabled, ideally p=quarantine on established sending domains
- A dedicated prospecting subdomain separate from the root domain used for internal and customer communication
- DKIM key rotation scheduled every 6-12 months with overlapping selectors to avoid a signing gap
- DMARC aggregate reports reviewed monthly to catch alignment failures before they suppress volume
Skipping any one of these doesn't just risk occasional spam-folder placement — it can trigger the kind of pattern that gets an entire domain rate-limited or blocked by a major mailbox provider, which is far more expensive to recover from than the twenty minutes it takes to configure the records correctly at the start.
Authentication is the least interesting part of cold email automation and the part most likely to sink an otherwise well-targeted, well-written campaign. Teams that treat SPF, DKIM, and DMARC as a one-time setup step rather than an ongoing part of domain management are the ones who end up diagnosing a deliverability collapse three months in, usually after a DKIM key silently expired or a second SPF record got added by another tool.
OnyxSend handles authentication setup, DKIM rotation, and DMARC monitoring automatically as part of our automated prospecting workflow, alongside the ICP scoring and sequencing we cover in our SDR replacement guide — so sending domains stay authenticated without a dedicated deliverability hire watching DNS records. See our pricing or request access to get your sending domains audited before your next campaign goes out.