Email Health Check
Seven Records, and What to Fix First

What an Email Health Check Actually Tests — and Why Seven Records, Not Three

Three records get all the attention: SPF, DKIM and DMARC. They deserve it — they are what the bulk sender requirements at Google, Microsoft and Yahoo actually name, and they are where most real problems live. But three records is not the whole configuration. A check that stops there will tell you a domain is fine while its mail is being delivered to its web server, or while its transport encryption policy has been returning a 404 for eight months.

So this email health check reads seven, in the order a message actually encounters them:

Reading all seven is the easy part. The reason this page exists is the part after that: the conflicts between them. An SPF record ending in ?all is not a fault on its own — it is a deliberate statement of no opinion. A DMARC policy of p=reject is not a fault either; it is the goal everyone is told to reach. Put the two together on one domain and you have a configuration that hard-fails legitimate mail, and neither an SPF checker nor a DMARC checker can see it, because each one is looking at half the picture. The tool above reports ten of those cross-record conflicts, and every one of them is invisible to a single-record tool.

What it does not do, said here rather than buried

It does not expand your SPF include: chain. Counting the full ten-lookup budget takes recursion — often sixty or more DNS queries for one domain — and doing that inside a seven-record page would make it slow enough to be useless. What you get here is an honest count of the lookup-costing terms visible in your own record, clearly labelled as a lower bound, and the SPF row links through to the dedicated tool that walks the whole tree branch by branch.

It does not guess your DKIM selector either, and it is worth understanding why nothing can. DNS offers no way to list the selectors under a domain. A tool that appears to discover yours is probing a list of common names. A domain using a selector outside that list then gets told it has no DKIM, while it is in fact signing every message perfectly. If you know your selector, type it in and the DKIM row is checked in full. If you do not, the row says it was skipped and why — which is a true statement, where “no DKIM found” would not be.

And it does not tell you whether a particular message will land in the inbox. Configuration is the half you control and the half that lives in DNS. The other half is sending reputation, complaint rate and content, which no record-based tool can see and which anybody promising otherwise is inventing. If mail is being filtered despite everything here passing, the problem has moved to what actually decides whether your mail reaches the inbox, and that is a different investigation.

The Subdomain Trap: What Inherits, What Does Not, and Why Checkers Get This Wrong

Here is the single most expensive misunderstanding in email authentication, and it is not complicated — it is just inconsistent, which is worse.

Some of these records inherit from the parent domain. Some do not. And the ones that do not are the ones people assume do.

If you send marketing mail from news.yourbrand.com, or transactional mail from mail.yourbrand.com, every one of the seven records behaves differently on that name:

Read that table again, because it explains two opposite mistakes that people make on the same afternoon.

Mistake one: assuming SPF flows downhill

RFC 7208 is unambiguous about where an SPF record goes. It is published “at the owner name it pertains to, not in a subdomain under the owner name”. There is no inheritance, no wildcard behaviour, no fallback. A perfect SPF record on yourbrand.com does precisely nothing for mail sent from news.yourbrand.com.

The symptom is specific and recognisable: your main domain’s mail is fine, your newsletter is landing in spam, and every check you run says the domain is configured correctly — because you have been typing the parent domain into it. Type the sending subdomain instead and the record disappears.

Mistake two: reporting “no DMARC” on a subdomain that is fully protected

DMARC does the opposite. A subdomain with no _dmarc record of its own is not unprotected — it is governed by the organisational domain’s record: the sp= tag if the parent publishes one, and p= if it does not. A checker that queries only _dmarc.news.yourbrand.com, finds nothing and announces “this domain publishes no DMARC record” is giving a wrong answer about a correctly configured domain. BIMI has the same fallback for the same reason.

This page resolves both names for both protocols, tells you which one answered, and labels a row as inherited when it is. It is the reason the result panel prints a DNS name under every row instead of just a tick.

Where the parent stops being a parent at all

There is a third case, and it catches people who are not running their own domain. yourshop.myshopify.com, yourblog.blogspot.com, yourapp.vercel.app and yoursite.github.io all look like subdomains. For the purposes of every record on this page, they are not. Those parents sit on the Public Suffix List — the registry of names under which the public may register, which receivers use to work out where one organisation ends and the next begins.

The consequence is blunt: nothing is inherited across that line. Shopify’s DMARC policy does not cover your shop, and GitHub’s does not cover your Pages site, however strong those policies look when you go and read them. Your name is its own organisational domain, everything has to be published on it, and on most hosting platforms you cannot publish DNS records for it at all. If you need authenticated mail, that is the moment to move to a domain you own.

The check above works this boundary out from a suffix table rather than the full Public Suffix List, and it says so on any finding that depends on it. The alternative — telling somebody they are covered by a policy that does not reach them — is the worst answer a page like this can give.

And the MX fallback that quietly aims your mail at a web server

If a domain has no MX records at all, senders do not give up. RFC 7505 describes exactly what happens: a sender “falls back to looking up a DNS A or AAAA RR” — so mail is delivered to whatever IP address the domain points at, which on a subdomain is usually a web server that is not expecting it. The message does not bounce with a clear error. It is attempted, repeatedly, against a host with no mail service, and the RFC notes senders retry “for a long period, typically a week” before giving up.

This is one of the findings the tool above reports as an error rather than a note, because the domain looks configured from the outside and is not.

SPF, DKIM and DMARC: the Three That Decide Whether Mail Is Accepted

These three do the real work, and they work as a chain rather than as a checklist. SPF and DKIM each produce a result; DMARC decides what that result means for your domain and what a receiver should do about it. Get the order wrong and you enforce a policy on top of authentication that does not work yet.

SPF: one record, ten lookups, and the qualifier at the end

SPF lists the servers permitted to send using your domain in the envelope sender. Three things break it, and this page checks all three.

More than one record. RFC 7208 does not pick a winner between them: “If the resultant record set includes more than one record, check_host() produces the ‘permerror’ result.” Two SPF records is not a stricter SPF. It is no SPF at all, and it happens every time a new platform’s setup guide says “add this TXT record” and nobody merges it with the existing one.

The ten-lookup limit. The include, a, mx, ptr and exists mechanisms and the redirect modifier each cost a DNS lookup, and an implementation “MUST limit the total number of those terms to 10”. Over the limit, SPF returns permerror and stops authenticating anything — including the mail that was working yesterday. The count shown above is what is visible in your own record; every include: brings its own terms on top, which is what the SPF record checker exists to count properly.

The qualifier at the end. -all is a hard fail, ~all a soft fail, ?all explicitly neutral, and +all authorises the entire internet to send as you. A record ending in ?all cannot produce an SPF pass for anything you did not list, which means SPF contributes nothing to DMARC — a state that looks configured and is not.

There is one shape that looks like that fault and is not, and it is worth recognising because three of the largest mailbox providers publish it. A record of just v=spf1 redirect=_spf.example.com has no all mechanism at all, and it is completely correct: RFC 7208 returns neutral only “if none of the mechanisms match and there is no redirect modifier”, and where there is one, the result of the target record “is then considered the result of the current evaluation”. gmail.com, yahoo.com and icloud.com all publish exactly that. The qualifier that applies to you then lives in the other record, and so do its DNS lookups.

DKIM: the signature that survives forwarding

DKIM signs each message with a private key; the matching public key sits in DNS at selector._domainkey.yourdomain.com. It matters more than SPF in one specific and very common situation: forwarding. When a mailing list or a forwarding address relays your message, the connecting IP changes and SPF fails — but the DKIM signature travels with the message and still verifies. A domain with SPF and no DKIM loses authentication the moment anyone forwards anything.

The checks worth knowing: p= is the only required tag, and RFC 6376 says an empty value “means that this public key has been revoked” — which is a different and much worse thing than no record. A t=y flag marks the key as testing, and the RFC tells verifiers they “MUST NOT treat messages from Signers in testing mode differently from unsigned email”, so a testing flag left on after go-live silently cancels your DKIM. And key length matters: 1024 bits is the published floor at the large receivers, 2048 the recommendation. The row above measures the real modulus out of the key rather than estimating it from the length of the base64. To find your selector and measure the key behind it in more depth, including the algorithm and the tag order, use the dedicated tool.

DMARC: the policy, and the word everyone skips

DMARC ties the other two to the domain your recipients actually see — the one in the From header — and that tie is alignment. It is the word that explains the most confusing situation in email: SPF passes, DKIM passes, and DMARC still fails. That happens when the domain that passed belongs to your sending platform rather than to you. Passing is not aligning.

The policy itself has three values. p=none monitors and asks receivers to do nothing differently. p=quarantine asks for suspicious mail to go to spam. p=reject asks for it to be refused outright. Start at none with a reporting address, read the reports until you recognise every sender, then move up. The order is not optional: a domain at p=reject whose SPF ends in ?all and which publishes no DKIM is asking receivers to reject its own mail, and that specific combination is one of the cross-record findings this tool reports.

MTA-STS and TLS-RPT: Encrypting the Mail in Transit

SPF, DKIM and DMARC are all about identity — who sent this, and are they allowed to. None of them encrypts anything. The mail itself travels between servers over SMTP, and SMTP’s encryption is opportunistic: if the receiving server offers STARTTLS the sender uses it, and if the offer is stripped in transit the sender quietly falls back to plaintext. That fallback is the attack.

MTA-STS closes it. You publish a TXT record at _mta-sts.yourdomain.com and a policy file over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, listing your MX hosts and a mode. In enforce mode, a sender that cannot make a valid TLS connection to a listed host must not deliver the message at all rather than deliver it in the clear.

TLS-RPT is how you find out it broke. A TXT record at _smtp._tls.yourdomain.com with a reporting address, and sending providers mail you a daily summary of TLS negotiation successes and failures against your domain. Without it, a certificate that expired on one of your MX hosts is invisible until somebody complains.

Here is why they are worth a section of their own: of the 196 large, well-known domains we resolved on 23 September 2026, 162 publish neither one. That is our own measurement, not an estimate, and the full figures are below.

What our own measurements show

On 23 September 2026 we resolved these records across the same 196 large, well-known domains we use for every survey on this site. The numbers are ours, measured, and repeatable:

This is a convenience sample of large, well-known domains rather than a random one, so read it as a picture of the well-resourced end of the internet — the end where adoption should be highest. Now read the middle two rows together, because that comparison is the whole point. More than three times as many of these domains put a logo in your inbox as force their mail to be encrypted in transit. BIMI is newer, harder and usually costs money in certificates; MTA-STS is free and needs one TXT record and one static file. The gap is not about difficulty. It is about which one is visible to a marketing department.

One more figure from the same run, and it is an encouraging one: of the 28 domains publishing MTA-STS, 27 also publish TLS-RPT. Whoever gets as far as transport security almost always turns the reporting on too. Six more publish TLS-RPT without an MTA-STS policy, which still buys them something: RFC 8460’s reports cover “failures in routing, DNS resolution, and STARTTLS negotiation”, not only policy failures, so reporting is a reasonable first step even before a policy exists.

The policy file is also the only one of the seven records that can rot without any DNS change at all. The TXT record keeps saying a policy exists; the web server that used to serve it was decommissioned in a migration. The tool above downloads the file and tells you what it was actually served — and our MTA-STS checker goes further, comparing the mx entries inside your policy against your live MX records.

BIMI, MX, and the Two Ends of the Stack

The seven records bracket the whole problem. MX sits at the bottom, deciding whether mail arrives at all. BIMI sits at the top, deciding whether your logo appears beside your name once everything underneath is right. They are the first and last things to look at, and for opposite reasons.

MX: the record that has to be right before anything else matters

Three MX configurations are correct, and they are very different statements:

• Real MX records. One or more hosts, each with a preference number. Mail is delivered to the lowest preference that answers.
• A null MX. RFC 7505 defines it as a single record with “preference number 0 and a zero-length label, written in master files as ‘.’” — the explicit statement that this domain accepts no mail. The RFC is equally explicit that it must be alone: “A domain that advertises a null MX MUST NOT advertise any other MX RR.”
• Nothing at all — on a domain with no address record. Senders find nowhere to go and stop. Untidy, but not dangerous.

The fourth case is the dangerous one, and it is the A/AAAA fallback described earlier: no MX, but an address record, so mail is delivered to your website. If a domain sends but does not receive, a null MX is the correct configuration, and it costs exactly one DNS record.

BIMI: last, because it displays nothing until the rest is right

BIMI puts your logo in the inbox, and it is gated on DMARC: the policy has to be quarantine or reject, on the domain and on its organisational domain, before any mailbox provider will look at the record. That gate is why BIMI is the last item in the fix order above. It is also why a BIMI record on a domain at p=none is a record nobody will ever read.

The record itself is trivial — one TXT entry with an l= URL and usually an a= certificate URL. What breaks is the file at the other end of that URL, which must be SVG Tiny Portable/Secure: a stripped-down profile that requires version="1.2", baseProfile="tiny-ps" and a non-empty <title>, three things no drawing tool exports on its own. This page checks the record and the DMARC gate in front of it; our BIMI check downloads the logo and validates the file itself, rule by rule.

Fixing Them in the Right Order — and What Happens If You Do Not

A list of red rows is easy to produce and hard to act on. The useful question, when you are looking at five of them, is which one do I touch first — and the answer is not “the most severe”. It is the dependency order, because several of those rows cannot be fixed correctly until the ones below them are, and that is what the fix list in the result panel gives you.

The expensive mistake is jumping to step 3. Somebody reads that p=reject is the goal, publishes it, and every receiver that honours DMARC starts refusing mail from the four sending platforms nobody documented — the invoicing system, the recruitment tool, the CRM, the helpdesk. The failures are silent to you and hard bounces to them. This is not a rare disaster story; it is the single most common way a DMARC rollout goes wrong, and the only protection against it is the boring one: publish p=none with a reporting address, read the reports for a few weeks, and move up only when you recognise every sender in them.

What each record looks like when it is right

Shapes, not a generator — every value below has to be your own. The point is to recognise a healthy record when you look at one.

Two shapes on that list are worth memorising because they are the ones people get wrong from memory. 0 . is a null MX — preference zero, and a single dot for the host. And a DMARC record with no rua= is a policy you will never get feedback on, which is how a p=reject rollout goes wrong quietly.

A realistic timeline

1. Day one. Fix MX if it is wrong. Publish or merge SPF to a single record ending in ~all. Turn on DKIM signing at every sending platform and publish each selector.
2. Day two. Publish v=DMARC1; p=none; rua=mailto:…, and make sure the reporting mailbox is one someone actually reads.
3. Weeks two to six. Read the aggregate reports. Every legitimate sender that is failing is either missing from SPF or not signing with DKIM. Fix them one at a time.
4. Once the reports are clean. Move to p=quarantine, then to p=reject. Set sp= deliberately rather than letting it default.
5. Then transport. MTA-STS in testing mode first, with TLS-RPT so you can see what testing reveals, then enforce.
6. Last. BIMI, if a logo in the inbox is worth the certificate to you.

Two things sit outside this list because they are not configuration. New sending infrastructure needs volume ramped gradually rather than switched on — the mechanics of warming a new sending IP matter as much as the records do. And before any large campaign it is worth checking sender reputation ahead of a bulk send, because perfect authentication on a poor-reputation IP still lands in spam. Records get you the right to be judged on your merits; they do not decide the judgement.

Email Health Check: Frequently Asked Questions