SPF, DKIM & DMARC: The Complete Email Authentication Setup Guide

Why email authentication is mandatory now

Email was designed in an era of trust, with no built-in way to prove that a message claiming to come from your domain actually did. SPF, DKIM, and DMARC are the three DNS-based standards that retrofit that proof onto email. Together they let a receiving server confirm that a message was sent by a server you authorized, was not tampered with in transit, and genuinely originates from your domain.

Since Gmail and Yahoo began enforcing bulk-sender requirements in February 2024, this is no longer a nice-to-have. Senders without proper authentication see a growing share of their mail rejected or dropped into spam. This guide walks through all three records in the right order, because they build on each other — SPF and DKIM come first, and DMARC ties them together.

SPF: authorizing your sending servers

SPF (Sender Policy Framework) is a single DNS TXT record listing every server and service permitted to send mail on behalf of your domain. When a receiver gets a message, it checks the sending server’s IP against this list. If the IP is authorized, SPF passes; if not, it fails.

The record lives at the root of your domain and begins with v=spf1. You add an include or ip4/ip6 mechanism for each sending source — your ESP, your CRM, your transactional provider, your own mail server — and end with an "all" mechanism describing how strict to be. Use ~all (softfail) while testing and -all (hardfail) once you are confident every legitimate source is listed.

; SPF TXT record at the domain root (yourbrand.com)
yourbrand.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all"

; Rules of thumb:
;  - Only ONE SPF record per domain (multiple v=spf1 records break it)
;  - Keep it under 10 DNS lookups (the include limit) or SPF fails with permerror
;  - Move to -all once every legitimate sender is covered

DKIM: signing your messages

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message. Your sending platform holds a private key and signs the headers and body; the matching public key is published in your DNS. The receiver fetches the public key, verifies the signature, and thereby confirms two things: the message really came from your domain, and it was not altered between sending and receipt.

You do not generate DKIM keys by hand in practice — your ESP generates the key pair and gives you a CNAME or TXT record to publish at a "selector" subdomain. The selector lets you run multiple keys (for different providers, or for key rotation) simultaneously. Publish exactly what your provider gives you, then use their dashboard to confirm the signature validates.

; DKIM record published at a selector subdomain
selector1._domainkey.yourbrand.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq...<public key>...QAB"

; The message header will then carry, e.g.:
; DKIM-Signature: v=1; a=rsa-sha256; d=yourbrand.com; s=selector1; h=from:to:subject; bh=...; b=...

DMARC: tying it together and getting reports

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer. It does two jobs. First, it tells receivers what to do with mail that fails authentication: do nothing (p=none), send it to spam (p=quarantine), or reject it outright (p=reject). Second, it asks receivers to send you aggregate reports about who is sending mail using your domain — invaluable for spotting both misconfigured legitimate services and outright spoofing.

The DMARC record lives at _dmarc.yourbrand.com. Crucially, DMARC only passes if SPF or DKIM not only passes but is aligned — meaning the domain that passed matches the domain in your visible From address. This alignment requirement is what actually stops spoofing, because an attacker can pass SPF for their own domain but cannot align it with yours.

; DMARC record
_dmarc.yourbrand.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbrand.com; adkim=s; aspf=s; pct=100"

; p    = policy (none | quarantine | reject)
; rua  = address to receive aggregate reports
; adkim/aspf = alignment mode (s=strict, r=relaxed)
; pct  = percentage of failing mail the policy applies to

Rolling out DMARC enforcement safely

The single biggest mistake teams make is jumping straight to p=reject and accidentally blocking their own legitimate mail — the invoicing tool, the support desk, the marketing platform nobody remembered was sending as the domain. The correct rollout is gradual and driven by the reports.

Start at p=none, which changes nothing about delivery but turns on reporting. Read the aggregate reports for a few weeks until you can see every legitimate sending source and confirm they all pass and align. Then move to p=quarantine, optionally using the pct tag to ramp (pct=25, then 50, then 100). Only when quarantine is clean should you advance to p=reject, the fully protected end state.

• Week 1–2: p=none. Collect reports, inventory every sender, fix any that fail alignment.
• Week 3–4: p=quarantine with pct=25–100. Failing mail goes to spam; watch for false positives.
• Week 5+: p=reject. Spoofed mail is now blocked outright; your domain is protected.
• Keep monitoring reports indefinitely — new tools get added and can silently break alignment.

Authentication is necessary but not sufficient

Passing SPF, DKIM, and DMARC gets you in the door, but it does not by itself land you in the inbox. Authentication proves you are who you say you are; it says nothing about whether recipients want your mail. A perfectly authenticated domain with a dirty list and a high complaint rate will still be filtered to spam. Authentication and list hygiene are two halves of the same discipline.

That is why the highest-performing senders pair correct authentication with verifying every address before they send. Verification keeps bounce and complaint rates low, which protects the reputation that authentication alone cannot build. Check an address in real time with a single call:

curl -X GET "https://verifly.email/api/v1/verify?email=prospect@example.com" \
  -H "Authorization: Bearer vf_your_api_key"

Your authentication checklist

Set up all three records, in order, and verify each with your provider’s tools or a public checker before moving on. One SPF record listing every sender, ending in -all. DKIM signing enabled with the public key published at your selector. DMARC starting at p=none and advancing to p=reject once reports confirm all legitimate mail aligns. Get those three right and you have cleared the authentication bar that mailbox providers now enforce.

From there, the work shifts to reputation and hygiene. Our complete deliverability guide covers the reputation side, and the bulk email verification API handles the list side before every campaign.