SPF, DKIM & DMARC checker
Paste a domain. Get the SPF chain expanded lookup by lookup against the 10-lookup limit, the DKIM selectors that actually exist, the DMARC policy in plain language — and a record you can paste straight into your DNS panel.
Runs in your browser against Cloudflare and Google DNS-over-HTTPS. Nothing is sent to this site's server, and nothing is stored.
Advanced — add a DKIM selector
Three records decide whether your invoices get read
Email authentication is the part of a payment flow nobody owns until it breaks. These are the failures that show up in support tickets rather than logs.
You added one more provider and crossed 10 DNS lookups. Receivers now return permerror and treat your domain as having no SPF at all. Nothing bounced, nothing logged — receipts just started landing in spam.
SPF breaks the moment a message is forwarded. DKIM is the signature that survives it. Without DKIM, a customer forwarding your invoice to their finance team turns it into a DMARC failure.
No DMARC record, or p=none forever, means a spoofed "updated bank details" email from your domain arrives looking exactly like yours — and you never find out it happened.
Straight answers
Does my domain data get sent to your server?
Why do you not check DNS blocklists like Spamhaus?
You said you found no DKIM key. Does that mean I have none?
What is the 10-lookup SPF limit, and why does it matter so much?
Can I just flatten my SPF record to fix the lookup limit?
Is p=none good enough for DMARC?
What does this have to do with payment integrations?
Still broken after the DNS is right?
Email authentication is DNS. Payment notifications not arriving is usually not — it is a webhook that failed signature verification, an event type you never subscribed to, or a status that never synced. That is what I fix: a fixed-fee $99 root-cause diagnosis, credited toward the repair.