You configured SPF, DKIM and DMARC on the domain you send mail from. Good. You also own eleven other domains: the misspellings you registered defensively, the two from an acquisition, the country variants, the one for a product that never launched, and the redirect for a campaign in 2021.
None of them has any email authentication at all, which means anyone can send mail that appears to come from them. Those are your brand, and they are unprotected precisely because nobody sends from them and so nobody configured them.
This post is what a domain you never send from needs, and how to find the ones you forgot. For whoever owns the DNS.
Why a non-sending domain is the attractive target
An attacker spoofing your primary domain hits DMARC and the mail is rejected or quarantined. An attacker spoofing a domain with no DMARC record has nothing in the way, and receiving mail servers have no policy to apply.
The domains most useful for that are the ones closest to your real one: the misspelling you registered to protect yourself, the hyphenated variant, the .co version. Registering them defensively and then leaving them unauthenticated turns a protective measure into a convenient launchpad, because the recipient sees something that looks right and the mail passes every check that exists.
The same applies to subdomains, which are a larger surface than most people track.
What a non-sending domain needs
Three records, and they are short. This tells the world that nothing legitimate ever comes from here.
An SPF record that authorises nobody:
example-parked.com. TXT "v=spf1 -all"
A DMARC record with the strictest policy:
_dmarc.example-parked.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourcompany.com"
Note sp=reject, which applies to subdomains. A DMARC record without it may leave subdomains covered by a weaker inherited policy than you intended, and subdomains are where this gets exploited because nobody enumerates them.
A DKIM record that revokes any key:
*._domainkey.example-parked.com. TXT "v=DKIM1; p="
An empty p= means the key is revoked, so any signature claiming to be from this domain fails.
Optionally a null MX, saying this domain receives no mail either:
example-parked.com. MX 0 .
That is four short records per domain, and they can be templated and applied in bulk.
Do the same for subdomains you do not send from
The usual configuration protects the organisational domain and leaves subdomains to inherit. Whether inheritance applies, and with what policy, depends on your sp value, and the default is not what most people assume.
Set sp=reject on the organisational domain unless you have subdomains that genuinely send, and for those, give them their own explicit records rather than relying on inheritance.
The subdomain case matters because attackers use plausible ones: billing.yourcompany.com, secure-yourcompany.com, mail.yourcompany.com. The first is a real subdomain of your real domain, and if your policy does not cover it, the mail authenticates as far as the receiver is concerned.
Find the domains you forgot
You own more than you think, and the list lives in three places that disagree.
Your registrar accounts. All of them, including the one somebody opened with a personal card for a campaign.
Finance. Recurring renewal charges. This is the most reliable source, for the same reason it is the reliable source for subprocessors and contractors: nobody forgets to pay.
Certificate transparency logs. Every certificate issued for a name you control is public. Searching those finds subdomains and domains nobody remembers:
curl -s "https://crt.sh/?q=%25.yourcompany.com&output=json" \
| jq -r '.[].name_value' | tr '[:upper:]' '[:lower:]' | sort -u | head -50
That last one routinely finds hosts nobody on the current team has heard of, which is useful beyond email: it is also your subdomain takeover candidate list.
Then check what you found
for d in $(cat domains.txt); do
spf=$(dig +short TXT "$d" | grep -c 'v=spf1')
dmarc=$(dig +short TXT "_dmarc.$d" | grep -c 'v=DMARC1')
printf "%-40s spf=%s dmarc=%s\n" "$d" "$spf" "$dmarc"
done
Every row with zeros is a domain anyone can send as. The list is usually longer than expected, and fixing it is a bulk DNS change rather than a project.
Turn on the reporting
The rua address in the DMARC record collects aggregate reports from receiving mail servers, telling you who is sending mail claiming to be you. On a parked domain with p=reject, any volume at all is interesting, because nothing legitimate should exist.
It is the cheapest detection you will deploy: one field in a record you are already creating, and it turns each of these domains into a sensor.
The concession
A domain with no DNS records at all is already hard to spoof convincingly in some configurations, and there is a reasonable argument that the effort is better spent elsewhere. Receiving mail servers vary in how they treat a domain with no policy, and several apply heuristics that catch obvious spoofing regardless.
The counter is cost. This is four DNS records per domain, applied in bulk, with no ongoing maintenance and no risk of breaking anything, because the domain sends no mail. It is one of the few security tasks with genuinely no downside, and the reporting you get for free turns a passive measure into a detection.
The implication
Your email authentication protects the domain you thought about. The value of a spoofed domain to an attacker is that it looks right to a human, and the ones that look most right are the defensive registrations sitting unconfigured.
Pull the list from your renewal charges, add four records to each, and point the reports somewhere you will read.
