Mail Check – is your domain protected against forged senders?

Enter a domain or an email address. In one to three seconds you get a report on everything that can be measured from outside: who is allowed to send in your name, whether your mail is signed, what recipients are told to do with a forgery, where your mail is delivered, whether your servers are on a blocklist, and whether delivery to you is encrypted. Every finding links to the passage on these pages that explains it and says what to do.

Three records, three jobs

Email authentication rests on three DNS records. They are often mentioned in one breath, which hides the fact that each does something entirely different – and that two of them are useless without the third.

The cases that keep being misunderstood

DMARC on p=none

This is the most common state we see, and the one most often mistaken for protection. p=none means: report forgeries and deliver them anyway. As the first step of a rollout it is exactly right. As a permanent state it is a monitoring system nobody reads, and a forger has the same opportunity as on a domain with no DMARC at all. The way out is to read the reports for a few weeks, authenticate every sending path they reveal, then move to quarantine and later reject.

The SPF record that failed without saying so

SPF may cost a receiving server at most ten DNS lookups, and the cost sits mostly inside other people's records. One popular hosting include alone consumes fifteen. When the total goes over ten, the record is not "a bit too long" – it counts as an error and is ignored entirely. Nothing about that is visible in your own DNS panel, and your record does not have to change for it to happen: it is enough that a provider you include changes theirs.

The logo that never appears

BIMI has three requirements that all have to be met at once: DMARC enforced, a logo file in a narrow SVG profile, and a mark certificate. Miss any one and the record does nothing – silently, with no error anywhere. Most disappointment here comes from ordering the steps backwards, starting with a certificate while DMARC is still on p=none.

Reports that never arrive

A DMARC record that sends its reports to a different domain needs that domain's permission, published as a small record of its own. Without it, the sending providers discard the reports. The record looks perfectly correct, and nothing ever lands in the mailbox. The same happens with TLS-RPT when the rua field is missing altogether.

The domain with no mailboxes

Old brand names, defensive registrations, the domain from a campaign three years ago. They receive nothing and send nothing, and almost none of them are protected – which makes them convenient for anyone who wants to write in your name. Three records close the door: a null MX, v=spf1 -all, and DMARC on p=reject. Ten minutes per domain.

What this test cannot do

• DKIM cannot be guessed reliably. DNS never says which selector a domain uses, so a check run from outside can only try known names – around fifty across five markets. "Not found" therefore does not mean "not there". Enter the selector, or paste the headers of a real message, and the key is verified instead of guessed.
• STARTTLS and mail server certificates are not measured. Outgoing SMTP is blocked on the checking server, so we cannot open a connection to your mail server. The report says "not measurable" rather than quietly calling it fine. What is measurable from DNS – MTA-STS and TLS-RPT – is checked.
• Spamhaus is not queried. It does not answer queries from data centre addresses without a paid access key, and a "query refused" reply is not a result. Six other blocklists are checked normally.
• This is a snapshot, taken from outside. DNS answers can be cached, providers change their records, and a listing can appear an hour after a clean result. Nothing here replaces looking at your own reports.

Every topic explained separately

Each of the seven topics has its own page: what the record contains, an example broken down part by part, the mistakes that actually happen in practice, click paths for the common providers, and every finding the check can report – each with what was measured, why it counts, and what to do about it.

Frequently asked questions

Do I need to sign up?

No. Enter a domain and the check runs. Three checks a day are free. Only the report itself is stored and it expires after 24 hours.

Does the check send mail to my domain?

No. It reads public DNS records and, for BIMI, fetches two files from your web server. Nothing is delivered to your domain and no mailbox is touched.

Which of the findings should I fix first?

In this order: a missing or broken SPF record, then DKIM, then DMARC – first on p=none with a reporting address, later stricter. Blocklist hits are urgent whenever they appear. BIMI comes last and is optional.

Can I check a domain that only hosts a website?

Yes, and it is worth doing. The check recognises a domain without mailboxes and reports specifically what is missing to keep it from being used as a forged sender.

Why do results change between two runs?

Because DNS answers are cached with different lifetimes, and because blocklists and provider records change constantly. A record you have just edited may take up to an hour, occasionally a day, to be visible everywhere.