DMARC, SPF and DKIM Checker

Enter a domain to see whether anyone can send email pretending to be it. Most domains publish records that look reassuring and enforce nothing — a DMARC policy of p=none tells receiving servers to watch spoofed mail go through, not to stop it. This check reads the actual DNS records and tells you which of those two situations you are in.

Lookups run over DNS-over-HTTPS from your browser. Nothing is sent to our servers and nothing is stored. No email is sent to the domain.

What this checks

Three separate records have to line up before a receiving mail server will trust that a message really came from your domain. They are usually explained in the wrong order, so here they are in the order they actually matter.

Record	Question it answers	Where it lives
SPF	Which servers are allowed to send mail for this domain?	`example.com` TXT
DKIM	Was this message signed with a key the domain published?	`selector._domainkey.example.com` TXT
DMARC	What should a receiver do when SPF and DKIM don’t line up?	`_dmarc.example.com` TXT

DMARC is the one that does the work. SPF and DKIM on their own produce a result that receiving servers are free to ignore, and most will, because rejecting mail is risky and nobody wants to bounce a real invoice. DMARC is the domain owner saying out loud: if this fails, here is what I want you to do about it.

How to read the result

DMARC policy

The p= tag is the whole ballgame:

Policy	What receivers are told	Real-world effect
`none`	Deliver it anyway, but send me reports	No protection. Spoofed mail reaches inboxes.
`quarantine`	Treat failures as suspicious	Spoofed mail usually lands in spam, not the inbox.
`reject`	Refuse the message outright	Spoofed mail is never delivered.
no record	Nothing — no instruction exists	Same as `none`, with no reporting either.

The trap is p=none. It is the correct place to start — you publish it, collect reports for a few weeks, find out which of your own systems are failing, fix them, and then tighten the policy. It is not a place to stay. A domain that has sat at p=none for three years is a domain whose owner set it up once and never came back, and it is exactly as spoofable as one with no record at all.

The SPF “all” mechanism

An SPF record ends with an instruction about everything not already listed:

-all — hard fail. Anything else is not us.
~all — soft fail. Anything else is probably not us, but accept it anyway.
?all — neutral. No opinion, which is the same as no record.
+all — pass. Anyone in the world may send as this domain. Always a mistake.

With DMARC at reject, the difference between -all and ~all matters much less than people think, because DMARC overrides the softness. Without DMARC, ~all is close to meaningless.

The ten-lookup limit

SPF allows a maximum of ten DNS lookups while evaluating a record. Each include:, a, mx, ptr, exists: and redirect= counts, and includes are recursive — one include: for a large provider can spend four or five on its own. Go over the limit and the result is a permanent error, which most receivers treat as no SPF at all. This check counts the mechanisms in your own record; it cannot count what your providers’ records spend inside their own includes, so a record showing 7 here can still be over in practice.

What this check can’t tell you

Whether DKIM is actually being used. DKIM selectors cannot be enumerated from DNS — you can only ask about a name you already know. This tool probes a list of selectors used by the common providers. Finding none does not mean the domain has no DKIM; it means it isn’t using a name we guessed.
Whether your real mail passes. These are published records, not a delivery test. A domain can have flawless DNS and still send mail that fails alignment. To check an actual message, use the Email Header Analyzer.
What your DMARC reports say. The rua= address receives daily XML from receiving servers describing who is sending as you. That data goes to the domain owner, not to us.
Recent changes. DNS answers come from a public resolver and may be cached for as long as the record’s TTL. A change made minutes ago may not appear yet.
Subdomains. Unless an sp= tag says otherwise, subdomains inherit the parent policy — but a subdomain can publish its own DMARC record that overrides it. This checks the exact name you typed.

A domain that sends no mail still needs these records. Parked domains, brand-protection registrations and internal-only names are attractive precisely because nobody is watching them. The fix is a one-line SPF of v=spf1 -all and a DMARC of v=DMARC1; p=reject; — that says plainly that no server on earth is authorised to send as this name.

Common fixes

You have no DMARC record

Add a TXT record at _dmarc.yourdomain.com containing v=DMARC1; p=none; rua=mailto:you@yourdomain.com;. Leave it for two to four weeks and read the reports. They will show senders you had forgotten about — a newsletter tool, an old ticketing system, the accounting software. Fix those, then move to p=quarantine, then p=reject.

You have been at p=none for a year

Go to p=quarantine with pct=25, which applies the policy to a quarter of failing mail. If nothing breaks in a fortnight, raise it. This is the whole migration: it is designed to be done in increments precisely so that one forgotten sender doesn’t take down your invoicing.

Your SPF record is over the lookup limit

Remove providers you no longer use — that is almost always the cause. Flattening the record (replacing include: with the IP ranges it resolves to) works but creates a maintenance problem, because the provider will change those ranges without telling you.

There are two SPF records

Merge them into one. Two v=spf1 records on the same name is a permanent error under the specification, and receivers will treat the domain as having no SPF at all. It usually happens when a second provider is onboarded and adds its own record instead of editing yours.

Check a real message next

DNS records tell you what the domain claims. Headers tell you what actually happened to one particular email.

Email Header Analyzer DNS Checker

Frequently asked questions

Does a DMARC record stop people spoofing my display name?

No. DMARC protects the domain in the envelope and the From header. It does nothing about a message sent from random@gmail.com with the display name set to your company. That is the most common form of business email compromise, and no DNS record prevents it.

Will p=reject break my mailing lists?

It can. Mailing lists that modify a message — adding a footer, rewriting the subject — break the DKIM signature, and if the list forwards without rewriting the From address, the result fails DMARC. Most serious list software handles this now by rewriting the sender. Roll out with pct= so you find out gradually rather than all at once.

Is SPF alone enough?

No. SPF breaks on forwarding — when a message is forwarded, the sending server is the forwarder, which your record doesn’t list. DKIM survives forwarding because the signature travels with the message. That is why DMARC accepts either one passing, as long as it aligns with the From domain.

What does alignment mean?

SPF and DKIM can pass for a domain that isn’t the one the recipient sees. Alignment requires the passing domain to match the From header. Relaxed alignment (r, the default) accepts a subdomain; strict (s) requires an exact match. This is the detail that makes DMARC meaningful — without it, a spammer could pass SPF for their own domain and still display yours.

Do I need DKIM if I have SPF and DMARC?

In practice yes, because of the forwarding problem above. A domain relying on SPF alone will see legitimate forwarded mail fail once DMARC moves to enforcement.