Testing whether a domain can be spoofed

How to read the result

If all three answers are favorable (p=reject or p=quarantine, with sp/np covered): the exact domain isn't directly spoofable. That's a good foundation, but not a total guarantee — regular checks that the configuration hasn't drifted (new unaligned source, DNS provider change) remain necessary, as does monitoring of the side vectors mentioned above, since none of them are covered by this test alone.

If a record exists but at p=none: the domain sits in observation mode, a legitimate deployment stage — but it remains technically spoofable until the policy is hardened. That's not urgent while a source inventory is being built methodically (see getting to p=reject without breaking legitimate email), but it's not protection either, and shouldn't be mistaken for it in a status report to leadership.

If no record exists at all: the domain is spoofable with zero barrier, exactly as if DMARC had never existed. It's the most common case among organizations that simply never heard of the topic — and the good news is the first step (publishing a record at p=none) is free, immediate, and requires no vendor, no software, and no budget approval to start.

Why this test needs repeating, not doing once

A domain properly protected today can become vulnerable again tomorrow, for reasons that have nothing to do with an attack: a DNS host change that accidentally wipes the record, an email platform migration that alters SPF configuration without touching DMARC, or a simple mistake during technical maintenance. That's why this spoofability test deserves to be repeated periodically, not just run once during initial compliance work — ideally after every email infrastructure change, and at regular intervals even with no known change, since silent drift is the whole point of the risk.

In practice, the simplest way to make the habit stick is to give the test an explicit owner and a calendar slot: a quarterly reminder assigned to whoever administers DNS, plus a one-line entry in the checklist of every email-related change ticket — new marketing platform, CRM migration, DNS host switch. Each check takes minutes, so there is no real trade-off to weigh. Organizations that fold the check into routine change management catch a regression within days; those that treated it as a one-time audit item tend to discover the drift months later, through an incident report rather than a scheduled review — the most expensive possible way to learn it.

Why this test precedes any other email security discussion

A common trap in organizations starting to care about email security: jumping straight to sophisticated discussions — whether to set up BIMI, which lookalike-domain monitoring service to pick, how to train teams against CEO fraud — without having checked this basic three-question test. It's a costly prioritization mistake: all these advanced measures implicitly assume direct spoofing of the exact domain is already closed. Investing time and budget in lookalike-domain monitoring while the main domain stays open is like installing a sophisticated alarm on the windows of a house whose front door isn't even locked — technically impressive, practically useless against the easiest way in.

That's why this test belongs at the very first step of any email security discussion in an organization — before budget, before choosing tools, before even deciding who owns the project internally. The answer conditions everything that follows, including whether those other conversations are worth having yet.

A sample result, line by line

To make this test tangible, here's how a real DMARC record reads, line by line — the kind returned by a query on _dmarc.example-company.com:

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@example-company.com

Each tag reveals a piece of the picture. v=DMARC1 confirms a valid DMARC record exists — first question answered positively. p=quarantine indicates partial enforcement on the root domain — second question, mixed answer: it's not none (so not completely open), but it's not reject either (so not maximum protection). sp=none is the most revealing detail here: subdomains have no enforcing policy at all — third question, clearly unfavorable answer. An attacker who fails to spoof the root domain (thanks to quarantine) can easily fall back to a subdomain, where sp=none leaves the field wide open, with no further work required on their part.

This kind of in-between configuration — neither fully open nor fully closed — is actually very common, and illustrates well why the test's three questions must be asked together: a favorable answer to one says nothing about the other two.

The case of domains that never send email

An angle often forgotten in this test: what of the domains an organization owns but that never send mail — defensive brands, old product names, domains reserved out of caution? The answer to the spoofability test for these domains should always be "maximally protected," and immediately, with no observation phase. Since no legitimate email ever leaves them, there's strictly zero false-positive risk in publishing p=reject; sp=reject; np=reject directly on a parked domain, with no observation window needed first. It's often the fastest fix on this whole list: a few minutes of DNS configuration, with no monitoring period required beforehand, unlike an active domain where inventorying legitimate sources takes real calendar time. Many organizations discover, while doing this inventory, that they own far more dormant domains than they thought — old brand names, domains acquired in a merger and never cleaned up since, defensively reserved variants — and that each one sat wide open for years, a free target nobody was watching until this exercise brought it back into view.

Doing the test in practice

Manually checking these three points means querying the domain's DNS records with a lookup tool (dig, or the DNS host's interface), then interpreting DMARC syntax — accessible, but requiring a minimum of technical familiarity to avoid getting a syntax detail wrong and drawing the wrong conclusion from it.

The fastest and most reliable method remains running the domain through the free DMARC analyzer, which performs these three checks automatically and returns a clear result in seconds — current policy, subdomain coverage, and source alignment if a record already exists. It's the equivalent of a vulnerability scanner, but for one precise, fundamental question: can this domain be spoofed today? Unlike a generic vulnerability scanner that produces a long list of results to sort through and prioritize, this test gives a directly actionable answer, requiring no expertise to interpret and no further triage before deciding what to fix first.

In summary

Knowing whether a domain is spoofable requires neither deep expertise nor a lengthy audit — three factual questions suffice: does a DMARC record exist, at what policy, and are subdomains covered. It's the starting point of any anti-spoofing strategy, and the question to ask again regularly, not just at the launch of an email security project — a domain correctly configured today is no guarantee it stays that way tomorrow without ongoing monitoring. A test that takes three minutes today can prevent an incident that will take far more than three minutes to resolve — in time, money, and customer trust to rebuild, none of which come back as quickly as they were lost.