Parked Domains: Locking Down the Ones That Send Nothing

Your main domain is at p=reject. Your RUA reports are clean. You review your sending sources every week.

Meanwhile, old-brand.com, acquired in 2019, redirected to your website and forgotten ever since, has no authentication records at all. Anyone can send in its name. Nobody will notice.

A domain that sends nothing is not a domain without risk. It is a domain without a witness: no legitimate recipient will tell you something is wrong, no campaign will bounce, no customer will raise an eyebrow. An attacker looking for a credible name to impersonate will pick your dormant domain over your already-locked main domain every single time.

This article covers the complete configuration for a domain with no outbound mail, including the part most guides skip entirely: how DNS wildcards actually behave.

Step 1: Take Inventory Before Locking Down

Find All Your Domains

The hard part is not technical, it is organizational. Domains accumulate across several registrar accounts, often registered by people who left years ago.

Four sources to cross-reference:

• Registrar exports, account by account. Expect to find one you had forgotten.
• Accounting records: domain renewals are recurring invoice lines and easy to filter.
• Certificate Transparency logs (crt.sh): every publicly issued TLS certificate shows up there, including for domains you no longer remember.
• Your web redirects: a domain redirecting to your main site is a domain you own, and almost certainly one you never configured for email.

Three Profiles, Three Configurations

A domain hosting a website or a redirect falls into profile A or B depending on its mailbox: the presence of an A or AAAA record changes nothing about the email configuration. It does matter on the receiving side, though, because some servers check that a domain “exists” by looking for an MX, falling back to an A or AAAA. A domain answering over HTTP therefore passes that existence test even though no message could ever be delivered to it, which is exactly what null MX is for.

Profile C is the only real trap. An old contact form, a legacy billing tool, a monitoring probe still alerting from the old domain: the flow exists, it is tiny, and nobody remembers it.

The Two-Week Rule

Even for a domain you are certain is dead, publish a DMARC record at p=none with a rua address first, and wait two weeks.

_dmarc.old-brand.com  TXT  "v=DMARC1; p=none; rua=mailto:a1b2c3d4@rua.senderaudit.com"

It costs nothing, no email is affected, and it is exactly what prevents you from cutting off a profile C flow without knowing. If after two weeks the reports show only unknown sources, lock it down with confidence. If they show a server you own, you just avoided an incident.

The address above is a Sender Audit collection address. Generate your own in one line: it is live immediately and saves you from provisioning a dedicated mailbox somewhere just to pile up XML. Collection starts without signing up, but reading the reports, analyzing them and receiving alerts require a free account: link the address to one before you start your two weeks, otherwise you will spend them waiting outside a locked door. The next section explains why that choice also solves a DNS problem most people discover far too late.

Step 2: The Four Records That Lock a Domain

SPF: v=spf1 -all

old-brand.com  TXT  "v=spf1 -all"

Translation: no server on earth is authorized to send for this domain.

Two details that matter:

• -all, not ~all. Softfail exists for migrations, when you are not yet sure you have found every sending source. On a dead domain, that uncertainty does not exist. Use hardfail.
• SPF works even without DMARC. SPF is evaluated against the MAIL FROM domain and the HELO name, independently of DMARC. Your -all therefore also protects you against receiving servers that do not implement DMARC, which is still a meaningful share of the installed base.

For syntax details, see the SPF guide.

DKIM: Revoke Every Selector at Once

This is the part almost no guide covers, and it fits in one line.

RFC 6376, section 3.6.1 states that an empty p= value means the public key has been revoked. A DKIM record with an empty p= is not a broken record, it is an explicit revocation.

Combined with a wildcard:

*._domainkey.old-brand.com  TXT  "v=DKIM1; p="

Translation: whatever the selector, the key is revoked. An attacker inventing mail._domainkey, default._domainkey or any other name gets a revocation, never a usable key. You do not have to guess which selectors they will try.

On how signatures and selectors work, see the DKIM guide and the anatomy of a DKIM signature.

DMARC: p=reject, and Definitely Not p= Alone

_dmarc.old-brand.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

Three tags, three distinct scopes:

np= arrived with DMARCbis and it is exactly the tag for this situation: on a parked domain, every conceivable subdomain is non-existent. See the DMARCbis practical guide for the details.

Where to Send the Reports, and Why It Matters

The parked domain receives nothing, so the rua has to point somewhere else. This is where most configurations fail silently.

A rua pointing to a domain other than the one carrying the DMARC policy is a cross-domain report request. The specification requires the destination domain to explicitly declare that it accepts reports for that specific domain:

old-brand.com._report._dmarc.your-main-domain.com  TXT  "v=DMARC1"

This is the single most forgotten record in the entire DMARC ecosystem, and its absence produces no error message at all: reporting servers simply decline to send, and three weeks later you conclude that nobody is spoofing you. Worse, you need one record per monitored domain. Ten parked domains, ten records to publish, and one more thing to forget at the next brand acquisition.

Let Sender Audit Collect the Reports

That is precisely the problem a collection address removes:

_dmarc.old-brand.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

The cross-domain authorization is already published on the Sender Audit side, as a wildcard, for every domain. You add nothing to your own zone, no matter how many domains you point at it. Check it yourself:

dig +short TXT old-brand.com._report._dmarc.rua.senderaudit.com

You get "v=DMARC1;" for any domain you put in front. One less line per domain, and one less silent failure mode.

The rest follows: aggregate reports arrive as compressed XML, unreadable by eye, and get parsed, deduplicated and attributed to an identified source. On a parked domain the point is not the dashboard, it is the alert: expected volume is zero, so the first line that shows up is a signal, not noise to sort through.

Generating a collection address takes one line. Collection begins as soon as the address is published, even without signing up, but reading the reports, getting alerted and tracking several domains over time require a free account the address is linked to.

One ordering detail that matters: do that linking before you publish the null MX. With no linked account, the notification telling you the first reports have arrived goes to the contact@ address of the domain in question, and that domain is precisely the one you just made incapable of receiving anything.

Null MX: MX 0 .

old-brand.com  MX  0 .

RFC 7505 defines this record as a formal declaration: this domain accepts no email.

The benefit is concrete. Without it, a server trying to deliver a message to you (often backscatter, the bounce of a spam run spoofing your domain) will retry for five days before giving up. With a null MX, it gives up immediately with a permanent error.

⚠️ Profile A only. Null MX also kills legitimate reception. If even one address is still monitored on that domain, do not publish it.

Step 3: The DNS Wildcard Trap

You might be tempted to cover every subdomain in one shot:

*.old-brand.com  TXT  "v=spf1 -all"

It looks economical. In practice it produces behavior few people anticipate.

A DNS Wildcard Does Not Stop at One Level

Contrary to intuition, *.example.com does not only cover foo.example.com. RFC 4592 defines wildcard synthesis from the closest encloser present in the zone. If nothing sits between the wildcard and the queried name, the wildcard answers, regardless of how many labels are involved.

Concretely, with only the wildcard above published:

A DKIM query gets answered with an SPF record. It is not catastrophic (a receiver discards any record not starting with v=DKIM1 or v=DMARC1 and concludes there is none), but it is messy, and above all it is a nightmare to diagnose: your testing tools will report “invalid” records at names where you believed you had published nothing.

The Fix Is Elegant

Publishing the DKIM wildcard shown earlier solves the problem on its own:

*._domainkey.old-brand.com  TXT  "v=DKIM1; p="

Creating that name also creates the intermediate node _domainkey.old-brand.com in the zone. That node becomes the closest encloser for any DKIM query, and therefore takes precedence over the broad wildcard. Every selector._domainkey lookup now returns the revocation, never the SPF record again.

In other words: the two wildcards are not redundant. The more specific one protects the broader one from its own side effects.

Four Practical Consequences

1. Always publish _dmarc explicitly. Without an explicit record, the wildcard answers in its place with content that is not DMARC. An explicit record always beats a wildcard.
2. Your ownership verifications keep working. Google Search Console, ACME _acme-challenge challenges: as soon as an explicit record exists at that name, the wildcard is not used at all.
3. Not every DNS host cooperates. Wildcard TXT records, names starting with an underscore, null MX: some control panels refuse one or the other. If the DKIM wildcard is impossible, publish at least the most common selectors (default, mail, selector1, selector2, google, k1) with an empty p=.
4. Watch your TTLs while rolling this out. A long TTL on a wrong record costs you hours of waiting on every correction.

The Complete Zone

Profile A: Sends Nothing, Receives Nothing

old-brand.com                TXT  "v=spf1 -all"
old-brand.com                MX   0 .
*._domainkey.old-brand.com   TXT  "v=DKIM1; p="
_dmarc.old-brand.com         TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"
*.old-brand.com              TXT  "v=spf1 -all"
*.old-brand.com              MX   0 .

Six lines, with nothing to publish anywhere else: the cross-domain reporting authorization is carried by the collection domain. If you would rather receive reports in a mailbox of your own, add old-brand.com._report._dmarc.yourdomain.com TXT "v=DMARC1" to your zone, and repeat for every parked domain.

Profile B: Still Receives Mail but Sends Nothing

Identical, without the two MX 0 . lines, keeping your real MX records.

Several Domains: Centralize the Policy

If you are locking down ten domains, duplicating the same _dmarc record ten times guarantees they will drift apart eventually. DNS lets you maintain a single one and point all the others at it:

_dmarc.old-brand.com    CNAME  _dmarc.parked.yourdomain.com.
_dmarc.other-brand.com  CNAME  _dmarc.parked.yourdomain.com.
_dmarc.parked.yourdomain.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

One record to maintain, and reports stay attributed to the right domain, since it is the spoofed domain, not the CNAME target, that appears in the report.

The SOA, the Only Way Left to Reach You

Almost always forgotten. Once the null MX is published, postmaster@ and abuse@ on that domain no longer exist, even though RFC 2142 makes them the expected contact points. One place in DNS still says who to talk to: the SOA RNAME field.

old-brand.com  SOA  ns.yourdomain.com. hostmaster.yourdomain.com. 2026082900 3600 7200 86400 86400

The second field, hostmaster.yourdomain.com., reads as hostmaster@yourdomain.com, on a domain that actually receives mail. It is the only channel a security researcher or a blocklist operator will have to report a problem on this domain.

The four values that follow are the timers worth using on a parked domain: refresh one hour, retry two hours, expire one day, minimum TTL one day. A zone that never changes does not need to be asked about often.

Verify

dig +short TXT old-brand.com
dig +short TXT _dmarc.old-brand.com
dig +short TXT test._domainkey.old-brand.com
dig +short MX old-brand.com

The third command is the most informative: the test selector does not exist, and that is precisely the point. You should get back v=DKIM1; p=. If you see v=spf1 -all, your DKIM wildcard is not published.

For a full check, scan the domain on senderaudit.com: SPF, DKIM, DMARC, MX and overall consistency are verified in a single pass.

What About Dormant Subdomains on an Active Domain?

You may not own a single parked domain. You almost certainly own unused subdomains, and the reasoning is identical.

mail.example.com, smtp.example.com, webmail.example.com, mx.example.com: these names send nothing for you, but they look trustworthy to a hurried reader. They are obvious targets.

The good news is that you do not need to publish anything subdomain by subdomain. On the main domain:

_dmarc.example.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

np=reject covers, in one record, every subdomain that does not exist in your zone, including the ones an attacker will invent tomorrow.

One caveat: if you create subdomains dynamically (staging environments, per-customer subdomains), start at np=quarantine and watch your reports before tightening.

What This Does Not Protect Against

Let us be honest about scope. Once your parked domain is locked, an attacker still has two options:

• Lookalike domains. old-brand-billing.com is not yours, your DMARC policy has no reach over it, and it will authenticate perfectly for whoever owns it.
• The display name. Nothing stops anyone from sending from random@gmail.com with “Old Brand Billing Department” as the sender name. On mobile, many mail clients show nothing but that name.

Locking your domains reduces the attack surface, it does not eliminate it. It is necessary, it is not sufficient.

Checklist

Before locking down

• Complete domain inventory (registrar, accounting, crt.sh, redirects)
• Profile determined for each domain (A, B or C)
• p=none with rua published for at least two weeks
• RUA reports reviewed, no legitimate source identified
• Report destination actually working: a Sender Audit collection address, or a _report._dmarc authorization published on your own receiving domain

The lockdown

• v=spf1 -all on the domain
• v=spf1 -all on the wildcard
• *._domainkey with v=DKIM1; p=
• Explicit _dmarc at p=reject; sp=reject; np=reject
• MX 0 . on the domain and on the wildcard (profile A only)
• SOA RNAME pointing at a genuinely monitored mailbox, on another domain
• dig verification of all four records, including the non-existent DKIM selector

Afterwards

• Auto-renewal enabled at the registrar
• Alerting enabled on the parked domain: any report received should reach you, not wait for your next visit

Conclusion

A parked domain is locked with four DNS records, once, with no maintenance afterwards. The only real work happens upstream: knowing which domains you own, and confirming they truly send nothing before you close the door.

Keep the rua in place after locking down. It feels counterintuitive on a domain that sends nothing, but that is exactly where it becomes interesting: any report you receive can only be the trace of an impersonation attempt. On an active domain you have to separate legitimate from illegitimate. On a parked domain, everything that shows up is suspicious by construction.

It is the only witness you will ever have on those domains. Do not unplug it, and do not point it at a mailbox nobody opens either: on a parked domain, an unread report and an unmonitored domain amount to the same thing.

To audit a domain, parked or active, run a scan on senderaudit.com. To collect its DMARC reports and get alerted at the first sign of spoofing, generate a collection address.