Email authentication sounds like a wall of acronyms, but the actual setup is just three records you publish in your domain's DNS. SPF, DKIM, and DMARC each prove a different part of 'this email really came from us,' and Google and Yahoo now require all three from anyone sending at scale. Get them right once and they run quietly in the background. Get them wrong — a missing include, a typo'd selector, a DMARC policy you flipped too early — and your mail silently disappears into spam folders while everything looks fine on your end.
This is the hands-on walkthrough: what each record does, exactly what to put in DNS, how SPF includes and the -all qualifier work, how to generate and publish a DKIM keypair and selector, and how to roll DMARC from monitoring all the way to enforcement without breaking your own mail. If you want the why behind the rules — the 0.3% spam threshold, the one-click unsubscribe mandate — that's covered in our Google and Yahoo sender requirements guide. This one is the how.
Before you start: how DNS records fit together
All three records live in the same place — your domain's DNS, managed wherever your domain is registered or wherever its nameservers point (Cloudflare, GoDaddy, Namecheap, Route 53, etc.). All three are TXT records, the generic 'text' record type DNS uses for arbitrary data. The difference is the host (the name the record sits at) and the value (the string it contains).
It helps to know what each one verifies before you touch anything. SPF answers 'is this server allowed to send for this domain?' DKIM answers 'was this specific message actually signed by this domain and left untouched in transit?' DMARC answers 'what should the receiver do if SPF or DKIM fails, and where do I send the reports?' You need all three, and they're checked together — a concept called alignment, which we'll come back to with DMARC.
One practical note: DNS changes aren't instant. Records propagate over minutes to a few hours depending on the TTL (time-to-live) you set. Set a low TTL (300 seconds) while you're configuring so corrections apply fast, then raise it once everything verifies.
Step 1: Set up your SPF record
SPF (Sender Policy Framework) is a single TXT record published at the root of your sending domain that lists every source allowed to send mail for it. A receiving server reads it, checks whether the connecting server is on the list, and passes or fails the message accordingly.
The record goes at the host '@' (the bare domain) and always starts with 'v=spf1'. After that you add a mechanism for each sending source — most commonly an 'include:' that pulls in your email platform's own SPF list. Then you close with an 'all' qualifier that decides what happens to everything not listed. A typical record looks like: 'v=spf1 include:_spf.google.com -all'. If you send through more than one provider, you chain the includes: 'v=spf1 include:_spf.google.com include:sendgrid.net -all'.
The qualifier at the end is the part people get wrong. '-all' (hard fail) tells receivers to reject anything not on your list — this is what you want for cold email, because it's the strongest signal. '~all' (soft fail) means 'probably unauthorized, but accept and mark' — acceptable as a temporary step, but weaker. '+all' would authorize the entire internet to send as you; never use it. For a domain whose only job is sending your campaigns, '-all' is correct.
- Record type: TXT · Host: @ (the root domain) · Value starts with 'v=spf1'.
- Add one 'include:' per sending platform (your provider publishes the exact value to use).
- End the record with '-all' for cold email — the hard-fail qualifier is the strongest signal.
- Publish only ONE SPF record per domain. Two SPF records is an error that fails the check entirely.
- Stay within 10 DNS lookups total — every 'include' counts, and exceeding 10 silently invalidates SPF.
Step 2: Generate and publish your DKIM keys
DKIM (DomainKeys Identified Mail) is a cryptographic signature added to every message you send. It works on a keypair: a private key your sending platform holds and uses to sign outgoing mail, and a matching public key you publish in DNS so receivers can verify the signature. If a message is altered in transit, or wasn't really signed by you, verification fails.
You don't usually generate the keypair by hand — your email platform does it for you. In your sending platform's admin (Google Workspace, your ESP, or your cold-email infrastructure), you enable DKIM for the domain and it produces the public key plus a selector. The selector is just a label (like 'google' or 's1') that lets a domain run multiple keys at once and rotate them later. The platform tells you exactly what to publish.
You then add the public key as a TXT record at a host built from the selector: '[selector]._domainkey.yourdomain.com'. For a selector named 'google' on example.com, the host is 'google._domainkey.example.com', and the value is the long 'v=DKIM1; k=rsa; p=...' string the platform gave you (the 'p=' part is the public key itself). Once it's published and verified, you flip on signing in the platform. From that point every email carries a signature receivers can check against the key in your DNS.
- Let your sending platform generate the keypair — copy the public key and selector it gives you.
- Record type: TXT · Host: [selector]._domainkey · Value: the full 'v=DKIM1; k=rsa; p=...' string.
- Keep the private key inside the platform — it is never published and never shared.
- After the record verifies, enable DKIM signing in the platform so mail is actually signed.
- Rotate keys periodically by adding a new selector before retiring the old one — no downtime.
Step 3: Publish DMARC and understand alignment
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy that sits on top of SPF and DKIM. It tells receiving servers what to do when a message fails authentication, and — critically — it asks them to send you reports on who's mailing as your domain. It's a single TXT record published at the host '_dmarc' (so '_dmarc.yourdomain.com').
A starting record looks like: 'v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com'. The 'p=' is the policy — what to do with failing mail. The 'rua=' is the address where aggregate reports get sent. You'll start at 'p=none' (monitor only, change nothing) on purpose; more on the ramp in the next step.
The concept that makes DMARC pass or fail is alignment. It's not enough for SPF or DKIM to pass on their own — the domain they authenticate has to match the domain in the visible 'From' address. SPF aligns when the envelope-sender domain matches the From domain; DKIM aligns when the signing domain matches it. A message passes DMARC if at least one of SPF or DKIM both passes and aligns. This is why simply 'having' SPF and DKIM isn't sufficient — they have to be set up on the same domain you send From, or DMARC will fail even though the individual checks pass.
- Record type: TXT · Host: _dmarc · Value starts with 'v=DMARC1'.
- 'p=' sets the policy: none, quarantine, or reject. 'rua=' sets where aggregate reports are sent.
- DMARC passes only with alignment — the authenticated domain must match the visible From domain.
- One of SPF or DKIM passing AND aligning is enough for DMARC to pass.
Step 4: Ramp DMARC from p=none to p=reject
The mistake that breaks people's mail is jumping straight to enforcement. DMARC is designed to be ramped in three stages, and rushing it can quarantine or reject your own legitimate email. The whole point of starting soft is to watch before you enforce.
Stage one is 'p=none'. This changes nothing about delivery — receivers still deliver failing mail as normal — but it turns on the aggregate (rua) reports. Run this for a couple of weeks and actually read the reports: they're XML summaries showing every source sending as your domain and whether each passed SPF, DKIM, and alignment. This is where you catch a sending source you forgot to add to SPF, or a DKIM selector that isn't aligning. Fix everything until the reports show your real mail passing cleanly.
Stage two is 'p=quarantine'. Now receivers send failing mail to the spam folder instead of the inbox. Because you already cleaned up alignment at p=none, your legitimate mail keeps landing while spoofed or misconfigured mail gets filtered. Watch the reports a while longer to confirm nothing legitimate is being caught.
Stage three is 'p=reject'. Receivers now refuse failing mail outright — the strongest protection, and the policy you ultimately want. Reaching p=reject means anything claiming to be your domain that isn't properly authenticated simply doesn't get delivered, which protects your domain's reputation. You can also tighten gradually with the 'pct=' tag (e.g. apply the policy to 25% of mail first) if you want an even more cautious roll-out.
- p=none — monitor only; turns on rua reports without affecting delivery. Start here.
- p=quarantine — failing mail goes to spam. Move here once reports show your real mail aligned.
- p=reject — failing mail is refused outright. The end goal once you're confident.
- Read the rua reports at every stage — they're how you catch a missed source before it costs you.
Step 5: Verify everything is working
Don't trust that a record is live just because you saved it. After publishing, confirm each one actually resolves and passes. The simplest check is to query DNS directly — a 'dig TXT yourdomain.com' shows your SPF record, 'dig TXT [selector]._domainkey.yourdomain.com' shows DKIM, and 'dig TXT _dmarc.yourdomain.com' shows DMARC. Plenty of free web-based checkers do the same with a friendlier readout.
The most reliable real-world test is to send yourself a message and inspect the headers. In Gmail, open the message, choose 'Show original,' and you'll see SPF, DKIM, and DMARC each reported as PASS or FAIL, along with whether they aligned. PASS on all three with alignment means your setup is correct. A FAIL points you straight at which record to fix.
Then keep watching. Authentication isn't entirely set-and-forget: the DMARC rua reports keep arriving, and they'll surface a new sending source, an expired key, or a provider change before it quietly tanks your delivery. Reviewing them periodically is the cheapest insurance you have against silently dropping out of the inbox.
Why MCA shops outsource this entirely
Doing this once, for one domain, is a manageable afternoon. The problem is that serious MCA cold email is never one domain. Sending cold email from your primary operational domain is reckless — if it gets blacklisted, the email your business actually runs on dies with it. So MCA senders use cousin domains: lookalike sending domains kept separate from the real one. And to send at volume without tripping spam filters, you don't use a handful — you use dozens or hundreds, with sending split across many inboxes and IPs.
Now multiply everything above across all of them. Every cousin domain needs its own SPF record with the right includes and -all, its own DKIM keypair and published selector, and its own DMARC record ramped carefully from p=none to reject — plus ongoing rua monitoring on each one, key rotation, and fixes whenever a provider changes its sending IPs. A single typo'd selector or a forgotten include on one domain means that domain silently falls out of the inbox, and you may not notice until the apps stop coming. That operational load, repeated across a constantly rotating fleet of domains, is exactly why MCA shops stop trying to manage authentication themselves.
It's why we built MCA Rocket to handle it by default. Full SPF, DKIM, and DMARC authentication is configured and verified on every single sending domain before a single email goes out — not as a setup checklist you run once, but as continuous infrastructure across a rotating fleet of cousin domains, all warmed by our 2M+ address network and monitored so nothing silently drops. Authentication is table stakes; we run it at scale so you never have to think about a TXT record again.
