SPF, DKIM and DMARC are three DNS records that let a receiving mail server confirm your cold email really came from your domain. Without them, Gmail and other providers are more likely to reject or spam-fold your messages. This page covers what each record does and where your list fits in.
Key takeaways
- SPF lists which servers may send for your domain. DKIM signs each message. DMARC tells receivers what to do when both fail.
- Google asks every sender for SPF or DKIM, and senders of 5,000 or more messages a day for all three (Google sender guidelines, September 2026).
- Set the records up on every sending domain before the first message goes out.
- Authentication proves identity, not quality. A bad list still burns your reputation.
What it is
SPF, DKIM and DMARC are email authentication standards: SPF checks the sending server, DKIM checks a signature on the message, and DMARC ties both to the From domain and sets a policy for failures.
Each one lives in your DNS as a TXT record. You publish them once per sending domain. Receiving servers read them on every message.
You can check your setup by sending a test message to a mailbox you control and opening the original headers. Look for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results line. Any fail points to the record to fix.
The three are defined in public standards: SPF in RFC 7208, DKIM in RFC 6376 and DMARC in RFC 7489 (all checked September 2026).
How it works
A receiving server runs the checks in a fixed order when your message arrives.
- SPF. The server reads the domain in the envelope sender (the Return-Path) and looks up its SPF record. It checks whether the connecting IP address is on the list. A match is a pass.
- DKIM. Your sending tool added a signature header using a private key. The server reads the selector and domain from that header, fetches the public key from DNS and checks the signature. A valid signature is a pass.
- DMARC. The server looks up the DMARC record on the domain in the visible From address. Mail passes DMARC if SPF or DKIM passed and the passing domain matches the From domain. This match is called alignment.
- Policy. If both fail, the receiver applies your policy:
none(monitor only),quarantine(treat as suspect) orreject(refuse the message).
A worked example for the placeholder domain acme.com:
acme.com. TXT "v=spf1 include:_spf.google.com ~all"
google._domainkey.acme.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.acme.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"The first record says only Google's servers may send for acme.com. The second publishes the DKIM public key under the selector google. The third starts DMARC in monitor mode and sends daily reports to one mailbox.
Alignment trips up most cold email setups. Your tool may send with its own Return-Path domain, so SPF passes for the tool's domain but not for yours. DMARC then relies on DKIM, which is why you should sign with your own domain and not the tool's default one.
SPF vs DKIM vs DMARC
SPF and DKIM prove something about a message. DMARC decides what to do with that proof. People confuse them because all three appear as pass or fail in the same header.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| What it checks | The sending server's IP | A cryptographic signature on the message | That SPF or DKIM passed and matches the From domain |
| Where it lives | TXT record on the domain | TXT record at selector._domainkey.domain | TXT record at _dmarc.domain |
| Survives forwarding | Often no | Yes, if the body is untouched | Only if DKIM still passes |
| Sets a policy | No | No | Yes: none, quarantine or reject |
| Sends reports | No | No | Yes, through rua and ruf tags |
| Common mistake | More than 10 DNS lookups | Wrong selector or a short key | Jumping to reject before checking reports |
SPF has a hard limit: the standard allows at most 10 DNS lookups while evaluating a record (RFC 7208, section 4.6.4). Stack too many include: entries and SPF fails with a permanent error.
When it matters
Before you send the first cold email
Set all three records on the domain before you warm it. A new domain with no authentication starts with no trust and fails Gmail's bulk checks. Warm-up on top of broken DNS only trains the wrong reputation. See best cold email warm-up tools for that step.
When you add a sending tool
Every tool that sends as your domain must appear in SPF or sign with DKIM. A forgotten sequencer sends from an IP your record does not list. Add its include: value, then confirm the DKIM selector it gives you. Compare tools in best cold email campaigns.
When you pass 5,000 messages a day
Google requires SPF, DKIM and DMARC from senders of 5,000 or more messages a day to personal Gmail accounts. It also requires one-click unsubscribe for marketing and subscribed mail at that volume (Google sender guidelines, September 2026). Cold email teams that spread volume across many domains still need all three records on each domain.
When you use several domains
Cold email teams often send from secondary domains to protect the main one. Each secondary domain needs its own SPF, DKIM and DMARC records, and its own warm-up. Copy the same record pattern across them and change only the domain and the DKIM selector. Keep a sheet of which tool signs for which domain.
When your replies drop
Read your DMARC reports before you rewrite your copy. A report lists every source sending as your domain and whether it passed. A drop in placement often traces to one tool that fails alignment or one domain with a missing record. Copy changes come second, as covered in how to personalize cold emails with AI.
How LeadOcean handles it
LeadOcean does not touch your DNS, your sending tool or your inbox. It gives you the other half of deliverability: a list you can filter by email status before you send.
Authentication proves who you are. Bounces and spam complaints decide whether receivers keep trusting you. The field that maps to this is email_status, and the search filter is emailStatus. LeadOcean tracks 13 email status values, among them verified, catch_all_valid, catch_all, risky and invalid.
The free MCP count, count_leads, covers mailable addresses only by default: verified, catch_all_valid and catch_all. If you want the strictest list, filter to verified alone. The sizing call is free.
curl -s "https://api.leadocean.io/v1/people/search?count=true" \
-H "x-api-key: $LEADOCEAN_API_KEY" -H "content-type: application/json" \
-d '{
"jobLevel": ["VP"],
"country": ["US"],
"emailStatus": ["verified"],
"limit": 1
}' | jq '.meta.total'Read email_status on every row before you send. LeadOcean gives no refund or credit-back for bounced emails, so filter first. Pro is $499 a month, flat. See pricing.
FAQ
Do I need all three records for cold email?
Yes. Google requires only SPF or DKIM from small senders, but all three from bulk senders. Set all three from day one so you never retrofit them when volume grows.
What DMARC policy should I start with?
Start with p=none and a rua address. Read the reports for two to four weeks. Move to quarantine once every legitimate sender passes. Treat reject as the last step, not the first.
Do I set records on my main domain or my sending domains?
Both. Each domain that appears in a From address needs its own records. A secondary domain you send cold email from has no inherited authentication from your main domain.
Does authentication guarantee inbox placement?
No. It removes one reason for rejection. Receivers also weigh spam complaints, bounce rate, content and sending history. A verified list lowers the bounce part of that.
What key length should DKIM use?
Gmail requires a DKIM key of 1024 bits or longer for personal accounts and recommends 2048 bits if your provider supports it (Google sender guidelines, September 2026).
This page describes public technical standards and one provider's published sender rules. It is not legal advice.
Authenticate the domain, then verify the list.
Free to start. No credit card. 1,000 records to spend whenever you like.
Get your free API key →