SPF, DKIM and DMARC explained

Anyone can write any address in an email's From line. SPF, DKIM and DMARC are three standards, all published in DNS, that let receiving mail servers check whether a message claiming to come from your domain really did. Your Domain Statistics report shows the SPF and DMARC records a domain publishes.

SPF: which servers may send

Sender Policy Framework (RFC 7208) lets a domain owner list the servers allowed to send mail using the domain. The receiving server checks the connecting IP address against that list. SPF checks the envelope sender (the MAIL FROM, also called the return path or bounce address) and the HELO name, not the From address the reader sees.

SPF is a single TXT record that starts with v=spf1:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.example.net ~all"

• ip4: and ip6: list addresses directly.
• include: pulls in another domain's SPF record, typically your email provider's.
• The ending sets what happens to everything else: -all (fail), ~all (softfail) or ?all (neutral).
• Publish only one SPF record. If a receiver finds more than one, the result is permerror.

The 10-lookup limit

Some terms make the receiver do extra DNS lookups: include, a, mx, ptr, exists and redirect. RFC 7208 caps these at 10 per check. Going over gives permerror, an error result, so SPF can't pass. ip4, ip6 and all don't count. The NCSC points out that includes are often nested. Its example is a single Google include that adds up to four lookups (NCSC SPF guidance). Several third-party services can push you over the limit without you noticing. RFC 7208 also says lookups that return nothing ("void lookups") should be limited to two, and that the ptr mechanism shouldn't be used at all.

DKIM: a signature on every message

DomainKeys Identified Mail (RFC 6376) adds a cryptographic signature to each message. The signature names a domain (d=) and a selector (s=). The public key used to check it is published at selector._domainkey.domain:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB"

RFC 8301 says RSA keys must be at least 1,024 bits, and recommends at least 2,048 bits. The sender chooses the selector, so a lookup tool can't list a domain's DKIM keys from the domain name alone. To find one, open the full headers of a message you've received, note the s= and d= values in the DKIM-Signature line, and look up that name.

DMARC: tying it to the From address

DMARC is published as a TXT record at _dmarc. in front of the domain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

A message passes DMARC if SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From address. Under relaxed alignment (the default), the two only need the same organisational domain, so mail.example.com aligns with example.com. Strict alignment (adkim=s, aspf=s) needs an exact match.

The p= tag sets the policy:

• p=none – no preference. Delivery isn't affected, but with rua= set you get reports. This is monitoring mode.
• p=quarantine – failing mail is treated as suspicious. The NCSC describes this stage as sending spoof emails to spam.
• p=reject – failing mail is a clear sign the use of the domain isn't valid.

rua= asks receivers to send aggregate reports: XML summaries, sent daily or more often, of which servers sent mail as your domain and whether it passed. ruf= requests reports on individual failed messages. sp= sets a policy for subdomains.

DMARC is now an IETF standard

The original DMARC document, RFC 7489 (2015), was informational. In May 2026 the IETF published RFC 9989 as a Standards Track replacement. Reporting moved into RFC 9990 (aggregate) and RFC 9991 (failure). Practical changes include:

• The pct= tag is gone, along with rf= and ri=. A new t=y test flag asks receivers to apply one level less than your stated policy.
• A new np= tag sets a policy for subdomains that don't exist.
• Organisational domains are found by walking up the DNS tree, not from a public suffix list.
• RFC 9989 warns that p=reject causes problems for domains whose users post to mailing lists. Domains using p=reject must sign with DKIM, not rely on SPF alone.

Gmail and Yahoo sender rules (from 2024)

From 1 February 2024, Google requires everyone sending to personal Gmail accounts to set up SPF or DKIM, have valid forward and reverse DNS, use TLS and keep reported spam below 0.3% (Gmail sender guidelines). Senders of more than 5,000 messages a day must also have:

• both SPF and DKIM
• a DMARC record (p=none is acceptable)
• a From domain aligned with SPF or DKIM
• one-click unsubscribe for marketing mail

Google counts all messages from the same primary domain towards the 5,000. Once a sender has been classed as a bulk sender, it stays one permanently. Since November 2025, mail that doesn't comply can be temporarily or permanently rejected (Gmail FAQ).

Yahoo's rules also took effect in February 2024 (Yahoo sender requirements). All senders need SPF or DKIM, spam below 0.3% and valid forward and reverse DNS. Bulk senders also need SPF and DKIM, DMARC of at least p=none, alignment, a working list-unsubscribe header, and must honour unsubscribes within two days.

What the UK's NCSC recommends

The National Cyber Security Centre's email security guidance says all your domains, including parked ones, should have DMARC. It recommends starting with p=none (NCSC), then moving to quarantine and finally to reject. It notes that many organisations move from quarantine to reject after about three months, and advises monitoring reports for at least two weeks afterwards (NCSC). That guidance dates from 2019 and uses pct= to phase changes in. RFC 9989 has since removed pct=, so step through the policies one at a time instead, or use t=y.

For domains that never send email, the NCSC suggests (parked domains):

parked.example.          TXT  "v=spf1 -all"
_dmarc.parked.example.   TXT  "v=DMARC1; p=reject"
parked.example.          MX   0 .
*._domainkey.parked.example.  TXT  "v=DKIM1; p="

The MX 0 . line is a "null MX" (RFC 7505). It tells senders the domain accepts no mail.

How to check your own domain

1. Run your domain through the Domain Statistics lookup and look at the email records.
2. Check you have exactly one v=spf1 record. Count its include, a, mx, exists and redirect terms, including those inside each include.
3. Check that _dmarc.yourdomain exists and that rua= points to a mailbox someone actually reads.
4. Send yourself a message and look at its full headers for SPF, DKIM and DMARC results.

For record syntax, see DNS records explained. Requirements above are as published by Google, Yahoo and the NCSC in October 2026.