Email Authentication: SPF, DKIM and DMARC Explained

Email was designed in an era of trust, so by default anyone can put any address in the "From" field — which is exactly why phishing and spoofing are so easy. Email authentication exists to let receiving servers answer a simple question: was this message really sent by someone authorized to send for this domain? Three standards work together to answer it: SPF, DKIM, and DMARC. None of them is sufficient alone, but combined they give mailbox providers strong signals to accept legitimate mail and reject forgeries. They are also increasingly mandatory: major providers now require authentication for bulk senders. The lookup tools referenced here — including the SPF checker — are server-assisted: a server fetches and parses the relevant DNS records for you and returns the results, rather than querying from inside your browser. It is worth being precise about what these standards promise. They authenticate the domain that sent a message and prove it was not forged or altered in transit; they do not, on their own, tell you whether the content is trustworthy or the sender is honest. A determined phisher who controls their own domain can still pass all three checks. The value is accountability: spoofing your domain becomes hard, and receivers gain a reliable signal to weigh alongside reputation and content filtering when deciding where a message lands.

Sender Policy Framework (SPF) lets a domain publish the list of servers permitted to send mail on its behalf. It lives in a single TXT record that starts with v=spf1 and ends with an "all" mechanism. A simple record might read: v=spf1 include:_spf.google.com ~all. The include pulls in another domain's authorized servers (here, Google's), and the trailing mechanism sets the default for everything else. ~all means "soft fail" (mark as suspicious), while -all means "hard fail" (reject). The receiving server checks the connecting server's address against this list. One important limit: SPF allows at most ten DNS-lookup mechanisms, and exceeding it causes a permanent error that breaks authentication. Consolidate includes if you approach the limit. Validate the record with the SPF checker, and build a correct one from scratch with the SPF generator.

DomainKeys Identified Mail (DKIM) takes a different approach. Instead of listing servers, it attaches a cryptographic signature to each outgoing message. The sending server signs selected headers and the body with a private key, and publishes the matching public key in DNS under a selector. When a message arrives, the receiver fetches the public key, recomputes the signature, and confirms the message was not altered in transit and genuinely came from a server holding the private key. Because the signature travels with the message, DKIM survives some forms of forwarding that break SPF. The public key is published as a TXT record at a name like selector._domainkey.example.com. You can retrieve and inspect a published key with the DKIM lookup tool, which is handy when a mail platform asks you to confirm a selector is live before enabling signing.

DMARC ties SPF and DKIM together and tells receivers what to do when a message fails. It also requires alignment — the domain that passes SPF or DKIM must match the visible "From" domain — which closes loopholes that authentication alone leaves open. A DMARC record is a TXT entry at _dmarc.example.com beginning with v=DMARC1. Its most important tag is the policy, p=, which takes one of three values, and you should adopt them in order: 1. p=none — monitor only. Nothing is blocked, but you receive aggregate reports showing who sends mail using your domain. Start here. 2. p=quarantine — failing mail is treated as suspicious, typically routed to spam. Move here once reports confirm your legitimate sources pass. 3. p=reject — failing mail is refused outright. This is the goal, offering the strongest protection against spoofing. The reason for the progression is safety: jumping straight to reject can bounce legitimate mail from a forgotten newsletter tool or ticketing system. The reports gathered during the "none" phase reveal those senders so you can authorize them first. Check an existing policy with the DMARC checker, and create a syntactically correct record with the DMARC generator.