SPF, DKIM and DMARC explained for cold email

SPF, DKIM and DMARC are three DNS records that let a receiving server check that a message really came from the domain it claims. Skip them, or get one wrong, and Gmail and Yahoo will filter or reject your cold email no matter how good the copy is. Here is what each one does, how they fit together, and the mistakes that break them.

What SPF, DKIM and DMARC each do

SPF (Sender Policy Framework, RFC 7208) is a list of the servers allowed to send mail for a domain. It is a TXT record on the domain, like v=spf1 include:_spf.google.com ~all. The receiving server checks the IP that delivered the message against that list. One detail trips people up: SPF checks the envelope sender (the Return-Path), not the From address you see in the inbox.

DKIM (DomainKeys Identified Mail, RFC 6376) is a signature. Your mail server signs each message with a private key, and the matching public key sits in DNS under a selector, at selector._domainkey.yourdomain.com. The receiver fetches the key and checks the signature. If it verifies, the message was signed by the domain that owns the key and the signed parts weren't changed on the way.

DMARC (RFC 7489) sits on top of the other two. It's a TXT record at _dmarc.yourdomain.com that does two things: it says what to do with mail that fails (nothing, quarantine, or reject), and it asks receivers to send you reports about who is sending as your domain.

How they fit: alignment

Passing SPF or DKIM isn't enough on its own. DMARC asks for alignment: the domain that passed SPF or DKIM has to match the domain in the visible From address. A message passes DMARC if SPF or DKIM passes and aligns. You don't need both, but you want both.

This is where cold email setups go wrong. A sending service can sign every message with its own domain. DKIM passes, but it doesn't align with your From domain, so DMARC treats it as a stranger. The fix is to set up the service's custom DKIM for your domain, so the signature uses your domain.

A bounce like 550 5.7.26 is Gmail telling you exactly this. Its own text points to three causes: SPF and DKIM both failed, your SPF record ends in -all and the sending IP isn't listed, or your DMARC policy told Gmail to reject unauthenticated mail.

What Gmail and Yahoo require from bulk senders

Both providers set rules for bulk senders. Read them yourself, because they change:

• Google's email sender guidelines: SPF and DKIM for all senders, plus a DMARC record for bulk senders (Google defines bulk as sending 5,000 or more messages a day to Gmail addresses), with the From domain aligned to SPF or DKIM. Marketing mail also needs easy unsubscribing, and the spam rate in Postmaster Tools should stay under 0.1%, never reaching 0.3%.

• Yahoo's sender best practices: the same core of SPF, DKIM and DMARC, plus a low complaint rate and easy unsubscribe.

A DMARC record with p=none meets the requirement to have one. For cold email, treat the rules as the floor even if you send far below the bulk line: you're an unknown sender, and unauthenticated mail from an unknown sender is the easiest thing to filter.

Roll out DMARC at p=none, then tighten

Don't start with p=reject. You may not know every service that sends as your domain, and a strict policy will block the ones you forgot.

1. Publish p=none with a reporting address. For example v=DMARC1; p=none; rua=mailto:[email protected]. Nothing about delivery changes; you start receiving aggregate reports.

2. Read the reports for a few weeks. They list every source sending as your domain and whether it passed and aligned. Fix the legitimate ones. Notice the ones you don't recognize.

3. Move to p=quarantine, optionally with pct to apply it to a share of mail first.

4. Move to p=reject once everything legitimate passes. RFC 7489 defines all three policies.

Cold-email domains are usually simple: one or two sending services and nothing else. That makes tightening quick. A primary domain with a dozen tools sending as it is where you go slowly. For why that split matters, see cold email infrastructure.

Common mistakes

• Two SPF records. A domain must have exactly one SPF record. If two TXT records start with v=spf1, SPF returns a permanent error. Merge them into one.

• More than 10 lookups. SPF allows at most 10 DNS-querying terms (include, a, mx and a few more), per RFC 7208, section 4.6.4. Stack up several include: entries and you can go over, which also returns an error. Remove services you no longer use.

• Forgetting a sending service. The newsletter tool, the CRM, the invoicing app: anything that sends as your domain needs to be in SPF and ideally signing with your DKIM. These are what p=reject quietly breaks.

• Treating the From domain and the Return-Path as the same thing. SPF can pass for the service's domain and still not align with yours.

• Changing records and not testing. DNS edits fail quietly. Send a test every time.

How to check a message's headers

Send a test to a Gmail address, open it, and choose Show original. Gmail lists SPF, DKIM and DMARC with PASS or FAIL. In any provider's raw headers, find the Authentication-Results line and look for:

spf=pass
dkim=pass
dmarc=pass

Check which domain each result names. dkim=pass for a domain that isn't yours is the alignment problem above. Anything other than three passes is the first thing to fix, before you look at copy or lists. The rest of the checklist is in how to stop emails going to spam.

Where SendingOS fits

DNS records are yours to publish; no sending tool can do that for a domain it doesn't control. In SendingOS, bounces are sorted into hard, soft or block with the reason and SMTP code shown on the conversation, so an authentication block like 5.7.26 reads as a sender problem and not a dead address. Every inbox's connection is also checked every few minutes, and an inbox that fails stops sending until it passes again.