SPF, DKIM, and DMARC: Email DNS Records Explained

Most cold email operators treat SPF, DKIM, and DMARC as boxes to check during domain setup, then never look at them again. We run AI outbound for 50 plus B2B companies, send roughly 8 million cold emails a year, and the single most common deliverability failure across that book is a misconfigured DNS record that nobody noticed for months. Below, the practitioner breakdown of what each of the 3 records actually does, how to set them up the first time, the 4 misconfigurations we see kill 30 to 60 percent of sends, and the right DMARC policy for a cold email domain in 2026.

What Are SPF, DKIM, and DMARC: The Short Definition

SPF (Sender Policy Framework)

A TXT record in your domain DNS that lists the IP addresses and hostnames authorized to send email on behalf of your domain. When a receiving server gets a message claiming to be from you, it pulls your SPF record, checks whether the sending IP appears on the list, and passes or fails the message accordingly. SPF protects against the simplest form of spoofing: someone forging your From address from an IP that has no business sending for you.

DKIM (DomainKeys Identified Mail)

A cryptographic signature that gets attached to every outgoing message and verified against a public key published in your domain DNS. The signature proves 2 things: the message came from a sender that holds your private key, and the body and key headers were not tampered with after signing. DKIM is the only one of the 3 records that survives forwarding intact, which is why Gmail weights it heavily in its placement decision.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

A TXT record that ties SPF and DKIM together with a policy and a reporting address. It tells the receiver what to do when a message fails authentication (none, quarantine, or reject) and where to send the daily aggregate report listing every IP that tried to send for your domain. Without DMARC, SPF and DKIM produce a pass or fail with no instructions, and the receiver has to guess at policy.

The mental model that helps: SPF answers the question "is this IP allowed to send for the domain." DKIM answers "was the message altered in transit and does it carry a valid signature for this domain." DMARC answers "given the SPF and DKIM results, what should the receiver do, and how do I find out about every attempt." The 3 records are not redundant. Each one closes a hole the others leave open.

What Is SPF and How It Actually Works

SPF is a single TXT record that lives at the root of your sending domain. The record contains a list of mechanisms (IP addresses, hostnames, or include statements referencing another domain's SPF record) and an enforcement mode at the end. When Gmail or Microsoft receives a message claiming to be from your domain, the server pulls your SPF record over DNS, checks the sending IP against the list, and applies the enforcement mode.

A typical SPF record for a cold email domain using Google Workspace plus a sending platform looks like this:

• v=spf1 declares this is an SPF record version 1.
• include:_spf.google.com imports every IP Google uses for outbound mail.
• include:sendgrid.net imports SendGrid's IP list (or whatever sending platform you use).
• ~all is the soft fail enforcement mode, the most common choice for cold email.

The enforcement mode at the end is the part most operators get wrong. The options are -all (hard fail, reject anything not on the list), ~all (soft fail, accept but flag), ?all (neutral, no policy), and +all (pass everything, never use this). Hard fail is the most secure but breaks legitimate mail that forwards through a third party. Soft fail is the standard recommendation for cold email because forwarding through a personal alias or a shared inbox should not silently drop the message.

The hard limit nobody talks about: SPF records can only contain 10 DNS lookups total. Every include statement, every redirect, and every a or mx mechanism counts as a lookup. Once you exceed 10, the SPF record returns a permerror and Gmail treats the entire SPF check as failed. Adding 4 sending platforms (Google, SendGrid, Mailgun, Instantly) without consolidation will blow past the limit fast. The fix is SPF flattening, which replaces the includes with the actual IP ranges and refreshes them on a schedule.

What Is DKIM and Why It Matters More Than SPF

DKIM is the strongest of the 3 records and the one Gmail leans on hardest in its placement scoring. The sending platform generates a public and private key pair. The private key stays on the sending server. The public key gets published as a TXT record at a specific selector subdomain in your DNS (typically something like default._domainkey.yourdomain.com or google._domainkey.yourdomain.com).

Every outgoing message gets signed in the headers using the private key. The receiving server pulls the public key from your DNS, verifies the signature against the message body and selected headers, and passes or fails the message based on the cryptographic check. The signature is unforgeable without the private key, which means DKIM is the strongest signal a receiver has that a message actually came from you.

DKIM matters more than SPF for one specific reason: forwarding. When a recipient auto-forwards your message to another inbox, the sending IP changes mid-transit. SPF breaks the moment the IP changes because the new sending IP is not on your authorized list. DKIM survives forwarding intact because the signature is embedded in the message itself and the public key is still published at the original domain. Per Google's sender guidance for bulk senders, DKIM alignment is one of the explicit thresholds Gmail enforces above 5,000 daily messages.

The setup mistake we see most often is using the default 1024-bit key length. Modern best practice is 2048-bit keys for any production sending domain. Some legacy hosting providers default to 1024 because the longer key exceeds 255 characters and has to be split across multiple strings inside the TXT record. The split is a 30 second DNS edit and produces a measurably stronger signal at Gmail's placement layer. Use 2048 unless your DNS provider literally cannot support split TXT strings.

What Is DMARC and How It Ties SPF and DKIM Together

DMARC is the policy layer. It does not authenticate anything on its own. It reads the SPF and DKIM results and applies the rules you set. A DMARC record is a single TXT entry at _dmarc.yourdomain.com that looks something like this:

• v=DMARC1 declares this is a DMARC record version 1.
• p=none sets the policy for messages that fail authentication (none, quarantine, or reject).
• rua=mailto:dmarc-reports@yourdomain.com tells receivers where to send the daily aggregate report.
• aspf=r and adkim=r set the alignment mode for SPF and DKIM (relaxed or strict).
• pct=100 applies the policy to 100 percent of failing messages (default).

Alignment is the load bearing concept most operators miss. SPF and DKIM both check authenticity, but the From header in your message can technically belong to a different domain than the one being authenticated. DMARC enforces that the visible From domain matches the SPF-authenticated domain or the DKIM-signing domain. Relaxed alignment lets subdomains match (mail.yourdomain.com aligns with yourdomain.com). Strict alignment requires an exact match. Relaxed is the standard choice for cold email because most sending platforms operate from a subdomain on your behalf.

The reporting piece is the unsung hero of DMARC. Once you publish a record with a rua address, Gmail, Microsoft, Yahoo, and most major receivers will send you a daily aggregate XML report listing every IP that sent mail claiming to be from your domain, whether each one passed or failed SPF and DKIM, and what the alignment looked like. The reports are machine readable and take a minute to parse with a tool like Postmark, dmarcian, or Valimail. They are the only window you get into who is actually trying to send mail in your name.

The 4 Misconfigurations That Quietly Kill Deliverability

Across the 50 plus B2B campaigns we run, the same 4 DNS misconfigurations show up over and over. Each one is invisible to the operator because nothing breaks visibly. The mail still sends. The mail still lands. Some percent just lands in spam instead of the inbox, and without parsing the DMARC reports there is no signal that anything is wrong.

The deliverability incident pattern is almost always the same. A domain ships fine for 60 to 120 days. Open rates and reply rates look healthy. Then one of the includes in the SPF record adds a new IP block, the lookup count crosses 10, and SPF silently breaks. Gmail's placement algorithm starts treating the domain with more suspicion. Reply rate drifts from 4.6 percent to 2.1 percent over 6 weeks. Nobody notices until the next campaign retro, and by then the domain reputation has already taken damage that takes another 30 to 60 days to recover.

How to Set Up SPF, DKIM, and DMARC for a Cold Email Domain

The setup order matters because each record builds on the last. SPF first, then DKIM, then DMARC. Set them up out of order and the DMARC reports will look broken even when everything is technically correct. Here is the practitioner sequence we use on every new cold email domain.

1. Publish SPF. Create a single TXT record at the root of your sending domain. Include your sending platform (Google Workspace, Microsoft 365, plus whatever cold email tool you use). End with ~all for soft fail. Verify the lookup count stays at or under 10.
2. Generate and publish DKIM. In your sending platform admin, generate a 2048-bit DKIM key. The platform will give you a selector name (like google or s1) and a public key. Publish the public key as a TXT record at selector._domainkey.yourdomain.com. Wait 24 hours for DNS propagation, then enable signing in the platform.
3. Publish DMARC at p=none. Create a TXT record at _dmarc.yourdomain.com with v=DMARC1, p=none, and a rua reporting address (use a tool like Postmark or dmarcian to receive the XML reports in a readable dashboard). Stay at p=none for at least 30 days to verify SPF and DKIM are aligning on every send.
4. Send a test message to Gmail. Open the test in Gmail, click the 3 dot menu, select Show original. Confirm SPF, DKIM, and DMARC all show PASS. If any show FAIL, fix before going any further.
5. Move DMARC to p=quarantine after 30 to 60 days. Once the reports show consistent SPF and DKIM alignment on 99 percent or more of your legitimate mail, tighten the policy. Quarantine routes failing messages to spam rather than rejecting them outright.
6. Move DMARC to p=reject after another 30 to 60 days. Once quarantine has been clean for 30 days and the reports show no surprise senders, set p=reject. This is the strongest policy and the one Gmail and Microsoft reward most in their placement algorithms.
7. Parse the reports weekly. Forever. The reports are the only signal you get when SPF lookup counts creep up, when a new third party platform starts sending under your domain, or when an attacker tries to spoof you. Parsing takes 5 minutes a week and prevents the silent decay pattern that kills most cold email domains.

What Gmail and Microsoft Actually Check at the Inbox

Per the 2024 bulk sender requirements Gmail and Yahoo rolled out (still the baseline in 2026), any sender above 5,000 messages per day per domain must pass all 3 authentication checks for the message to land in the primary inbox. Below that threshold the rules are softer, but the placement scoring still rewards full authentication. Microsoft has been quietly tightening to a similar standard through 2025 and 2026.

The thing operators miss: the 5,000 message threshold is per domain, not per workspace. If you run 30 sending domains for a cold email campaign and each one sends 500 messages a day, no single domain hits the 5,000 threshold, but Gmail still applies the placement scoring across all of them based on aggregate behavior tied to the IP block and the sending pattern. Authentication is no longer a "we are big enough to need it" concern. It is the price of entry for any sending domain that wants the inbox.

The Practitioner Take on DNS for Cold Email in 2026

DNS configuration is the most boring part of cold email and the highest leverage one. A misconfigured SPF record costs nothing visible day to day, then quietly drops 30 percent of your sends into spam over a 6 week window. A missing DKIM signature on a forwarded message looks fine in the local inbox and fails the moment Gmail decides to scrutinize the domain. A DMARC policy stuck at p=none with no reporting address means an attacker can spoof your domain for months without your knowledge.

The right move is to treat DNS as part of the sending infrastructure, not a one time setup task. Audit every sending domain monthly. Parse the DMARC reports weekly. Refresh flattened SPF records on a 30 day cadence. Regenerate DKIM keys annually. The whole cycle takes maybe 2 hours a month for a 30 domain sending footprint, and it prevents every silent placement decay we have seen at scale across the 50 plus B2B campaigns we operate.

If you are setting up cold email from scratch, do the 3 records on day one before you send a single message. If you have been running for a while and have never parsed a DMARC report, pull one this week. The signal is in the data and it has been sitting there waiting. The operators who treat DNS as infrastructure ship 40 to 60 percent inbox placement on cold email. The operators who set it once and forget it ship 20 to 30 percent and blame the copy.