SPF, DMARC and DKIM record checker

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector._domainkey.example.com
nslookup -type=TXT _dmarc.example.com

v=spf1 include:_spf.example.net include:mail.example.org ip4:192.0.2.10 ~all

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyhGFRPyY5LYMiS0I676OOAWxWqSTwRz7qOHjCyxTlWGK9uio/MHJ5qCZx0xuxJkF66wcER6zoF20BzLhtZqE7Z8l6lYaj8YcVOO2qNDg53exJVRrW/z5OdNyWFcT2l704I+b7AFZZ9yET+ZDFyAI5I8SDCqsjEZUbZDlE1RbAdwIDAQAB

What the three records do

Email was designed without any way to prove who sent a message. These three DNS records, all published as TXT records, add that proof in layers:

• SPF (RFC 7208), at the domain itself, lists the servers allowed to send mail using this domain in the envelope sender (the bounce address).
• DKIM (RFC 6376), at selector._domainkey.domain, publishes a public key. The sending server signs each message with the matching private key, and receivers check the signature.
• DMARC (RFC 7489), at _dmarc.domain, ties the two to the address people actually see in the From line, tells receivers what to do with mail that fails, and asks them to send reports.

The link between them is alignment. A message passes DMARC if SPF passes for a domain that matches the From domain, or a DKIM signature verifies for a domain that matches it. With the default relaxed alignment, a subdomain counts as a match (mail.example.com aligns with example.com); with aspf=s or adkim=s it must be identical.

How each record is checked

SPF

Every term is parsed as a mechanism (ip4, ip6, a, mx, include, exists, ptr, all) with an optional qualifier (+ pass, - fail, ~ softfail, ? neutral), or as a modifier (redirect=, exp=). Anything else is a syntax error, and RFC 7208 treats a syntax error as a permanent error, which fails SPF for all mail. Receivers stop at the first mechanism that matches, so anything after all is dead.

The 10-lookup limit (RFC 7208 section 4.6.4) is the most common real-world failure. include, a, mx, ptr, exists and redirect each cost one DNS lookup, and so does every such term inside every included record. This tool counts the terms in the record you paste, but it cannot fetch the included records, so a total under 10 here is a lower bound. Paste each included domain's record as well to add them up.

DMARC

The record must start with v=DMARC1 and must have a p= policy. The checker explains each tag, flags invalid values, and warns when there is no rua address, because without aggregate reports there is no way to see which services send as your domain before tightening the policy.

DKIM

The public key in p= is decoded as a DER SubjectPublicKeyInfo, the same structure a certificate uses, to measure the key. RFC 8301 (2018) says verifiers must not accept RSA keys under 1024 bits and signers should use at least 2048. An empty p= means the key has been revoked on purpose.

A worked example

The three example records above are what many small businesses end up with:

• The SPF record includes two sending services and one fixed address and ends in ~all. It passes syntax, with two lookups visible here, but each include pulls in more lookups that must also be counted, and one provider's include can cost several lookups on its own.
• The DMARC record is p=none with an rua address. That is the correct first step, not a finished setup: failing mail is still delivered. After a few weeks of reports show every legitimate source passing, move to p=quarantine and then p=reject.
• The DKIM key is 1024-bit RSA. It still verifies everywhere, but should be rotated to 2048 bits: publish a new selector with the new key, switch the sending service to it, and remove the old selector once mail signed with it has stopped arriving.

A sensible order for setting this up

1. List every service that sends mail as your domain: mailbox provider, website contact forms, newsletter platform, invoicing, helpdesk.
2. Publish one SPF record covering them all, ending in ~all.
3. Turn on DKIM signing in each service and publish each selector it gives you.
4. Publish DMARC with p=none and an rua address, and read the reports.
5. Move to quarantine, then reject, once everything legitimate passes.

What this checker cannot see

It reads records you paste and cannot query DNS, so it cannot follow include or redirect, confirm that a record is really published at the right name, or check that a report address on another domain has authorised your reports. It also checks the records alone, not real messages: a DKIM key can be perfect while the sending service is not actually signing with it. To check a live message, look at the Authentication-Results header of an email you have received from the domain.