SPF
Lists which servers may send mail for the domain. It checks the sending host, not the address a recipient reads, which is why SPF alone does not stop spoofing.
Can a stranger send mail that appears to come from your domain? Everything else here — the records, the flags, the key lengths — is working towards that one answer, and this page gives it before the detail.
Lists which servers may send mail for the domain. It checks the sending host, not the address a recipient reads, which is why SPF alone does not stop spoofing.
A signature on each message, verified against a key in DNS. Survives forwarding in a way SPF does not, because it travels with the message.
The only part that tells receivers what to do with mail that fails, and the only part that looks at the From address a person actually sees.
Makes TLS mandatory for mail arriving at your domain. Without it, a sender that cannot negotiate encryption quietly delivers in plain text instead.
SPF authorises the envelope sender — the address used in the SMTP conversation, which no recipient ever sees. DKIM proves a message was signed by someone holding the key. Neither looks at the From header, which is the only address displayed in a mail client.
So a message can pass SPF and DKIM for a domain the attacker controls, while showing your domain in the From line, and nothing in either protocol objects. DMARC is what closes that gap: it requires the visible From domain to align with the domain that passed SPF or DKIM, and it tells receivers what to do when it does not.
Which is why a domain with textbook SPF and DKIM and p=none is still spoofable, and why this check reports that plainly rather than counting records and awarding a grade.
The reverse matters too. Moving to p=reject before every legitimate sender passes will reject your own mail — invoices, ticketing systems, the marketing platform somebody set up years ago. That is what the aggregate reports are for, and why the sensible path is p=none with an rua address, a few weeks of reading, then quarantine, then reject.
Unless DMARC is published with p=quarantine or p=reject, yes — SMTP has no built-in way to verify the From address, and that is the address people read. SPF and DKIM do not prevent it on their own because neither one examines the From header. This check tells you which case you are in.
It will reject any legitimate sender that is not authorised, and in most organisations there are more of those than anyone expects: accounting systems, helpdesks, newsletter platforms, scanners that email documents. That is what the aggregate reports are for. Publish p=none with an rua address first, read the reports for a few weeks, authorise what you find, and then tighten.
Because DNS has no way to list a domain's DKIM selectors — a checker can only ask about names it already knows. We try sixteen documented provider defaults. Finding nothing means the domain does not use those names, which is not the same as having no DKIM. The selector in use is in the s= field of the DKIM-Signature header of any message you send.
Not to receive mail, but without it the encryption of inbound mail is optional and silent: a sender that fails to negotiate TLS delivers in plain text and nobody is told. MTA-STS makes it mandatory for senders that support it. It needs a DNS record and a policy file served over HTTPS, and publishing only the record — which is a common mistake — achieves nothing.
The domain is sent to our diagnostic service to perform the lookups and is not kept afterwards. No check on this page asks for a password, an API key or a mailbox credential, and none of them needs one: everything it reads is already published in public DNS.
Getting to an enforced DMARC policy means finding every system that sends as you — the CRM, the invoicing platform, the scanner in the corner — and authorising them before you tell the world to reject the rest. We do that migration, and then the inbound side that display-name spoofing walks straight past.