Email authentication checker

DMARC is a DNS record that tells other mail servers what to do with messages that claim to be from your domain but fail authentication. It has three settings. p=none asks them to report the failure and deliver the message anyway. p=quarantine asks them to hold it where the recipient will not see it. p=reject asks them to refuse it outright. Without a DMARC record at quarantine or reject, anyone can send mail showing your exact domain in the From line and it will be delivered normally, because SPF and DKIM on their own do not instruct the receiver to do anything about a failure.

It can, and the risk is entirely about preparation rather than about the setting itself. What breaks is mail from a legitimate system you did not know was sending as your domain. Invoicing platforms, appointment reminders, marketing tools, applicant tracking systems, and multifunction copiers that scan to email are the usual casualties. This is why the aggregate reports come first. Publish DMARC at p=none with a rua= address, read the reports for two to four weeks until you can account for every sender, authorise them in SPF and DKIM, and only then tighten the policy. Done in that order it is uneventful. Done by skipping straight to enforcement it takes out the billing run.

Because delivery is not visible in DNS. This tool reads the records you publish, which describe your configuration and your exposure to being impersonated. Whether a specific message reached a specific inbox depends on the receiving organisation's filtering, your sending reputation, the content of the message, and things no external party can see. Proving mail actually flowed requires the headers of a real message that arrived, which we do not have and cannot obtain over DNS. A perfect grade here is not a promise that your mail lands in inboxes, and a poor grade does not mean your mail is being blocked today.

Quarantine is real protection and we grade it that way. A message that fails DMARC under a quarantine policy does not reach the person it was aimed at. On Microsoft 365 it goes to the hosted quarantine, which is administrator controlled and is not the user's junk folder, so nobody is one click away from opening it. Reject is a genuine improvement because the message is refused rather than stored, and it removes the case where someone releases a spoofed message that looked convincing. But the large step is the one from none to quarantine, and a business sitting at quarantine has already done the work that matters.

No. A DKIM selector is an arbitrary name chosen by whoever configured signing, and there is no DNS query that lists a domain's selectors. We probe nine common ones, including the two Microsoft 365 uses and the one Google Workspace uses, and the page prints exactly which nine. If your platform signs with a name outside that list, we cannot see it and the result says unconfirmed rather than missing. That is also why the grade shows a second figure for what it would be if DKIM is present on a selector we did not check. To settle it, look up the selector your mail platform reports in its admin console.

Evaluating an SPF record is allowed to trigger at most ten DNS lookups, counted across the whole record including everything inside each include. Go over it and receiving servers return a permanent error, which means SPF fails for every message you send rather than degrading gracefully. It is the most common silent breakage in email authentication, because nothing warns you when the record crosses the line. The fix is removing includes for services you no longer use, and replacing fixed-IP senders with ip4 entries, which cost no lookup at all.

Yes, and it is worth being clear about why. DMARC only governs the domain in the From address. A message sent from a Gmail account with your chief executive's name in the display field passes DMARC without any difficulty, because the domain it was actually sent from belongs to whoever sent it. So does a lookalike domain with one letter swapped, which publishes its own perfectly valid SPF, DKIM, and DMARC. A strong grade here means nobody can forge your exact domain, which closes one specific and very commonly used route. It does not close display-name spoofing, lookalike domains, or a supplier whose mailbox has been taken over and is sending genuine mail with new bank details.

Because two different things can be true and DNS cannot tell them apart. When no DKIM key turns up on the selectors we probe, the domain might have no DKIM, or it might sign under a name we did not guess. Rather than pick one and be confidently wrong, the result shows the grade as measured and the grade you would have if the key exists somewhere we did not look. The same principle applies elsewhere: a lookup that does not complete is dropped from the score rather than counted as a failure, and a domain with a wildcard DNS record has DKIM removed from the score entirely, because every selector would appear to exist.

No. Every result on this page comes from public DNS records plus, when a domain publishes one, the MTA-STS policy file it deliberately serves at a well known public address. The tool never connects to a mail server, never scans a port, and never sends test mail. It sees exactly what any receiving mail server sees when it decides what to do with your message, which is why it can be run against any domain without permission and without touching anything.

No. There is no database behind this, no export, and no list of checked domains going to sales. Results are held in memory for about fifteen minutes so a repeated check is fast, and then they are gone. There is no email gate, no sign-up, and no full report held back. What you see is the whole result.