SPF, DKIM and DMARC checker

Read all three of a domain's email authentication records in one go, as receivers read them.

Check

SPF names servers, DKIM signs messages, DMARC decides

A receiver reads three records before it decides whether a message claiming your domain reaches the inbox, lands in the spam folder, or comes back as a bounce. SPF names servers: your record lists the hosts allowed to put your domain in the envelope sender, and the receiver checks the connecting IP against that list. DKIM signs messages: your sending platform signs each one with a private key, and the receiver fetches the matching public key from your DNS to confirm the signed headers and body arrived unchanged. DMARC runs no check of its own. It reads those two results, tells receivers what to do when neither one backs the address in the From line, and asks them for a summary of what they saw.

Record	Where it lives in DNS	What it settles	What failing it costs on its own
SPF	TXT on the domain itself, example.com	Whether the connecting server is on the list you published	DMARC still passes if DKIM passes and aligns, but a receiver may act on a hard fail before the receiver gets that far
DKIM	TXT at selector._domainkey.example.com	Whether a domain signed the message, and whether the signed headers and body arrived unchanged	DMARC still passes if SPF passes and aligns, but the message loses the check that survives a forward
DMARC	TXT at _dmarc.example.com	Which policy receivers apply when neither check aligns, and where the reports go	Receivers fall back on their own filtering, and no report comes back naming the senders that failed

The checker above reads all three in one submit. Our DMARC checker, SPF checker and DKIM checker go deeper on one record at a time.

Do I need all three? Yes. DMARC passes on one aligned result, so two records can look like enough. But SPF fails whenever a forwarder relays your message without rewriting the envelope sender, and DKIM breaks when a mailing list edits the subject or appends a footer to the body. Publish both, and one can break without the message failing DMARC. Google's sender guidelines require SPF and DKIM together from any domain sending 5,000 or more messages a day to Gmail accounts, plus a DMARC record at p=none or stricter.

Alignment joins the three records

A domain can hold a valid record of each kind and still fail DMARC on every message one platform sends. A message passes DMARC only when SPF or DKIM passes and the domain that passed matches the domain in the From line. DMARC calls that match identifier alignment. The receiver checks SPF against the envelope sender, the address in the SMTP MAIL FROM command, which never appears in a mail client. It checks DKIM against the d= value inside the signature.

So an invoicing app can bounce to its own domain and sign with its own d=. The app passes both checks under its own name rather than yours, so every message it sends fails DMARC. At p=reject receivers refuse every message that fails alignment. That includes the forgeries, and it includes the invoices from the platform you did not recheck. The alignment guide covers the platform settings that make its mail bounce and sign as your domain.

DMARC first when a check comes back flagged

DMARC decides what the other two results mean, so read it first, then SPF, then DKIM. Until you publish a policy and a rua= tag, receivers apply their own judgment to mail that fails DMARC, and you are working from bounces. The DMARC setup guide covers the ramp from p=none to p=reject and the numbers to check before each step.

Does p=none stop spoofing? No. At p=none receivers deliver failing mail as they would have anyway, and the reports the record asks for are the reason to publish it. p=quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder, and p=reject asks them to refuse it. You move to those once the reports show that your own senders align.

Take SPF next. Look for a syntax error, then for a second v=spf1 record on the same name, then count the lookups. Under RFC 7208 a receiver spends one budget of 10 DNS-querying terms on the whole evaluation, including everything nested inside every include. A chain that runs past that budget returns permerror, and a permerror can never give DMARC an aligned SPF result. One include too many costs you the SPF result on every message the domain sends. DKIM then has to carry alignment on its own. The 10-lookup guide walks a long chain back under the cap.

Can I publish two SPF records? No. RFC 7208 says a domain must not carry more than one v=spf1 record, and a receiver that finds two returns permerror instead of reading either. Merge every mechanism into a single record.

DKIM comes last. A selector that does not answer means whoever set the platform up never published its key, or published it under a different host name. Leave the selector field blank and the checker tries the common names. The DKIM settings page inside your sending platform names the selector your mail really uses. If a bounce is already in your log, the error index has a page for each rejection string.

A DNS lookup cannot tell you which of your own senders follow the rules you published, and that is the answer to have before you move the policy past p=none.

The other tools