Domain-security radar

The domains anyone can forge email from

Around 84% of domains have no enforcing DMARC — the DNS record that tells the world “reject email that isn’t really from me.” Without it (or with the monitor-only p=none), anyone can send email that looks exactly like it came from the domain: phishing its customers, invoicing its finance team, impersonating its brand. We measure this passively over public DNS — no mail sent, nothing connected to.

Check your domain — free →How it works

What the radar is seeing

1,969,686
Domains checked
1,714,599
Can be spoofed (no / monitor-only DMARC)
87%
…that's this share of all checked
84,332
Fully protected (DMARC p=reject)

Why this matters

SPF and DKIM aren’t enough on their own — only an enforcing DMARC policy stops someone forging the visible From: address your recipients actually see:

  • • Business Email Compromise & invoice fraud — attackers email your finance team or customers as you, and the messages land in the inbox.
  • • Phishing that passes every visual check — the sender domain is genuinely yours; there’s nothing for a user to spot.
  • • Even domains that send no email are at risk — a parked or product domain with no DMARC can still be impersonated.

The fix is free and DNS-only: publish a DMARC record and move it to p=reject.

By TLD — where it's worst

  • .com709,019 spoofable of 836,501 (85%)
  • .ph117,202 spoofable of 117,359 (100%)
  • .xyz76,588 spoofable of 78,387 (98%)
  • .net63,719 spoofable of 72,206 (88%)
  • .org55,462 spoofable of 63,696 (87%)
  • .de41,435 spoofable of 49,192 (84%)
  • .uk37,057 spoofable of 45,374 (82%)
  • .top21,962 spoofable of 22,330 (98%)
  • .br20,318 spoofable of 23,786 (85%)
  • .cn19,083 spoofable of 19,900 (96%)
  • .au18,760 spoofable of 22,950 (82%)
  • .ru18,544 spoofable of 20,000 (93%)

Are you exposed?

Check whether your domain can be spoofed — a free, passive look at your SPF/DMARC posture and the rest of your internet-facing surface, no signup.

Check your exposure →

How it works

How do you check this without sending email?

Purely from public DNS. We resolve the domain’s TXT record for SPF, its _dmarc TXT record for DMARC, and its MX records — the same lookups any mail server makes. We never send mail, connect to anything, or log in.

When do you call a domain “spoofable”?

When there is no DMARC record, or DMARC is set to p=none (monitor-only, no enforcement). Those are the cases where forged mail is actually delivered. p=quarantine we count as partial; p=reject as fully protected.

Why don't you list the spoofable domains?

Publishing them would be a ready-made target list for phishers. We keep domain names private for responsible disclosure to the owners and publish only aggregate counts. Use the scanner above to check your own domain.

Aggregates only. Passive, read-only DNS resolution; no mail sent; domain names withheld; affected owners notified via responsible disclosure — see our full Responsible Disclosure & Data Handling policy.Last check completed Mon, 02 Nov 2026 01:19:12 GMT.
Seeing this scanner in your logs? It's us. Our Discovery Radars name themselves — like Googlebot — in the User-Agent of every HTTP request they send, for example EchelonGraph-<Radar>/1.0 (+https://echelongraph.io/surface-scanner; opt-out https://echelongraph.io/responsible-disclosure; support@echelongraph.io) or, from our radar prober, EchelonGraphBot/1.0 (+https://echelongraph.io/bot), and their HTTP requests to the hosts they check also carry a From: support@echelongraph.io header. Some checks are a single identified GET; others send several requests to one host. Confirming an MCP endpoint sends a POST asking the server which protocol versions it supports, a second POST with the older handshake only if the first is refused without a 2026-07-28 error, a DELETE to close any session a POST opened and, if a POST is refused with HTTP 401 or 403, up to two GETs of the server's OAuth protected-resource metadata on the same host; where neither POST finds an MCP endpoint, the older SSE transport's stream is requested with GET, only its first event is read, and the connection is closed. A server that answers the first POST with a DiscoverResult, or with an error the 2026-07-28 revision defines, opens no session and is sent no further POST, so it is not written to; if the POST is refused with HTTP 401 or 403, the metadata GETs above still follow. Confirming an exposed datastore needs a protocol-level exchange, and on Redis our client names itself so the connection is identifiable in your own CLIENT LIST. We never log in, submit credentials or exploit what we find. Who we are, exactly what each check sends, and how to opt out → A radar's HTTP requests to the host it checks also carry a signed receipt you can validate at /verify-scan.