Email Auth Posture Checker

What email authentication posture actually means

An email authentication posture check reads the four records that decide whether your domain's mail is trusted, then grades them together. Nobody explains this part until it bites you. Gmail, Outlook, Yahoo, La Poste, OVH, basically every B2B gateway out there, they don't actually read your mail to decide where it lands. They check a handful of signals a machine can verify on its own, no human in the loop. SPF is the guest list of IPs allowed to send "from" your domain. DKIM signs each message with a private key and parks the matching public key in DNS, so the receiver can prove nobody fiddled with the message in transit. DMARC is the note you leave at the door: if SPF and DKIM both whiff, here's what to do (nothing, spam folder, or slam the door shut). And BIMI? That's the cherry, your verified logo sitting next to your name in the inboxes that bother to render it. Botch any of this and you're staring at spam folders, branding that got stripped off, maybe some stranger spoofing your domain to phish the very customers you're trying to reach.

So the tool yanks all four records out of DNS, reads each one, grades it against what counts as sane in 2026, and rolls the lot into a single posture score. No vendor agenda wired in. Nobody waiting to upsell you an audit at the bottom of the page. It's the same data Gmail and Microsoft are already squinting at when they decide whether your domain's mail is worth a damn.

How the checker queries SPF, DKIM, DMARC and BIMI

Under the hood it fires four DNS-over-HTTPS lookups at Google Public DNS all at once. Doing them one after another is just dead time, and nobody wants to watch a spinner. For SPF I grab the TXT record at the apex, throw away everything that isn't v=spf1, walk the include statements, count the DNS lookups against that infamous ceiling of ten, and flag the soft fails plus the genuinely scary pass-all policies. DMARC comes off the TXT at _dmarc.yourdomain: policy (none, quarantine, reject), the alignment modes, the reporting addresses, the percentage. BIMI sits at default._bimi.yourdomain, and if it's actually there I read off the SVG logo URL and, where there is one, the VMC certificate URL. DKIM's the awkward one. It's the single pillar you can't find without already knowing the selector, so I just chuck the twelve usual suspects at it (plus whatever you typed in the box), report which ones answered, and pull the key length off the first hit.

Common use cases for an email auth checker

• Pre-flight before a marketing campaign. The morning of a fifty-thousand-newsletter blast, I run it. Every single time, no exceptions. One record out of place and the whole send belly-flops into spam, and by then? Way too late to claw it back.
• Investigating "the partner's mail goes to spam". Stop arguing over email and just point this at their domain. Nine times in ten it's a DKIM key that was never set up, or an SPF so loose half the internet can send as them.
• Auditing a new acquisition. Some company gets folded into the group, and suddenly its email setup is fair game for the security review. A sloppy SPF, a weak DMARC, that's a wide-open door for anyone who fancies impersonating the brand you just bought.
• Preparing for the Gmail and Yahoo bulk-sender rules. Both have wanted valid SPF, DKIM and an actual DMARC from bulk senders since 2024. I lean on this to confirm I'm over the bar well before any cutoff bites.
• Enabling BIMI for brand recognition. Whatever you do, don't shell out for a Verified Mark Certificate until you've confirmed your DMARC is sitting at p=quarantine or p=reject. BIMI just ignores you otherwise. That's a few hundred euros down the drain for nothing.
• Switching mail provider. Cut-overs are where deliverability quietly goes to die. Once the move's done I run it to confirm the new SPF really does include the new vendor and the fresh DKIM keys are actually live.

Limitations and privacy notes

Let me be straight about the edges here. This reads public DNS and nothing else. It never fires off a test email, never pokes a mail server, and it forgets every domain you type the instant you close the tab. DKIM stays the irritating one, since it leans entirely on knowing your provider's selector, so if yours is off the beaten path, that's exactly what the custom field above is for. On SPF I count the top-level includes against the ten-lookup ceiling, but I'll admit I don't recurse down into nested includes, so a really hairy setup might still want a manual once-over. As for BIMI, all I'm claiming is that the record's there. Whether the logo genuinely renders, whether the VMC holds up, that's the receiving server's call. Not mine.

Frequently asked questions

Do I really need both SPF and DKIM?

Yeah. You really do. They're not doing the same job twice: SPF vouches for the IP that sent the thing, DKIM vouches for the message itself, and DMARC only passes when at least one of them clears with identifiers that line up. On top of that, Gmail and Yahoo have flat-out demanded both from bulk senders since 2024. So optional stopped being the word for it a while back.

What is a safe DMARC policy to start with?

Ease into it. Open with p=none and a rua address that actually works, so the reports have somewhere to land. Then sit with those aggregate reports for a week or two and figure out which legit senders are failing. Once that's sorted, climb to p=quarantine at 25%, push it to 100%, and only after all that go for p=reject. I've watched people slam reject on day one with zero monitoring and quietly torch their own invoices. Don't be that person, honestly.

Why does the SPF record have an "include" limit of 10?

It's a guardrail straight out of RFC 7208. Capped at 10 so nobody can turn your SPF record into a DNS amplification mess. Every include, a, mx, ptr, exists and redirect nudges the counter up by one. Sail past 10 and receivers hand you back a permerror, which, in practice, just switches your SPF off completely. So I start flagging it while you're creeping toward the line. Not after you've already face-planted over it.

What selector should I use for DKIM lookup?

You don't need it memorised. I auto-try the twelve I bump into most (google, default, k1, selector1, selector2, dkim, mail, smtp, mxvault, mandrill, sendgrid, sib). If your provider went off and picked some custom name, it's usually buried somewhere in their docs. Dig it out, paste it into the optional field above, and I'll head straight for that one.

Does BIMI require a paid certificate?

For the big two, yeah, basically. Gmail and Yahoo flat-out won't show your logo without a Verified Mark Certificate from a CA like DigiCert or Entrust, and getting one is paid and a bit of a slog. Other receivers are looser and render BIMI without it. Me, I can only tell you whether your record exists and whether it points at a VMC at all. Actually buying the cert? That part's on you.

Is the domain I check stored anywhere?

Nope. The lookups go out to Google Public DNS as plain DoH requests, and that's where it ends. Nothing gets logged. The domain's gone the moment you close the tab, and it never gets quietly shipped off to some analytics pixel either. Whatever you're looking at in that results table lives in your browser's memory and nowhere else on earth.