SPF, DKIM, and DMARC: the setup that lands in the inbox
SPF says who can send, DKIM proves nothing was tampered with, DMARC ties them together and tells receivers what to do. Here is the whole picture.
Email authentication sounds like infrastructure trivia, but it is the gate every message passes through. Get these three records right and you clear the bar receivers set; get them wrong and even legitimate mail looks like spoofing.
SPF — who is allowed to send
SPF (Sender Policy Framework) is a DNS TXT record listing the servers permitted to send mail for your domain. It ends in an "all" mechanism that tells receivers how strict to be: -all (hard fail) rejects everyone else, ~all (soft fail) flags them. Watch the 10-DNS-lookup limit — too many includes and SPF silently breaks.
v=spf1 include:_spf.google.com include:sendgrid.net -allDKIM — proof nothing changed
DKIM (DomainKeys Identified Mail) signs each message with a private key; receivers verify it against a public key in your DNS. A valid signature proves the mail really came from your domain and was not altered in transit.
DMARC — the policy that ties it together
DMARC sits on top of SPF and DKIM. It tells receivers what to do when a message fails (p=none monitors, p=quarantine sends to spam, p=reject blocks it) and where to send reports (rua). Gmail and Yahoo now require at least p=none for bulk senders — but p=reject is the goal.
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100You still need more than DNS
Authentication is necessary, not sufficient. A perfectly authenticated brand-new domain that blasts 1,000 cold emails will still land in spam. You need warmup and reputation monitoring on top — which is the part CogniLead manages so you do not have to.
Warmed pools, a reputation circuit-breaker, suppression on every send — per send, via API or MCP.