SPF, DKIM and DMARC: what they are, how to set them up and why your domain needs them

SPF, DKIM and DMARC are three DNS records that let a receiving mail server check that a message claiming to come from your domain really does. SPF lists the authorised servers, DKIM signs each message, and DMARC says what to do with mail that fails both checks and sends you reports. Without them, anyone can spoof your domain.

To check it on your own site: SEO audit

They are not a ranking factor, but they belong to the security and trust part of SEO: they protect the brand your search work is building.

What does email have to do with your website?

More than it seems. Google's sender guidelines recommend always setting up email authentication for the domain that hosts your public website1. There are two practical reasons:

• Spoofing. If your domain publishes no DMARC record, a fraudster can send mail with your address as the sender and there is no policy asking receivers to reject it. Your customers see your name, not theirs.
• Deliverability. Contact form notifications, invoices, password resets and newsletters all go out under your domain. Gmail says unauthenticated messages may be marked as spam or rejected1.

What they do not do is improve your rankings: no Google documentation lists them as a search signal.

SPF: which servers may send on your behalf

SPF (Sender Policy Framework) is a TXT record at the root of the domain that lists the servers authorised to send mail with it. Receivers check it against the envelope domain (the Return-Path), not the sender the reader sees2. An example for a domain that sends through its mailbox provider and a newsletter tool:

; TXT record on example.com (the provider names are illustrative)
example.com.  IN TXT  "v=spf1 include:_spf.mail-provider.example include:send.newsletter.example -all"
;  v=spf1        -> version; without it the record is ignored
;  include:...   -> authorises the servers each provider publishes (each include counts as a lookup)
;  -all          -> everything else fails; ~all would mean "probably not authorised" (softfail)

Two rules are broken all the time. A domain can only have one SPF record: with two, the check returns a permanent error2. And every new tool that sends mail (the CRM, the shop, the invoicing platform) has to go into that single record.

The 10 DNS lookup limit

SPF caps at 10 the mechanisms that require a DNS query during evaluation: include, a, mx, ptr, exists and the redirect modifier. Go over it and the result is permerror, which means the SPF stops working. Lookups that come back empty (void lookups) should be limited to two2.

The limit counts nested includes: if your provider's record includes three others, you have spent four. To stay under it, delete providers you no longer use, avoid ptr and replace a and mx with ip4: or ip6: ranges when you know the addresses, because those do not count.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each email, which the receiver verifies against a public key published in DNS. The key lives at a name of the form selector._domainkey.example.com, and the signer chooses the selector: there can be several at once, one per provider or per period3.

; Public DKIM key for the selector "s2026" (a real key is much longer)
s2026._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

Google requires keys of at least 1,024 bits to send to personal Gmail accounts and recommends 2,048 if your provider supports it1. In practice, each service that sends for you gives you the record to publish.

Why DKIM cannot be checked from the outside

To read a DKIM key you need its selector, and the selector only appears in a message's signature (the s= tag of the DKIM-Signature header). DNS does not list the names under _domainkey, so without one of your emails in hand nobody can tell whether you have DKIM or which selector you use. That is why tools that analyse a website from the outside check SPF and DMARC, which live at fixed names, and not DKIM.

DMARC: the policy and the reports

DMARC is a TXT record at _dmarc.example.com that tells receivers what to do with mail that fails validation and where to send reports. In May 2026 the IETF published the new specification, RFC 9989, which replaces RFC 74894.

; TXT record on _dmarc.example.com
_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
;  p=none     -> observe only: asks for no particular handling of failures
;  rua=...    -> mailbox that receives the aggregate reports
;  adkim/aspf -> alignment; relaxed (r) unless stated otherwise
;  sp / np    -> policy for subdomains and for non-existent subdomains

Alignment: the condition that fails most

A message passes DMARC if it passes SPF or DKIM and the validated domain matches the visible sender (the From: header). In relaxed mode, the default, it is enough for them to share the organisational domain: mail.example.com aligns with example.com; in strict mode they must be identical4.

The typical failure: a newsletter tool sends with its own domain in the envelope and signs with its own key. SPF and DKIM pass, but for the provider's domain, not yours, and DMARC fails. The fix is to set up your own sending domain and your own DKIM signature in the tool.

From p=none to quarantine and reject

The RFC explains why you start at p=none: in almost any organisation some server or provider sending on its behalf gets overlooked, and the reports are there to find them before the policy bites4. But p=none does not protect against spoofing: it is a phase, not a destination. The old pct tag, which applied the policy to a percentage of messages, is gone in RFC 9989; to test a policy you now use t=y, which asks receivers to apply one level less4.

rua reports

Receivers that send aggregate reports should do so at least once every 24 hours4. They arrive as XML and tell you how many messages with your domain they saw, from which IPs, and whether they passed SPF, DKIM and alignment. They are meant to be read by software, so most people use a service that summarises them. They show both your own misconfigured mail streams and spoofing attempts.

What do Gmail, Yahoo and Outlook require?

Microsoft first announced it would send that mail to the Junk folder and, before the deadline, changed course and decided to reject it instead6. If you send far fewer than 5,000 emails a day, the bulk sender rules do not bind you, although Gmail does ask every sender for SPF or DKIM, and meeting the rest still helps delivery.

Why protect a domain that never sends email?

Because it is the easiest one to spoof. If a domain has no SPF or DMARC, nothing tells receivers that mail claiming to come from it is fake. This applies to parked domains, old campaign domains and the variants you bought to protect your brand. UK government guidance recommends publishing four records like these on them7:

; A domain that never sends email
example.org.                    IN TXT  "v=spf1 -all"
;  -> no server is authorised
_dmarc.example.org.             IN TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"
;  -> reject anything claiming to come from the domain or its subdomains
*._domainkey.example.org.       IN TXT  "v=DKIM1; p="
;  -> empty DKIM key: no signature is valid
example.org.                    IN MX   0 .
;  -> "null MX": the domain accepts no mail

How to check your records

From the terminal, with dig (replace example.com with your domain):

# SPF: look for a single line starting with v=spf1
dig +short TXT example.com

# DMARC: look for v=DMARC1 and check the value of p=
dig +short TXT _dmarc.example.com

# DKIM: only if you know the selector (find it in the s= tag of one of your emails)
dig +short TXT s2026._domainkey.example.com

Disclosure: this blog belongs to SmoothSeen. In the security and trust category of its SEO analysis, SmoothSeen checks whether your domain publishes SPF and DMARC, and warns you if DMARC has been left at p=none. It does not check DKIM, for the selector reason explained above. The same category reviews your HTTP security headers and whether the site is served over HTTPS without mixed content, which is covered in the guide to HTTPS and SEO.

Frequently asked questions

Do I need DMARC if my business only sends everyday email, no newsletters?

Yes. The strictest rules from Gmail, Yahoo and Outlook apply to bulk senders, but DMARC protects any domain from spoofing, and that has nothing to do with how much you send. Everyday email also gets delivered more reliably when it is authenticated. Start with p=none and a reports mailbox, and tighten the policy once you know who sends on your behalf.

Which is better in SPF, ~all or -all?

-all declares that any server not listed fails; ~all (softfail) only says it is probably not authorised. If you are not yet sure which services send on your behalf, ~all is the more cautious choice while you review your DMARC reports. On a domain that never sends email, use -all without hesitation, as UK government guidance recommends.

Does a DMARC record with p=none protect me from spoofing?

No. With p=none the domain owner expresses no preference about failing mail, so the receiver decides on its own. Its value lies in the reports, which tell you who is sending with your domain. It is the first step towards p=quarantine and p=reject, the policies that actually ask receivers to set aside or reject forged mail.

Does setting up SPF, DKIM and DMARC improve SEO?

There is no Google statement saying so, and you should not expect it. What they do is protect your brand: they stop someone using your domain to defraud your customers and they help your emails reach the inbox. That is trust, and trust is lost quickly when a forged email with your name on it starts circulating.

What to do next

Run the first two dig commands against your domain and against any domains you are not using. If DMARC is missing, publish one with p=none and a reports mailbox today, and put a reminder in your calendar to review it in a month. Then carry on with the rest of your site's security in the guide to what SEO is.