SPF / DKIM / DMARC / BIMI checker
Check the email authentication posture of any domain. The tool queries Google Public DNS for SPF, DMARC and BIMI records, probes the 12 most common DKIM selectors, scores each pillar, and returns a prioritised list of fixes. Use it before sending a marketing campaign, before signing off on a new domain, or to investigate why a partner’s mail keeps landing in spam.
DKIM uses a per-message selector that lives in DNS at selector._domainkey.domain. The tool tries 12 well-known selectors (google, default, k1, selector1/2, dkim, mail, smtp, mxvault, mandrill, sendgrid, sib). Add your own selector above if you use a custom one.
What email authentication posture actually means
Modern mail receivers (Gmail, Outlook, Yahoo, Apple, La Poste, OVH and most B2B gateways) decide where to deliver a message based on three machine-verified signals: SPF, DKIM and DMARC. SPF lists the IP addresses that are allowed to send mail “from” your domain. DKIM signs each outgoing message with a private key and publishes the public key in DNS so the receiver can verify the signature. DMARC tells receivers what to do when SPF or DKIM fails: nothing (monitor), quarantine to spam, or reject outright. Add BIMI on top and your verified brand logo shows up next to the sender name in supported inboxes. Get any of these wrong and your mail lands in spam, gets stripped of branding, or worse, lets an attacker spoof your domain.
This checker queries DNS for all four records, parses each one, scores it against the current best practice, and assembles a single email authentication posture score. The result is not a vendor opinion or a paid audit; it is the same data that Gmail and Microsoft use when they decide whether to trust an inbound message from your domain.
How the checker queries SPF, DKIM, DMARC and BIMI
The tool runs four DNS-over-HTTPS lookups in parallel through Google Public DNS. SPF is read from the TXT record at the apex of the domain; the parser filters records that start with v=spf1, expands include statements, counts DNS lookups against the SPF RFC limit of ten, and flags soft fails and pass-all policies. DMARC is read from the TXT record at _dmarc.yourdomain; the parser extracts the policy (none, quarantine, reject), the alignment modes, the reporting addresses and the percentage. BIMI is read from the TXT record at default._bimi.yourdomain; if present, the parser extracts the SVG logo URL and the optional VMC certificate URL. DKIM is the only pillar that requires a selector to look up; the tool tries twelve common selectors (and your custom one, if you provide it), reports which selectors are present, and reads the key length from the first record found.
Common use cases for an email auth checker
- Pre-flight before a marketing campaign. Confirm SPF/DKIM/DMARC are all set and aligned before sending fifty thousand newsletters; one missing record can drop the campaign into spam.
- Investigating “the partner’s mail goes to spam”. Run the checker on the sender’s domain; in most cases a missing DKIM key or a too-loose SPF is the root cause.
- Auditing a new acquisition. When a company joins a group, the email posture is part of the security due diligence. Bad SPF/DMARC equals impersonation risk.
- Preparing for the Gmail and Yahoo bulk-sender rules (2024+). Both require valid SPF, DKIM and a published DMARC for bulk senders; the checker confirms the baseline.
- Enabling BIMI for brand recognition. Before paying for a Verified Mark Certificate, confirm DMARC is at
p=quarantineorp=rejectas required by BIMI. - Switching mail provider. When migrating from one mail vendor to another, the checker confirms the new SPF includes the new vendor and that DKIM publishes the new keys.
Limitations and privacy notes
This checker reads public DNS only; it does not send a test email, does not connect to any mail server, and does not store the domains you check. DKIM is the trickiest pillar because it requires knowing the selector your provider uses; if your provider uses a non-standard selector, add it in the custom field above. SPF expansion is limited to ten DNS lookups by RFC, but the tool only counts top-level includes and does not recursively resolve nested ones — a deeper audit may be needed for very complex setups. BIMI status only reflects whether the record exists; the actual logo and VMC verification still happen on the receiving mail server.
Frequently asked questions
Do I really need both SPF and DKIM?
Yes. SPF authenticates the sending IP; DKIM authenticates the message content. DMARC requires at least one of them to pass with aligned identifiers. Major receivers like Gmail and Yahoo explicitly require both for bulk senders since 2024.
What is a safe DMARC policy to start with?
Start with p=none and a valid rua reporting address. Read the aggregate reports for one to two weeks, fix any legitimate senders that fail, then move to p=quarantine at 25%, then 100%, then p=reject. Going straight to reject without monitoring can silently block your own newsletters or invoices.
Why does the SPF record have an “include” limit of 10?
RFC 7208 caps total DNS lookups at 10 to prevent denial of service. Each include, a, mx, ptr, exists and redirect counts. Going over 10 returns a permerror and effectively disables SPF; the checker warns when you approach the cap.
What selector should I use for DKIM lookup?
The tool tries twelve common selectors automatically (google, default, k1, selector1, selector2, dkim, mail, smtp, mxvault, mandrill, sendgrid, sib). If your provider uses a non-standard selector (often listed in the provider documentation), add it in the optional field above for a targeted lookup.
Does BIMI require a paid certificate?
Gmail and Yahoo require a Verified Mark Certificate (VMC) issued by a CA like DigiCert or Entrust. Other receivers display BIMI logos without the VMC requirement. The checker tells you whether your BIMI record is present and whether it points to a VMC; getting a VMC is a separate paid step.
Is the domain I check stored anywhere?
The DNS queries go to Google Public DNS as a normal DoH request. PeopleAreGeek does not log the domain, does not retain it after you close the page, and does not forward it to any analytics tool. The result table lives in browser memory only.
