Skip to content
LeakLens
emaildnsdeliverability

SPF, DKIM and DMARC Explained: Why Your Emails Land in Spam, or Get Spoofed

How email authentication actually works, what each DNS record does, how to verify them in minutes, and the minimal setup that stops exact-domain spoofing.

Published · Updated · 9 min read

Email has no built-in proof of sender. Anyone can claim to be you@example.com in a message envelope the same way anyone can write a return address on a physical envelope. SPF, DKIM and DMARC are the three DNS-based patches the internet actually agreed on to restore accountability, and when any of them is missing, your mail is both easier to impersonate and more likely to be filtered as suspicious.

This guide explains what each record proves, how they fit together, and how to check any domain in under two minutes with live DNS lookups.

The problem: anyone can send as you

The Simple Mail Transfer Protocol separates the envelope sender, shown to mail servers, from the header From, shown to humans. That gap lets attackers craft messages that pass a casual glance while originating from infrastructure you never authorized. Spam filters respond by scoring unauthenticated mail heavily negative, meaning legitimate messages without authentication often land in spam even when they were never spoofed.

Authentication does not encrypt content and does not prove you own a domain; it proves the message took an authorized path and was not altered after signing. That proof is enough for modern filters to distinguish you from a forger.

SPF: which servers may send for this domain

SPF is a TXT record at your domain's apex listing the IPs and includes allowed to send on its behalf. Receiving servers extract the envelope sender's domain, fetch its SPF record, and reject or penalize mail from unlisted hosts. The record looks like v=spf1 include:_spf.google.com ~all for a Google Workspace domain or a list of ip4: and ip6: entries for self-hosted mail.

  • Use a soft fail (~all) during rollout so legitimate but misconfigured forwarders do not hard-bounce; move to -all once telemetry is clean.
  • Every include: triggers an additional DNS lookup; stay under the 10-lookup limit or validation fails.
  • SPF authenticates the envelope domain, not the visible From header, which is why it cannot succeed alone against display spoofing.

DKIM: a cryptographic signature by the sender

DKIM adds a digital signature header whose domain and selector point to a public key published as a TXT record under selector._domainkey. The sending server signs selected headers and the body; receivers verify the signature with the published key. A valid signature proves the message originated from a holder of the private key and that signed parts were not modified in transit.

Key length matters: 1024-bit RSA was once common but is now marginal; 2048-bit is the modern baseline. Key rotation, publishing a new selector and phasing out the old, limits blast radius if a key is ever exposed, and aligns cleanly with warmup periods.

DMARC: the policy that ties them together

DMARC is a TXT record at _dmarc that tells receivers what to do when authentication fails and where to send aggregate and forensic reports. The crucial mechanism is alignment: DMARC passes only when either SPF or DKIM passes and the authenticated domain aligns with the header From. Without alignment, SPF passing for a different domain does not help you.

A minimal but meaningful DMARC record starts with v=DMARC1; p=none; rua=mailto:reports@example.com during monitoring, then graduates to p=quarantine and finally p=reject once legitimate flows are authenticated. Reports, sent daily by major providers, are the fastest way to discover third-party senders you forgot to include in SPF or to sign with DKIM.

Check any domain in two minutes

Lookups make abstract records concrete. Query a domain's TXT records and search for entries starting with v=spf1 and v=DMARC1; query selectors like google._domainkey or default._domainkey for DKIM keys if you know the provider's selector. A domain that sends mail without all three primitives can be impersonated on the exact domain with convincing exact-spoof messages, and will see steadily lower deliverability as providers tighten defaults.

  1. Run a DNS lookup for TXT records on the domain you own or investigate; note SPF and DMARC entries.
  2. If you operate mail, add SPF first, then publish DKIM keys from your provider, then publish DMARC at p=none to collect reports.
  3. After two weeks of clean reports, tighten DMARC to p=quarantine with a low pct:, then to p=reject, and keep monitoring rua: reports for new senders.

Good authentication is invisible to recipients and non-negotiable to filters. It keeps your mail out of spam and your domain out of someone else's phishing kit. Check any address with our Email Validator and any domain's records with our DNS Lookup before trusting mail that claims to be important.