Apprendre
SPF, DKIM and DMARC: The Three DNS Records Email Authentication Needs
Three records answer three different questions: who may send, whether the message was altered, and what to do when the answers disagree. Publishing one without the others leaves the job half done.
Lancez un audit DomainLens frais et utilisez le rapport comme liste de priorités.
What each record actually proves
They stack. SPF and DKIM each produce a verdict; DMARC decides what that verdict means and tells receivers what to do about it. Without DMARC the first two are advisory and largely ignored.
| Record | Question it answers | Lives at |
|---|---|---|
| SPF | Is this server allowed to send for this domain? | A TXT record at the domain apex |
| DKIM | Was this message altered after signing? | A TXT record at selector._domainkey |
| DMARC | What should a receiver do when SPF or DKIM fails? | A TXT record at _dmarc |
SPF: exactly one record, under ten lookups
SPF lists the servers permitted to send mail as your domain. Two rules cause most failures: there may be exactly one SPF record per domain, and evaluating it must not require more than ten DNS lookups.
- Each include, a, mx or redirect costs a lookup; exceeding ten makes the whole record fail as permerror.
- Start with ~all (softfail) and move to -all only after DMARC reports confirm nothing legitimate is failing.
- SPF checks the envelope sender, not the From: header a reader sees — which is exactly the gap DMARC closes.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
; v=spf1 version, always first
; include: delegate to another domain's SPF (1 lookup each)
; ~all softfail everything else (recommended start)
; -all hard fail — only once you are certain
; WRONG — two SPF records invalidate each other:
; example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
; example.com. IN TXT "v=spf1 include:sendgrid.net ~all"
; Merge them into one instead.DKIM: a signature and its public key
DKIM signs outgoing mail with a private key held by your mail provider and publishes the matching public key in DNS. A receiver verifies the signature and learns that the message was not altered in transit and genuinely came from a system holding that key.
The record lives at a selector you choose, under _domainkey. Providers generate the key and hand you the record to publish; rotating keys means publishing a new selector and switching to it rather than editing the old one.
s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
; s1 the selector — your provider chooses it
; _domainkey fixed label required by the spec
; p= the public key, often split across strings
; because a single TXT string caps at 255 charsDMARC: the policy that ties it together
DMARC does two things. It requires alignment — the domain SPF or DKIM validated must match the domain in the visible From: header — and it states what receivers should do when nothing aligns.
Deploy it in stages. Start at p=none, which changes nothing but sends you reports, and read those reports until you can account for every sending source. Only then move to quarantine, and finally to reject.
; Stage 1 — monitor only, no delivery impact
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
; Stage 2 — failing mail goes to spam
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
; Stage 3 — failing mail is rejected outright
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Does any of this affect SEO?
Not directly. Google does not read your mail authentication when ranking pages, and no amount of DMARC will move a position. The connection is indirect but real: a domain whose mail is spoofed accumulates abuse reports and reputation damage that is unpleasant to unwind, and outreach or notification mail that lands in spam undermines everything that depends on it. Treat these records as domain hygiene alongside DNS record types rather than as a ranking tactic.
How DomainLens contributes
DomainLens reports whether SPF and DMARC records are present for the domains it audits, so a missing policy surfaces in the same pass as the on-page findings. To see the current records for any domain, use the DNS checker .
- Can I have two SPF records?
- No. Exactly one SPF record is permitted per domain, and publishing two makes both invalid. Merge every sender into a single record.
- Do I need DKIM if I already have SPF?
- Yes, in practice. SPF breaks when mail is forwarded, because the forwarding server is not on your list. DKIM survives forwarding, so the two together cover cases neither handles alone.
- What does p=none actually do?
- Nothing to delivery. It asks receivers to treat failing mail normally while sending you aggregate reports, which is exactly what you want while discovering your own sending sources.
- Where does the DMARC record go?
- On the _dmarc subdomain as a TXT record — _dmarc.example.com, not the apex. Putting it at the apex is a common and silent mistake.