Glossary

What are SPF / DKIM / DMARC: three DNS settings that protect your domain from spoofed email

SPF, DKIM, and DMARC are three DNS settings that let receivers verify whether mail from your domain is genuine. Without them, you can't stop phishing emails sent in your name. The role of each, a diagram of how mail is verified, and how to set them up safely (start DMARC at p=none) — explained plainly.

Published 2026-06-08 Updated 2026-10-06 7 min read

Phishing emails can go out in your domain's name without you knowing. SPF / DKIM / DMARC stop that. Here's the role of each and how to set them up safely.

The role of each

Setting	Role (in one line)
SPF	Declares in DNS which servers may send for this domain
DKIM	Adds a cryptographic signature proving the mail is unaltered and from a legitimate source
DMARC	Declares what to do if SPF/DKIM fail, and receives reports (the setting that ties the three together)

All three are text (TXT) records in DNS. For example.com they look like this (values are examples).

Setting	Where it goes	Example value
SPF	`example.com`	`v=spf1 include:_spf.mail-service.example ~all`
DKIM	`selector._domainkey.example.com`	`v=DKIM1; k=rsa; p=(public key issued by your sending service)`
DMARC	`_dmarc.example.com`	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`

For SPF's include:, use the value your mail-sending service tells you to. The DKIM public key is also issued by the sending service, so you don't create it yourself.

How mail gets verified

Receivers (Gmail, etc.) check SPF and DKIM on an incoming message, then apply your DMARC policy to decide "pass / quarantine / reject."

Incoming mail (in your domain's name)

↓ receiver verifies

SPF: is the sending server authorized?

DKIM: is the signature valid, untampered?

↓ match results against DMARC policy

DMARC: on failure → pass / quarantine / reject

The receiver checks SPF/DKIM, then the DMARC policy makes the call. All three are needed for it to work.

So SPF and DKIM alone may "check but do nothing"; only with a DMARC policy do they actually "stop spoofing."

The part people miss: domain alignment

The key to a DMARC verdict is that the domains line up. DMARC passes only when the domain of the sender the recipient sees in their mail app (the From header) matches a domain verified by SPF or DKIM.

SPF doesn't check the visible sender; it checks the domain of the behind-the-scenes envelope sender used for delivery. So an attacker can pass SPF with their own domain while writing your domain only in the From field. If SPF passes but doesn't match the From domain, and DKIM doesn't provide a match either, DMARC fails the message. Checking this match is exactly what lets DMARC stop From-address spoofing.

How to set them up safely

One correct SPF record

Authorize every legitimate sender (your own, mail services, etc.). Keep one SPF record per domain (multiple records tend to break it).

Enable DKIM signing

Turn on DKIM in your mail platform and publish the public key in DNS, so legitimate mail is signed.

Start DMARC at p=none

Don't reject immediately. Begin with p=none (monitor only) + reporting to confirm legitimate mail isn't dropped.

Tighten gradually

Once reports show no legitimate senders are missed, move p=quarantine → p=reject, finally reaching "spoofing is rejected."

"Exactly one" in step 1 comes from the spec. RFC 7208 says that if a domain has more than one SPF record, the result is permerror (a permanent error). The same spec limits DNS lookups from include and similar terms to 10 across the whole evaluation; going over is also permerror. When you add a mail service, append to the existing single record rather than adding another one.

Common mistakes

Mistake	What happens	Fix
Two SPF records	SPF returns permerror	Merge them into one
Too many nested `include`s	DNS lookups exceed 10 → permerror	Remove `include`s for services you don't use
DKIM not enabled at a sending service	Mail from that service fails DMARC	Enable DKIM in the service and publish it in DNS
DMARC left at p=none	Spoofed mail keeps getting through	Read the reports and raise to reject
Nothing set on a domain that sends no mail	Spoofing in that unused domain's name can't be stopped	Publish `v=spf1 -all` and DMARC `p=reject`

How to check your own domain

Enter your domain in the SPF / DKIM / DMARC checker to see whether the three records exist and what's wrong with them
To look directly from the command line, run dig +short TXT example.com (SPF) and dig +short TXT _dmarc.example.com (DMARC)
Send a message from your domain to a Gmail address and use Gmail's "Show original" to confirm SPF, DKIM and DMARC all say PASS
Once DMARC reports (rua) start arriving, check weekly for senders you don't recognize

For a site whose ownership you've verified, the site security audit checks these together with your web-side settings.

A real case: spoofed mail "from your own address"

"I got a threatening email from my own address to myself" is a typical case that Japan's IPA and others have warned about. Most of these aren't account takeovers; the sender field was simply rewritten. Because the sender can write anything in that field, such mail can reach the inbox for domains that haven't raised DMARC to reject. How to tell and what to do are covered here:

Spam from your own email address (confirm in five minutes whether you were hacked)
Spoofed mail using your own domain (reading headers, and stopping it with SPF, DKIM and DMARC)

Spec update (May 2026)

DMARC was revised in May 2026 as RFC 9989, which obsoletes the previous RFC 7489. The three policies — p=none, p=quarantine and p=reject — are unchanged. What changed: the pct tag (the percentage to apply) was removed and replaced by a t tag that signals test mode, and an np tag was added for the policy on non-existent subdomains. Existing records don't stop working overnight, but don't use pct when writing a new one.

This site's view: you're also protecting your users

SPF/DKIM/DMARC isn't only about your mail arriving; it also protects your users from phishing that impersonates your domain. Phishing is ultimately a way of stealing credentials and keys. Many domains stop at SPF/DKIM and never raise DMARC to enforcement (reject). Don't stop at p=none; read the reports and ramp all the way to reject for it to matter.

Sources (primary)

IETF RFC 7208, "Sender Policy Framework (SPF)" — datatracker.ietf.org (one record per domain; 10 DNS lookups max)
IETF RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures" — datatracker.ietf.org
IETF RFC 9989, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)" (May 2026; obsoletes RFC 7489) — datatracker.ietf.org
Google, "Email sender guidelines" — support.google.com (requirements from February 1, 2024; requirements for senders of 5,000+ messages a day)

Classification

CWE classifies the types of weakness behind vulnerabilities; MITRE ATT&CK classifies attacker techniques. Both are maintained by MITRE and widely used to label vulnerability reports and detection rules.

ATT&CK (attack technique)

T1684.002Social Engineering: Email Spoofing

© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ATT&CK Terms of Use

FAQ

QWhat are SPF / DKIM / DMARC for?

So receivers (Gmail, etc.) can verify whether mail from your domain is genuine. Without them, anyone can send spoofed phishing in your name unchecked, and your domain's reputation suffers.

QWhat's the difference between the three?

SPF declares 'which servers may send for this domain', DKIM is a 'cryptographic signature proving it wasn't tampered with', and DMARC is 'what to do if SPF/DKIM fail, plus reporting'. DMARC combines the SPF/DKIM results and makes them enforceable.

QWhat should I watch out for when configuring?

Authorize all legitimate senders (mail services, etc.) before tightening. Especially DMARC: jumping straight to reject can drop legitimate mail, so start at p=none (monitor only), read the reports, then move p=quarantine → p=reject.

QWhat does DMARC p=none mean?

It asks receivers for no special handling of mail that fails authentication. It doesn't stop spoofing, but you receive reports (rua) showing who is sending mail in your domain's name. Once you've confirmed every legitimate sender, raise it to p=quarantine (spam folder) and then p=reject (refused).

QWhat's the difference between '-all' and '~all' in SPF?

Both go at the end of an SPF record and say how to treat mail from servers not listed. -all means 'not authorized' (fail); ~all means 'probably not authorized' (softfail). With DMARC in place the final handling is decided by the DMARC policy, so starting with ~all until you've confirmed all legitimate senders is fine.

QWhat is SPF's 10 DNS lookup limit?

The SPF spec (RFC 7208) limits DNS lookups from include, a, mx, ptr, exists and the redirect modifier to 10 across the whole evaluation. Exceed it and the result is permerror (a permanent error), so SPF counts as failed. Listing several mail services with include makes this easy to hit; remove includes for services you no longer use.

QDoes Gmail require SPF, DKIM and DMARC?

Since February 1, 2024, Google requires everyone sending to personal Gmail accounts to set up SPF or DKIM. Senders of 5,000 or more messages a day must set up both SPF and DKIM, DMARC (a p=none policy is acceptable), and alignment between the From domain and the SPF or DKIM domain.