Email Authentication Checker

Why the Four Records Work as a System

SPF, DKIM, DMARC, and BIMI are often explained as four separate checkboxes, but they behave much more like one machine with four connected parts. SPF and DKIM are the evidence layer: SPF proves that the server delivering a message was authorized to send mail for your domain, while DKIM proves that the message was cryptographically signed by your domain and was not altered along the way. DMARC is the decision layer: it reads the SPF and DKIM results, checks whether either one aligns with the domain people actually see in the From line, and tells the receiving server what to do when both checks fail. BIMI is the reward layer: once DMARC is enforced, it allows participating inbox providers to display your verified brand logo next to your messages.

Because the chain flows in one direction, a weakness early in the chain undermines everything after it. A strict DMARC policy accomplishes nothing if neither SPF nor DKIM can pass with alignment, and BIMI will never show a logo for a domain whose DMARC policy is still in monitoring mode. That is why the checker above evaluates all four records together rather than in isolation: a domain can publish four syntactically valid records and still fail authentication in practice because the parts do not agree with each other.

Recommended Setup Order for a New Domain

Start with SPF, because it is the fastest record to publish and most sending services tell you exactly what to include. Add one TXT record at your domain root beginning with v=spf1, list every legitimate sending source, and finish with -all (or ~all while you are still discovering forgotten senders). Next, turn on DKIM signing in every platform that sends mail on your behalf — your mailbox provider, your marketing tool, your support desk — and publish the public keys they generate as selector records. DKIM deserves equal priority to SPF because it is the more durable signal: a DKIM signature survives forwarding, while SPF often breaks when a message is relayed.

Only then publish DMARC, and start it gently. A record like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com blocks nothing, but it switches on aggregate reporting so you can see exactly which sources pass and which fail. Once the reports look clean for a few weeks, tighten the policy to p=quarantine and eventually p=reject. BIMI comes last by design, because the specification requires an enforced DMARC policy before any logo can be displayed. Treat it as the finish line: prepare the SVG logo first, obtain the certificate if you need one, and publish the record only when DMARC enforcement is stable.

How Each Stage Affects Deliverability

Mailbox providers do not weigh the four records equally, and the deliverability effect compounds as you move down the chain. A domain with no SPF and no DKIM looks indistinguishable from a spoofed one, and the largest inbox providers now require both mechanisms, plus a published DMARC record, from anyone sending meaningful volume. Passing SPF and DKIM does not guarantee the inbox — content and reputation still matter — but it ensures your mail is judged on its merits instead of being filtered on suspicion.

DMARC affects deliverability more indirectly but more permanently. An enforced policy stops strangers from sending as your domain, which keeps spoofed junk from poisoning the sender reputation your legitimate mail depends on. It also consolidates your identity: receivers can attribute every aligned message to your domain and build a consistent reputation history for it. BIMI sits at the end of the chain and is not a filtering input at all; its value is human. A verified logo makes legitimate mail instantly recognizable in a crowded inbox and signals that the sender cleared a high authentication bar.

Alignment, Explained Simply

Alignment is the rule that the domain a person sees must match the domain that actually passed authentication. Every message carries a visible From address, but SPF authenticates a hidden bounce address called the Return-Path, and DKIM authenticates whatever domain appears in the d= tag of its signature. DMARC only counts a result as passing when the authenticated domain matches the visible From domain — that match is alignment, and it is the single most misunderstood concept in email authentication.

Alignment comes in two strengths. Relaxed alignment (aspf=r and adkim=r, the defaults) accepts a subdomain match, so mail authenticated as mail.yourdomain.com aligns with a From address at yourdomain.com. Strict alignment (s) demands an exact match. The most common real-world failure looks like this: a third-party service sends your newsletter, SPF passes — but for the service's own domain, not yours — and DMARC fails anyway because nothing aligned. The fix is almost always to enable DKIM signing with your own domain in that service's settings.

A Worked Example: Reading Real Records

Here is a realistic SPF record, piece by piece: v=spf1 include:_spf.mailhost.example ip4:203.0.113.25 ~all. The v=spf1 tag declares the version and must come first. The include: mechanism pulls in the list of servers your email provider publishes, and each include costs one of the ten DNS lookups RFC 7208 allows — exceed ten, and the whole record returns a permanent error, which most receivers treat as a failure. The ip4: mechanism authorizes one specific address, such as an office mail gateway, and costs no lookup at all. The final ~all is a qualifier meaning soft fail: unlisted senders are suspect but not categorically rejected, whereas -all declares a hard fail and is the right end state once you trust your list.

A matching DMARC record might read: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; np=reject. Here p=quarantine asks receivers to send failing mail to spam rather than reject it outright, rua names the mailbox that receives aggregate reports, which providers typically deliver once a day, and adkim=r keeps DKIM alignment relaxed. The np=reject tag is one of the additions in the current DMARC standard (DMARCbis, RFC 9989): it applies a stricter policy to subdomains that do not exist at all, which attackers love to invent because nonexistent subdomains historically inherited the gentler sp or p policy.

The Four Records Side by Side

The table below summarizes where each record lives in DNS, what a passing result actually proves, and the hard limits the relevant standards impose. Keep it handy when interpreting checker results: a surprising number of failures trace back to a record published at the wrong location or a limit quietly exceeded.

Reading a Full Checker Report

The checker above reports one of four statuses per record. Pass means the record exists, parses cleanly, and meets current standards. Warning means the record works but something is suboptimal: an SPF record sitting at nine lookups, a ~all qualifier on a mature domain, a DMARC policy still at p=none, or a 1024-bit DKIM key that meets the minimum but falls short of the recommended 2048 bits. Fail means the record is actively broken — a syntax error, an exceeded lookup limit, a malformed public key — and receivers will likely treat it as if authentication failed. Not found means no record exists at the expected DNS location, which for DKIM often just means the checker needs the selector your provider actually uses.

Consider a typical mixed report: SPF passes, DKIM returns not found, DMARC shows a warning for p=none, and BIMI returns not found. Read as a system, this domain is half-built. The missing DKIM is the urgent item, because without it every forwarded message will fail DMARC once enforcement begins. The DMARC warning is expected at this stage — p=none is the correct starting point — and the missing BIMI record is not a problem at all yet, since BIMI cannot function until DMARC reaches enforcement. The order of fixes falls straight out of the chain: complete the evidence layer, then tighten the decision layer, then claim the reward.

Maintenance and Monitoring Habits

Email authentication is not a set-and-forget project, because your sending footprint changes even when your DNS does not. Make a habit of reading DMARC aggregate reports — or a tool that digests them — at least monthly, watching for new sources that fail alignment. Re-run the checker every time you adopt a new tool that sends email, before its first campaign rather than after. Audit your SPF record a few times a year: vendors restructure their include chains without notice, and lookup counts have a way of creeping toward the limit of ten while nobody is watching.

A few quieter habits prevent the rarer failures. Rotate DKIM keys periodically and delete selectors for services you no longer use, since an old key at a forgotten vendor is a standing risk. If you use a Verified Mark Certificate for BIMI, calendar its expiry the way you would a TLS certificate. And treat authentication DNS like code: record every change, who made it, and why, so the day a report turns red you can answer the only question that matters — what changed?

Frequently asked questions

Do I need all four records, or are SPF and DKIM enough?

SPF and DKIM authenticate your mail, but without DMARC nothing connects those results to the From address people actually see, and major inbox providers now expect a DMARC record from bulk senders. Publish at least SPF, DKIM, and a p=none DMARC record. BIMI is optional — a branding reward, not an authentication requirement.

Why does the checker show SPF passing while DMARC still fails?

This is almost always an alignment problem. SPF may pass for the domain in the hidden Return-Path — often a third-party sender's own domain — while your visible From domain gets no credit. Enable DKIM signing with your own domain in that sending service, and DMARC will start passing through the DKIM path.

What is the 10 DNS lookup limit, and what happens if I exceed it?

RFC 7208 caps SPF evaluation at ten DNS-querying terms: the include, a, mx, ptr, and exists mechanisms plus the redirect modifier. It also allows at most two void lookups, meaning queries that return no usable answer. Exceeding either cap produces a permanent error that many receivers score like a failure. Fix it by removing unused includes, replacing them with direct ip4/ip6 entries, or moving some mail streams to subdomains.

Is a 1024-bit DKIM key still acceptable?

RFC 8301 sets 1024 bits as the minimum signers must use and 2048 bits as the recommendation, and verifiers are allowed to distrust anything weaker. If your provider offers a choice, choose 2048. The checker flags 1024-bit keys as a warning rather than a failure for exactly this reason.

My DMARC record still contains pct=50 — is it broken now?

Not broken, but outdated. The current DMARC standard (DMARCbis, RFC 9989) removed the pct, rf, and ri tags, while keeping v=DMARC1 unchanged and adding np, t, and psd. Receivers ignore tags they do not recognize, so old records keep working, but you should remove pct and use the new t=y testing tag if you need a trial mode.

Do I need a Verified Mark Certificate to get my BIMI logo shown?

It depends on the mailbox provider. Gmail requires a VMC before displaying any logo, while Yahoo and AOL can display BIMI logos for senders with good reputation without one. Either way, your logo must be in SVG Tiny 1.2 P/S format and your DMARC policy must be at quarantine or reject.

How soon will DNS changes appear in the checker above?

It depends on the TTL (time to live) of the record you changed; the checker queries DNS live, so a fresh record usually appears within minutes, but a cached old value can linger up to the full TTL. If a change does not show after an hour, verify you edited the right zone and the right hostname — for example _dmarc, not the domain root.