LJILucas J Israel
05Tools — Email authentication audit

Your DNS records parse. Do they pass?

Enter a sending domain. This reads its public DNS and grades it against the bulk-sender rules Gmail and Yahoo now enforce — with every fix written in plain English.

No email sent  ·  No signup  ·  Everything runs in your browser

optional — leave blank to auto-probe ~50 common providers, or enter your exact selector
Reads public DNS only. DKIM is selector-specific — leave the selector blank to auto-detect across the major sending platforms, or enter your exact selector for a precise check.
The five records that decide it
SPF
Which servers are allowed to send mail for your domain.
DKIM
A cryptographic signature proving the mail wasn’t altered in transit.
DMARC
What inbox providers should do with mail that fails the checks above.
BIMI
Your verified logo shown beside your name in the inbox.Optional
MTA-STS
Forces inbound mail to your domain over an encrypted TLS connection.Optional
06Field notes — what the audit catches

Five ways a domain quietly loses the inbox.

Real verdicts this tool returns, and the delivery problem each one causes if it goes unfixed.

SPFFailing01 / 05
(no v=spf1 record published)
The issue

No SPF record found. Receiving servers have no list of who may send for this domain, so nothing legitimate can prove it belongs.

If left unfixed

Anyone can send as your domain, and your real bulk mail has no baseline to align to. Gmail and Yahoo throttle or spam it the moment you send at volume.

SPF · 12 / 10 lookupsFailing02 / 05
v=spf1 include:_spf.a.com include:_spf.b.com include:mail.c.net include:relay.d.io ~all
The issue

The include chain crosses the 10-DNS-lookup limit (RFC 7208). SPF returns a PermError and fails authentication for every message from the domain.

If left unfixed

Every message from every platform fails SPF silently, with no inbox-side notice. Add one more sending tool and healthy mail starts getting filtered overnight.

DKIM · selectorNeeds work03 / 05
google._domainkey.yourdomain.com → no key (DKIM is selector-specific)
The issue

No DKIM key at the selector checked. DKIM is selector-specific, so a healthy domain can look broken if the wrong selector is audited. The real one lives in the s= value of a sent message's headers.

If left unfixed

Without a signing selector, forwarded mail can't stay aligned, and at DMARC enforcement it gets rejected. It's also the most misread result on any checker.

DMARC · p=noneNeeds work04 / 05
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
The issue

Policy is p=none: monitoring only. Records are read but failures are never acted on, which falls short of the Gmail and Yahoo bulk-sender enforcement minimum.

If left unfixed

Anyone can spoof your domain and DMARC won't stop it, and you fail the bulk-sender requirement. Move to p=quarantine once your legitimate mail aligns.

BIMI · MTA-STSOptional05 / 05
(no v=BIMI1 / v=STSv1 record; never affects your grade)
The issue

The optional hardening layer isn't present. Absence never lowers your grade, but presence signals a mature, deliberately configured sender.

Worth doing once core is enforced

BIMI puts your verified logo beside your name in the inbox; MTA-STS forces inbound mail over encrypted TLS. Layer them on after SPF, DKIM, and DMARC are at enforcement.

Seen at enterprise scale on a 1.8M-contact regulated sender  →  read the case study