Apex domain to assess, e.g. acme.com. Default example.com.
Passive DNS only — no mail is sent.
How It Works
subfinder finds subdomains; each is a potential sending identity.
posture queries SPF, DKIM, DMARC, MTA-STS, and BIMI over DoH (distributed).
score walks the DMARC org tree — a child with no record inherits the apex sp= / p=. That is the difference between “looks unprotected” and actually spoofable.
Results
Dark PDF plus the email-posture live table: per-domain spoofing exposure, DNS records, and what to publish to close the gap.
Overview
Email authentication is configured once, usually by whoever set up the mail
provider, and then inherited by every subdomain nobody thought about. The apex
has a strict DMARC policy. The subdomain used by a marketing tool three years ago
has none, and it is just as usable for sending mail that appears to come from you.
This checks the whole tree rather than the apex. You get every subdomain's SPF,
DKIM, DMARC, MTA-STS and BIMI state, resolved the way a receiving mail server
resolves it, and a spoofability verdict per host. The result is a list of the
names an attacker could send as today, which is the fix list. Because it is DNS
only, it is passive and cheap to repeat, so it belongs on a schedule next to the
rest of your exposure management. Every
subdomain a team stands up arrives with whatever mail posture it inherited, and
the gap is worth catching before somebody else finds it.
No mail is sent at any point.
Pipeline
Read the target domain.
subfinder enumerates subdomains, because policy is
inherited per name and gaps live below the apex.
The check list is built from the apex plus every discovered subdomain.
SPF, DKIM, DMARC, MTA-STS and BIMI records are queried over DNS for each name,
distributed across the fleet, following the DMARC organizational tree-walk.
Each name is scored for spoofability from its resolved policy.
The exposure list is written to a PDF report.
Inputs
Target domain. The apex to assess. Subdomain enumeration expands it, so
you name one domain rather than assembling the list of names to check, which is
the list you would have got wrong anyway.
Check list. The apex plus every discovered subdomain, deduped and capped
before the sweep runs, so an over-enumerated domain does not turn into an
unbounded set of lookups.
Credentials. None. Every check is a DNS query, so there is no mail
provider to authenticate against and no API token to supply.
Outputs
Per-name posture. The SPF, DKIM, DMARC, MTA-STS and BIMI state resolved
for every name in the check list, not only the apex.
Spoofability verdict. One per name, decided from the policy that actually
applies to it after the DMARC organizational tree-walk rather than from the
records published under that name.
Remediation notes. What to publish, per domain, so the report doubles as
the ticket.
PDF report. The exposure list and the remediation in one file you can
send to whoever owns DNS.
Sample output
Illustrative, in the record shape the workflow emits. The run this was modelled
on was against a third party's live mail domain, so the names are replaced with
documentation domains.
Each name carries the effective policy a receiver would apply, not just the record
on the name itself:
domain
is_apex
verdict
effective_policy
own_dmarc
dmarc_policy
spf
has_mx
dkim
bimi
reasons
risk
example.com
true
protected
reject
true
reject
softfail
true
selector1, k1, k2
true
—
null
www.example.com
false
protected
reject
false
null
inherit
false
—
null
—
null
mail.example.com
false
protected
reject
false
null
strict
true
selector1
null
—
null
access.example.com
false
spoofable
none
true
none
strict
true
default
null
DMARC policy p=none (monitor only)
4
status.example.com
false
protected
reject
false
null
inherit
false
—
null
—
null
marketing.example.com
false
spoofable
none
true
none
softfail
true
—
null
DMARC policy p=none (monitor only), No DKIM selectors found
3
subfinder expands that apex to every name it can find. Most
of them publish no DMARC record of their own and inherit the apex p=reject,
which is what you want. The ones worth your attention publish a record that
enforces nothing, and so opt themselves back out of the protection the apex
bought.
The tree-walk is what produced those verdicts. Sibling names with no record of
their own inherit p=reject from the apex and score as protected; the one above
overrides that inheritance with p=none and reopens itself. Reading each name's
records in isolation gets both cases wrong, which is why the sweep resolves
policy down the tree rather than per name.
FAQ
Does it send any email?
No. Every check is a DNS lookup, so nothing is delivered, no test message lands
in anybody's inbox, and the target's mail servers are never contacted.
What is the DMARC organizational tree-walk?
It is how a receiving mail server decides which DMARC policy applies to a name.
If the name publishes no record of its own, the receiver walks up to the
organizational domain and applies its policy, or its subdomain policy where one
is set. Reading each name's own records in isolation therefore produces the wrong
answer twice over: it reports a protected subdomain as unprotected, and it misses
that a permissive subdomain policy at the apex reopens every name below it.
Do you need access to the mail provider?
No. There are no credentials and no API token anywhere in the run, which is also
why the same check works against a domain you do not administer.
Why check subdomains when mail comes from the apex?
Because a receiver does not care where you intended mail to come from. Any name
that resolves is a name somebody can try to send as, and the ones set up years
ago for a marketing tool or a status page are exactly the ones nobody revisited.
Related workflows
Typosquat & Look-alike Domain Scanner.
Reach for this instead when the phishing risk is a domain that merely resembles
yours rather than mail forged from a name you own.
Domain OSINT & Footprinting. Reach
for this instead when you want the full DNS and certificate picture, not only
the mail-authentication slice of it.
Find Subdomain Takeovers. Reach for
this instead when the concern is a subdomain an attacker can claim outright
rather than mail they can forge.