Email authentication tool

Can your domain be spoofed?

Enter a domain and get a verdict for three separate things: the domain itself, its existing subdomains, and the subdomains a spoofer invents. Each verdict names the record and tag receivers read, and the DNS change that would close the gap.

By Adam W., founder of DMARCit · Last updated 2026-10

What the verdicts mean

The question is narrow on purpose: if someone sends mail with your domain in the From address and no valid authentication, does your DMARC policy ask receivers to act on it? The answer comes from public DNS: the DMARC record that applies, the SPF record on the domain, and whether the name exists. The check never sends mail and never connects to your mail servers.

• Spoofable: no receiver is asked to act. There is no DMARC record, the policy is none, the record can't be parsed, the policy is held in test mode one level down to none, or SPF ends in +all.
• Partly protected: some receivers act and some don't. That is usually a transition artifact: a legacy pct= value, t=y without pct=0, or an np= that older receivers don't read.
• Protected: every receiver that honors DMARC is asked to quarantine or reject forged mail.

Protected is not a guarantee. DMARC policy is a request: RFC 9989 Section 5.4 leaves the final handling of every message to the receiver's local policy, and some receivers don't check DMARC at all. This page reports what you asked for, which is the part you control.

Three scopes, three tags

One DMARC record usually covers more names than people expect, with a different tag for each kind of name (RFC 9989 Section 4.7):

• The domain itself gets p= from its own record.
• Existing subdomains with no record of their own get sp= from the parent's record. When sp= is absent, p= applies.
• Subdomains that don't exist get np=, new as a core tag in RFC 9989. When np= is absent, receivers fall back to sp=, then p=.

“Doesn't exist” means the DNS answers NXDOMAIN for the name (RFC 9989 Section 3.2.13). That is where invented names like billing.example.com land. If your zone has a wildcard record, every name exists and np= never applies; the check probes a random label to spot that and falls back to sp=.

The common gap: p=reject on the domain with sp=none left over from an early rollout. The domain is covered and every subdomain is open. Receivers that don't support np= yet read sp= for invented names too.

When the name has no record of its own

Check news.example.com and there may be nothing at _dmarc.news.example.com. Receivers on RFC 9989 then walk up the DNS one label at a time, at most eight queries, and use the record at the Organizational Domain (RFC 9989 Section 4.10.1). The Organizational Domain is picked from the records the walk finds: a psd=n record marks it, a psd=y record marks a public suffix one label above it, and otherwise the record with the fewest labels wins (Section 4.10.2). The result card shows every name the walk queried and the record it landed on.

If the walk finds nothing, Section 4.10.1 is blunt: receivers MUST NOT apply DMARC to the message. The RFC 9989 guide covers the edge cases, including how psd=n on a subtree changes relaxed alignment.

Test mode and the old pct= tag

t=y asks receivers on RFC 9989 to apply one level below the published policy: p=reject is handled as quarantine, p=quarantine as none, and p=none doesn't change (Section 4.7). Receivers still on RFC 7489 have never heard of t= and ignore it.

pct= works the other way round. RFC 9989 removed it (Appendix A.6), so current receivers ignore it, while RFC 7489 receivers apply the policy to that percentage of failing mail. The rest of the mail under reject is quarantined, and the rest under quarantine gets normal filtering (RFC 7489 Section 6.6.4). That is why the check splits its answer by receiver generation: p=quarantine; pct=50 means full quarantine at one and half at the other.

pct=0 next to t=y reads as one level down at both generations, which makes it the honest test rung. The staged enforcement rollout walks through the rungs.

Why SPF alone doesn't stop spoofing

SPF authorizes servers to use a domain in the envelope sender, the MAIL FROM address used for bounces (RFC 7208 Section 2.4). The From address your recipients see is a different field. RFC 7208 says so itself: mail that passes SPF can still carry other false identities, and the From header is the example it gives (Section 11.2). A spoofer passes SPF with a domain they own and puts yours in From.

DMARC closes that gap by requiring alignment: an SPF pass only counts when the envelope domain matches the From domain (RFC 9989 Section 4.4.2). So the verdicts above are DMARC verdicts. The SPF panel still matters for your own mail. A record over 10 DNS lookups across its includes, or with more than two lookups that return nothing, is a permerror (RFC 7208 Section 4.6.4), and more than one SPF record is too (Section 4.5). Your legitimate senders lose their SPF path to a DMARC pass and lean on DKIM alone.

The one SPF setting that does open the door is +all. It authorizes every server on the internet, so a forger using your domain as the envelope sender passes SPF, aligns, and passes DMARC whatever your policy says. The SPF guide covers the qualifiers and the lookup budget.

Fixing it without breaking your own mail

Every suggested record above is the smallest edit that moves the verdict, and none of them jumps straight to p=reject. A domain with no reports gets p=none with a rua= address first, because enforcing before you know your senders is how invoices end up in spam. Quarantine is offered as a place you can stop, and reject only with a warning: RFC 9989 says domains whose users post to mailing lists SHOULD NOT publish p=reject, and domains that do MUST sign with DKIM (Section 7.4).

The trade-off between the two enforcing policies is in p=quarantine vs p=reject. To see the record you're publishing tag by tag, with next steps for reporting and syntax, run the DMARC checker.