DMARC, SPF & DKIM Checker

SPF is a list of servers allowed to send mail for a domain, published as a TXT record at the domain root. DKIM is a cryptographic signature on each message, verified against a public key published at selector._domainkey.domain. DMARC ties both to the visible From address: it requires SPF or DKIM to pass AND align with the From domain, tells receivers what to do on failure, and sends the domain owner reports. You need all three for reliable delivery: SPF and DKIM authenticate, DMARC enforces and reports.

Enter your domain in the checker above. It runs a DMARC record lookup on the TXT record at _dmarc.yourdomain.com and translates every tag into plain English: the p policy (none, quarantine or reject), the subdomain policy sp, the report addresses rua and ruf, the pct percentage and the adkim and aspf alignment modes. If no record exists, or two exist, it flags that too.

p=none is monitoring mode: receivers check alignment and send you aggregate reports, but failing mail is still delivered normally. It is the correct place to START a DMARC rollout, because reports show you every legitimate sender before you enforce anything. It is a weak place to STAY: with p=none, anyone can still spoof your domain and the mail goes through. The usual path is none, then quarantine, then reject.

RFC 7208 caps the number of DNS-querying terms in an SPF evaluation at 10: include, a, mx, ptr, exists and redirect all count, and includes count everything inside them recursively. Go over 10 and SPF returns permerror, which many receivers score like having no SPF at all. It happens quietly as you add vendors over the years. This SPF record checker resolves your includes recursively and shows the running total against the limit.

No. A domain must publish exactly one TXT record starting with v=spf1. Two or more is a permanent error under RFC 7208: receivers do not merge them, they treat SPF as broken. It usually happens when a second email vendor says "add our SPF record" and someone adds a new record instead of editing the existing one. The fix is to merge all include mechanisms into a single record, which this tool flags automatically.

Open any message sent from the domain and view its full headers: the DKIM-Signature header contains s=yourselector. If you cannot find a sent message, the auto-try in this DKIM checker covers the common ones: google for Google Workspace, selector1 and selector2 for Microsoft 365, k1 for Mailchimp, and generic names like default, mail, s1 and s2. Transactional providers list their selector in their DNS setup docs.

By default wp_mail() sends straight from the web server with no SMTP authentication. That server IP is almost never in your SPF record and nothing signs the mail with DKIM, so contact form messages and order confirmations fail email authentication and land in spam. The fix: send through an authenticated SMTP provider using an SMTP plugin, add that provider to your SPF record, publish its DKIM key, then add a DMARC record so you can see the results.