Google and Yahoo now reject mail from domains that fail authentication, rather than sending it to spam. This checks whether yours passes — SPF, DKIM, DMARC, transport security and blocklists — and grades it out of 100.
Only public DNS records and your homepage — the same things any mail server checks before deciding whether to trust a message from you. Nothing is sent to your domain, no mail is delivered, and no access is required. If we can see it in ten seconds, so can everyone deciding whether to accept your mail.
In February 2024 Google and Yahoo changed the rules together, and Microsoft followed for consumer Outlook accounts in 2025. The change that matters is not that unauthenticated mail gets filtered more aggressively — it is that it gets rejected. It does not land in a junk folder. It does not arrive.
| Everyone | SPF or DKIM. A matching reverse DNS record for your sending server. Mail sent over TLS. Message formatting that follows the standards. |
| Over 5,000 a day | SPF and DKIM and DMARC, with the visible From address aligned to the domain that authenticated. One-click unsubscribe, honoured within two days. Spam complaints kept under 0.3%. |
| The threshold | Counted per provider, and it includes everything — invoices, password resets and notifications, not just campaigns. Most companies cross it without deciding to. |
Every one of these is a public DNS record. Anyone can read yours right now, including the people deciding whether to accept your mail.
| SPF who may send as you | A DNS record listing the servers allowed to send mail using your domain. A receiver checks the connecting server against it. It is limited to ten DNS lookups. Every vendor you add — a CRM, a helpdesk, a payroll system — spends some, and the eleventh breaks the whole record rather than just the last entry. |
| DKIM a signature on the message | A cryptographic signature added by your sending server and verified against a public key in your DNS. It proves the message was not altered on the way. Each sending service needs its own key published. A service added later and never given a key sends unsigned mail that nobody notices until it stops arriving. |
| DMARC what to do with failures | Ties SPF and DKIM to the address recipients actually see, and tells receivers what to do when neither passes. It is also the only way to get reports on who is sending as you. Most domains publish p=none, which asks receivers to report failures and enforce nothing. It satisfies the letter of the bulk-sender rules and stops no impersonation at all. |
| MTA-STS and TLS-RPT encryption in transit | MTA-STS tells other mail servers to insist on a valid encrypted connection to you. TLS-RPT asks them to report it when that fails. Without MTA-STS, mail encryption can be silently stripped by anything in the path, and delivery still succeeds — so nothing looks wrong. |
| Blocklists whether you are already flagged | Whether your domain or sending addresses appear on the major reputation lists that receivers consult before accepting a connection. A listing you did not cause — a shared IP, a compromised mailbox, a forwarded newsletter — affects you exactly as much as one you did. |
| BIMI your logo in the inbox | Displays your verified logo beside your messages in supporting clients. It is the visible reward for getting the rest right. It requires DMARC set to quarantine or reject first, so it is a signal of enforcement rather than a thing you can simply switch on. |
Usually because the failures are invisible to you. If your DMARC policy is p=none — and most are — receivers report problems and deliver the mail anyway, so nothing visibly breaks. The damage shows up selectively: bulk and marketing sends to Gmail, mail to recipients who have never received from you, and anything forwarded. Your own inbox is the least reliable place to notice, because mail inside your company usually never leaves your own server.
Not for anyone sending more than about five thousand messages a day to a given provider, and not really for anyone else either. SPF breaks whenever mail is forwarded, because the forwarding server is not on your list — which is why DKIM exists, and why the rules now ask for both plus DMARC tying them to the address people actually see.
No, and doing so is the most common way to cause real damage while trying to improve security. Enforcing before you know every legitimate sender means your own invoices, password resets and notifications start bouncing. The order that works is: publish p=none, read the reports for a few weeks until you recognise every source, fix or authorise each one, then move to quarantine, then to reject.
No. It reads public DNS records and fetches your homepage the way any browser would. No mail is sent, nothing is delivered to your inboxes, and no access or credentials are needed. Everything reported is already readable by anyone who wants to look, including every mailbox provider deciding whether to trust you.
Because some checks cannot always be completed from where we run. The main blocklists refuse queries from large cloud providers, and when that happens we say the check did not run rather than counting it as a pass or a failure. The score is then calculated over what was actually measured, and the page tells you the number it was scored against. A tool that quietly scores you out of eighty and presents it as a hundred is not being generous; it is being wrong.
Send it to whoever controls your DNS — every result here has a permanent link for exactly that, because the person who runs a check is rarely the person who can change a record. The fixes are specific: which record to add, what to put in it, who normally owns it, and how to confirm it worked afterwards.
Built by Infinitus Management Consulting. The grader is free and stays free — it reads public records, so running it costs us almost nothing and gating it would be theatre.