This tool runs on the server.
How it works
The email protocol does not verify who is sending: any server can put your domain in the sender. Three DNS records close that door. SPF lists which servers may send on behalf of the domain. DKIM signs each message with a private key whose public half is published in DNS. DMARC ties the two together: it requires at least one of them to pass and match the visible sender domain, tells the receiver what to do with failures and asks for reports on everything sent in your name.
Since February 2024, Gmail and Yahoo require SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day to their users, and missing any of them means rejected email or the spam folder. That is why it pays to check all three together: a flawless SPF does little without DMARC, and a DMARC set to reject with a badly published DKIM locks out your own mail.
The check runs from our server using public DNS queries, just as any mail server would. SPF is evaluated in full, following every include and redirect to count the DNS lookups, because going over the limit of 10 voids the whole record. The MX records and the optional MTA-STS, TLS-RPT and BIMI records are also queried.
Examples
github.comSPF · 10 / 10Eight provider includes (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) and the ones they include bring the evaluation right to the limit of 10 DNS lookups. One more provider and the whole SPF would return a permanent error.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sThe right setup for a domain that neither sends nor receives email: null MX, an SPF that authorises nobody and DMARC set to reject. It protects parked domains, a common target for spoofing.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %A gradual rollout: only one in four failing messages goes to spam, and reports arrive at the rua mailbox so you can spot legitimate senders that are not authenticated yet.Use cases
- Diagnose why the domain's emails land in spam or are rejected by Gmail, Outlook or Yahoo.
- Make sure SPF stays under 10 DNS lookups before adding a new sending provider, such as a CRM or a newsletter platform.
- Check that a provider's DKIM key was published correctly after setting it up.
- Plan the move of DMARC from none to quarantine and to reject without cutting off legitimate email.
- Audit the domains of a client or an acquired company, including parked ones that should not send email.
- Review a suspicious sender's setup while analysing a phishing attempt.
Frequently asked questions
Why does it say no DKIM was found if my domain signs its email?
Because DKIM does not let you list a domain's keys: each one lives at <selector>._domainkey.<domain> and you need the selector to look it up. The tool tries the most common selectors, but many providers use their own names or dated ones. Open an email sent from the domain, find the DKIM-Signature header and copy the value of s=; with that selector the check is exact.
What happens if SPF exceeds 10 DNS lookups?
RFC 7208 requires the receiver to return a permanent error (permerror), and for DMARC that counts as SPF failing. Lookups are consumed by the include, a, mx, ptr and exists mechanisms and the redirect modifier, including those inside each include; ip4 and ip6 do not consume any. To bring the number down, remove providers you no longer use, replace includes with ip4 ranges or send from subdomains with their own SPF.
~all or -all?
With DMARC in place the difference is small: the receiver applies the DMARC policy, not the SPF qualifier. ~all is the norm because some receivers reject straight away on -all before evaluating DKIM, which can lose forwarded email that DKIM would have saved. Without DMARC, -all is the only way to ask for unauthorised mail to be rejected.
How do I move DMARC from none to reject without losing email?
Start at p=none with an address in rua and read the aggregate reports for a few weeks: they show every server sending with your domain and whether it passes SPF or DKIM. Authenticate the legitimate senders that are missing, move to quarantine with a low pct, raise pct gradually and finish at reject. Jumping straight to reject tends to lock out invoicing systems, CRMs or internal tools nobody remembered.
Is a 1024-bit DKIM key enough?
It works, because RFC 8301 requires receivers to accept keys from 1024 to 4096 bits, but the same standard recommends that signers use at least 2048. Keys below 1024 are not considered valid. Rotating to 2048 is simple: publish the new key under another selector, switch the signing and then revoke the old one by leaving p empty.
What are MTA-STS, TLS-RPT and BIMI for?
MTA-STS (RFC 8461) asks sending servers to require TLS when delivering to your MX, which prevents attacks that downgrade the connection to plain text. TLS-RPT (RFC 8460) sends you reports when those deliveries fail. BIMI shows the brand logo next to the sender in clients that support it, and only works with DMARC at quarantine or reject. None of them is mandatory, but all three help.