Free tool

Are your SPF, DKIM and DMARC set up right?

SPF, DKIM and DMARC read straight from your DNS zone and explained in plain English, not dumped as raw records for you to decipher.

Two problems for the price of one

Without these three records, anyone can send email that looks like it came from your domain — which is how most invoice fraud begins. It cuts the other way too. Your own legitimate mail starts landing in spam, because since 2024 Gmail and Yahoo expect proper authentication from any regular sender.

All three, one sentence each

SPF declares which servers may write in your name. DKIM signs each message so the recipient can tell it was not altered on the way. DMARC says what to do when both fail, and reports impersonation attempts back to you. All three live in DNS, as three records.

The decision

The path a message takes before it lands

SPF, DKIM and DMARC are not three independent checks. The first two produce a result, and the third decides what to do with it. Set the three switches and follow the path.

The three settings

SPF

Has your domain authorized the sending server?

DKIM

Does the signature hold, and does it carry your domain's name?

DMARC

What you want done with the messages that fail.

A message turns up claiming to come from your domain

Does either one pass, aligned with your domain?

yes

DeliveredThe message reaches the inbox.

What does your DMARC record ask for?

p=none

Delivered anywayYou asked for nothing, so the message gets through — but the failure shows up in the report sent back to you.

p=quarantine

Set asideThe message goes to the junk folder.

p=reject

RejectedThe receiving server refuses the message outright, and the sender gets a failure report.

One of the two passes and is aligned. DMARC is satisfied, and your policy never gets consulted. Delivered.

A message passes DMARC if SPF validates it while aligned, OR if DKIM validates it while aligned. Either one on its own is enough, which is exactly why both are worth setting up (RFC 7489).

What protects a domain

Three records. None by default.

A fresh domain has none of them. Anyone can write in its name, and recipients have nothing to doubt it with. All three go into the DNS, and they go in together.

SPFwho is allowed to send
DKIMthe signature that travels with the message
DMARCwhat to do with messages that fail

Reading the result

The check reads three records in your DNS zone and grades each one on its own. A flawless SPF with no DMARC still leaves the door open, and the reverse is just as true.

SPF present and correctly formed: One record, terms the standard recognizes, a closing all, and fewer than ten DNS lookups.
No SPF at all: Any server anywhere can write in your domain's name. We grade that serious when the domain receives mail, and worth watching when it does not.
More than one SPF record: The standard allows exactly one. Given two, the receiving server does not choose between them. It drops the whole check.
An SPF ending in +all: It authorizes the whole world to write in your name. That is no better than having no SPF, and arguably worse, because it looks like protection.
More than ten DNS lookups: The standard caps them at ten. Go past that and the check comes back as a permanent error, and it is your legitimate mail that pays.
An SPF ending in ~all: Unauthorized messages get accepted, then marked. This is the most common setting and a sound place to start, on the way to -all.
An SPF with no all, or ending in ?all: The record takes no position on senders it has not listed, so the recipient does nothing with it. The protection is zero.
An SPF that uses ptr: The standard discourages it as slow and unreliable, and several large providers ignore it outright. It burns a lookup for nothing.
DMARC on quarantine or reject: The policy is actually being applied. Messages impersonating your domain get set aside or refused. This is where you want to end up.
DMARC on p=none: The policy watches without blocking anything. A good first step, not a destination — and only worth anything if a reporting address is declared.
No DMARC, or an invalid policy: Without DMARC you will never find out that someone is impersonating your domain. And a policy that is neither none, quarantine nor reject does not get applied at all.
DKIM: no common selector found: A selector carries whatever name its provider picked for it. The tool tries twelve of the most common ones, so finding nothing here proves nothing.
No mail server declared: The domain does not receive mail. All three settings are still worth having — they stop anyone using your name to send some.

The mistakes we see most often

Two SPF records instead of one
What causes it: someone adds a sending provider and creates a second TXT record instead of extending the SPF already there. The check then fails outright.
What fixes it: merge the two into one v=spf1 record that gathers every include: in the same line.
The SPF goes past ten DNS lookups
What causes it: every include:, a, mx, exists and redirect= costs one lookup, and the include: entries your providers hand you carry more inside them.
What fixes it: swap the heaviest include: entries for the matching ip4: ranges, and drop the providers you stopped using.
A DMARC record set to observe, then forgotten
What causes it: starting on p=none is the right method. But with no rua address there are no reports to read, so the policy observes nothing and blocks nothing.
What fixes it: add rua=mailto:… pointing at a mailbox somebody actually reads, then move to quarantine.
The DMARC record is published in the wrong place
What causes it: DMARC belongs on the _dmarc subdomain, not on the domain itself. Sitting at the root, it never gets read.
What fixes it: create a TXT record on _dmarc.yourdomain, starting with v=DMARC1;.
The provider signs with its own domain
What causes it: DMARC wants SPF or DKIM aligned with the domain shown in the From field. Mail that sails through SPF at the provider can still fail the check.
What fixes it: turn on DKIM signing under your own domain with every sending provider you use.

The terms of an SPF record

An SPF record is a list of terms read left to right. First match wins.

Term	What it does	DNS lookup
v=spf1	Opens the record. Required, and always first.	No
ip4:	Authorizes an IPv4 address or a whole range.	No
ip6:	Authorizes an IPv6 address or a whole range.	No
a	Authorizes the domain's own addresses, or those of whichever domain you name.	Yes
mx	Authorizes the addresses of the domain's mail servers.	Yes
include:	Pulls in another domain's SPF, usually a sending provider's.	Yes
exists:	Authorizes when a name built on the fly resolves.	Yes
ptr	Tests the reverse name of the address. The standard discourages publishing it.	Yes
redirect=	Hands the whole evaluation over to another domain's SPF.	Yes
exp=	Points at the explanation text returned on refusal.	No
all	Always matches. It goes last, and it decides the fate of every unlisted sender.	No

Each term can carry a qualifier. Plus authorizes and is the default, minus refuses, tilde accepts then marks, question mark expresses no opinion. The standard caps the terms that trigger a DNS lookup at ten. Source: RFC 7208, §4.6.2, §4.6.4 and §5.

The tags of a DMARC record

Semicolon-separated tags, published as a TXT record on the _dmarc subdomain.

Tag	What it controls	Default
v	Version. It has to read DMARC1, and it has to come first.	Required
p	The policy you are asking for: none, quarantine or reject.	Required
sp	Policy applied to subdomains.	The value of p
rua	Where the daily aggregate reports get sent.	No reports
ruf	Where the detailed failure reports get sent.	No reports
pct	How much of the mail stream the policy applies to.	100
adkim	DKIM alignment: strict (s) or relaxed (r).	r
aspf	SPF alignment: strict (s) or relaxed (r).	r
fo	When a failure report gets produced at all.	0
ri	Interval between aggregate reports, in seconds.	86400
rf	Format of the failure reports.	afrf

Source: RFC 7489, §6.3. Three tags make a working record — v=DMARC1; p=none; rua=mailto:… — but drop the reporting address and the observation policy observes nothing.

Common questions

How do I check my SPF, DKIM and DMARC records?

Type the domain above. The tool queries your DNS zone, reads the SPF record, the DMARC record on _dmarc and the mail servers declared, then hunts for a DKIM signature across twelve widespread selectors. The answer comes back in plain language, not raw data.

What is the difference between SPF, DKIM and DMARC?

SPF declares which servers are allowed to write in your name. DKIM signs each message so tampering shows. DMARC tells the recipient what to do when both fail, and reports impersonation attempts back to you.

Should my SPF end in -all or ~all?

With ~all, unauthorized messages get accepted and marked. With -all, they get refused. Start on ~all, read the DMARC reports to catch the legitimate senders you forgot about, then move to -all. Jump straight to it and real mail vanishes.

Why is my DKIM not found?

Because a DKIM signature lives under a selector, and a selector carries whatever name its provider picked. No public tool can guess them all. This one tries twelve of the most common, and reports unknown rather than absent.

How long does a DNS change take to show up?

It depends on the lifetime declared on the record and on what resolvers are already holding in cache. A record published for the first time usually shows up within minutes. A record you changed takes at most the old value's lifetime to clear.

Do Gmail and Yahoo actually require DMARC?

Since February 2024, yes, for anyone sending in volume. Google draws the line at five thousand messages a day to its mailboxes, and above it asks for SPF, DKIM and DMARC, with a spam complaint rate under 0.30%. p=none satisfies that. Below the line, SPF or DKIM is still expected.

The three numbers that break an SPF

Ten, one, zero.

Real SPF records almost never fail on syntax. They fail on these three.

DNS lookups, not one more

The standard caps the terms that need a lookup at ten — include:, a, mx, exists:, ptr, redirect=. Past that the check fails outright, and one extra sending provider is all it takes to cross the line.

One SPF record per domain

Two v=spf1 records do not add up. The check fails. This is what happens when you follow a new service's instructions and leave the previous one's in place.

What a “p=none” DMARC prevents

none asks nothing of recipients. It watches, and it sends reports back. The right first step, and the wrong last one — which is where domains sit for years.

The ten-lookup limit and the one-SPF rule come from RFC 7208, the DMARC policies from RFC 7489 § 6.3. The two tables on this page take them apart term by term.

The vocabulary

Six signs that change the whole meaning

One character each, sitting in front of a term, deciding whether a message gets rejected or merely flagged.

+all: Authorizes the entire world to write in your name. Published by accident, it undoes the whole point of SPF.
-all: Rejects anything not on the list. The firm stance, and only safe once the list is complete.
~all: Accepts, then flags. The stance you hold while you read the reports.
?all: Expresses no opinion. The same as publishing nothing, except that it feels like you did something.
p=quarantine: Asks recipients to set failures aside instead of rejecting them.
rua=mailto:: Where the daily reports go. Without it, a DMARC in observation mode teaches nobody anything.

Are your SPF, DKIM and DMARC set up right?

Two problems for the price of one

All three, one sentence each

The path a message takes before it lands

Reading the result

The mistakes we see most often

Two SPF records instead of one

The SPF goes past ten DNS lookups

A DMARC record set to observe, then forgotten

The DMARC record is published in the wrong place

The provider signs with its own domain

The terms of an SPF record

The tags of a DMARC record

Common questions

Ten, one, zero.

Six signs that change the whole meaning

Twenty checks, no sign-up