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,750,978
Domains checked
1,511,965
Can be spoofed (no / monitor-only DMARC)
86%
…that's this share of all checked
77,127
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

  • .com616,340 spoofable of 738,014 (84%)
  • .ph120,457 spoofable of 120,595 (100%)
  • .xyz72,945 spoofable of 74,658 (98%)
  • .net55,584 spoofable of 63,669 (87%)
  • .org49,402 spoofable of 57,545 (86%)
  • .de33,772 spoofable of 40,250 (84%)
  • .uk31,622 spoofable of 39,526 (80%)
  • .top19,885 spoofable of 20,237 (98%)
  • .au19,225 spoofable of 23,147 (83%)
  • .br18,079 spoofable of 21,365 (85%)
  • .in15,627 spoofable of 20,736 (75%)
  • .cn15,024 spoofable of 15,670 (96%)

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 Thu, 12 Nov 2026 13:20:45 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; [email protected]) 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: [email protected] 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.