SPF, DKIM and DMARC

Anyone can write your domain into the From line of an email – the mail protocol doesn't stop them. Three DNS records make sure receiving servers can tell your mail from the fakes.

The short answer

SPF, DKIM and DMARC are three DNS-based checks against forged email senders. SPF lists the hosts that may send mail for a domain [1], DKIM adds a cryptographic signature whose public key sits in DNS [2], and DMARC tells receivers what to do with messages that fail and where to send reports [4]. What changed in 2026? Since May 2026, DMARC is defined by RFC 9989, a Standards Track document that obsoletes RFC 7489 [4]. Our assessment: set up all three, start DMARC with p=none, and tighten it once the reports look clean.

How it works

1. SPF. A domain publishes a TXT record that starts with v=spf1 and names the hosts allowed to use the domain [1]. SPF checks the envelope sender (MAIL FROM) and the HELO name, not the From line you see in your mail program [1]. A qualifier sets the result of each mechanism: + for pass, - for fail, ~ for softfail and ? for neutral [1]. An evaluation may use at most 10 DNS-querying terms such as include, a, mx, ptr and exists; more lead to a permanent error [1].
2. DKIM. The sending server signs selected header fields and the body. The DKIM-Signature header names the signing domain in d= and a selector in s=, and the receiver fetches the public key from a TXT record at selector._domainkey.domain [2]. RFC 8301 forbids rsa-sha1 and requires RSA keys of at least 1,024 bits, with at least 2,048 bits recommended [3].
3. DMARC. The record sits at _dmarc in front of your domain [4]. A message passes DMARC when SPF or DKIM succeeds for a domain that aligns with the author domain in the From line, either relaxed (same organizational domain) or strict (identical) [4]. The p tag sets the policy: none, quarantine or reject [4].
4. What RFC 9989 changes. The pct tag is gone; with the new tag t=y, a domain requests a test mode in which receivers apply one level less than the published policy [4]. The organizational domain is now found with a "DNS Tree Walk" instead of a public suffix list, and np sets a policy for non-existent subdomains [4]. Report formats now live in RFC 9990 (aggregate reports) and RFC 9991 (failure reports) [4].
5. Reports. With rua, receivers send aggregate reports to an address you choose [4]. They show which servers send mail in your name, including the ones you forgot.

A practical example

For example.com, which sends through a single provider, the three records could look like this; the provider name and the key are placeholders:

example.com.                  TXT "v=spf1 include:spf.provider.example -all"
sel1._domainkey.example.com.  TXT "v=DKIM1; k=rsa; p=<public key from your provider>"
_dmarc.example.com.           TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

You can check what public DNS returns, for example with dig +short TXT _dmarc.example.com. Once the reports only show your own servers, move p to quarantine and later to reject [4]. Domain and provider are made up, not our setup.

Checklist

• List every service that sends mail for your domain, including newsletter and ticket systems, before you write the SPF record [1].
• Keep SPF within 10 DNS lookups; nested include terms count too [1].
• Use DKIM keys with at least 2,048 bits if your provider lets you choose [3].
• Start DMARC with p=none and an rua address, and read the reports [4].
• Move to quarantine or reject only when all legitimate mail passes [4].
• Remove the pct tag when you update an old record, because RFC 9989 no longer defines it [4].