How can I implement a DMARC reject policy for non-existent domains to prevent spam?
Published 15 May 2025
Updated 11 Jun 2026
10 min read
Summarize with
Updated on June 11, 2026: We updated this guide for the published DMARCbis RFCs: RFC 9989 for DMARC, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. We clarified active tag guidance for np, psd, and t, and historic guidance for pct, rf, and ri.
The direct answer is: if you control the domain, publish a DMARC TXT record with p=reject, sp=reject, and np=reject. If the domain literally does not exist, or it is under a registry hold where nameservers no longer resolve, you cannot publish a DMARC record on that domain. The only standards-based way to cover that name is a parent or public suffix policy, usually published by the registry or public suffix operator, with psd=y and np=reject.
That caveat matters because DMARC is a DNS-published preference, not a central kill switch. A receiver has to find the right policy, test SPF or DKIM against the visible From domain, and then decide whether to apply the reject request. I still treat reject as the right target, but I do not treat it as the only control.
For owned domains, Suped's DMARC monitoring workflow helps find every legitimate sender before reject is enforced. For typo domains, dormant domains, and non-sending domains, the same monitoring habit helps prove that nothing valid breaks when the policy gets stricter.
Short answer
I implement non-existent-domain protection in layers. DMARC handles mail that claims a From domain under a policy domain. DNS controls whether the receiver can find that policy. Registry status controls whether you can publish any records at all. Receiver behavior controls the final outcome.
- Owned domain: Publish p=reject at _dmarc after every real sender passes DMARC.
- Subdomain coverage: Add sp=reject so failing mail using existing subdomains gets the same treatment.
- Non-existent names: Add np=reject to state the policy for NXDOMAIN subdomains under your policy domain.
- Whole missing domains: Ask the public suffix operator to publish PSD DMARC, or register the domain and publish no-send records.
The common trap
If a domain is on a registry hold and its nameservers do not resolve, you cannot add DMARC, SPF, DKIM, or MX records there until the domain returns to working DNS. In that state, rejection depends on receiver-side DNS checks or a valid parent policy.
How non-existent domain policy works
RFC 9989 now defines DMARC and obsoletes RFC 7489 and RFC 9091. It keeps the np tag as an active DMARC policy tag for non-existent subdomains. RFC 9990 now defines aggregate reporting, and RFC 9991 defines failure reporting. The np tag applies to non-existent subdomains under the policy domain. If np is absent, receivers that follow RFC 9989 apply sp if present, otherwise p. I still publish np=reject explicitly because it removes ambiguity for newer validators and documents intent for future audits.
Flowchart showing how DMARC selects policy for non-existent subdomains.
The difference between non-existent subdomains and whole non-existent domains is the detail people miss. If someone sends as billing.random.example.com and example.com exists, the receiver can use the DNS Tree Walk and find the policy at example.com. If someone sends as a completely unregistered second-level domain, the operator of the parent public suffix has to publish and receivers have to honor that parent policy.
What you control
- Registered domains: You can publish SPF, DKIM selectors, DMARC policy, and reporting addresses.
- Dormant domains: You can publish no-send SPF and DMARC reject without setting up mailboxes.
- Owned subdomains: You can publish explicit records or let the parent policy handle them.
- Typo domains: You can register high-risk variants and publish no-send records.
What you do not control
- Unregistered domains: You cannot publish records unless you register the domain.
- Registry holds: You cannot fix DNS while the registry prevents nameserver resolution.
- Public suffixes: Only the suffix operator can publish PSD DMARC for the suffix.
- Receiver choices: The inbound mail server decides whether to honor the reject request.
The DNS records to publish
For a domain you own, the practical setup is straightforward. Start with an inventory of legitimate sending systems. Fix each sender so SPF or DKIM passes and the authenticated domain matches the visible From domain. Then publish reject at the organizational domain and add explicit subdomain and non-existent-name policy.
|
|
|
|---|---|---|
Active domain | p=reject | Reject failing mail using the domain. |
Subdomains | sp=reject | Reject failing mail using existing subdomains. |
NXDOMAIN | np=reject | Reject failing mail using missing subdomains. |
Public suffix | psd=y | Let the suffix publish policy for its namespace. |
Compact policy choices for owned, dormant, and public suffix domains.
RFC 9989 changed DMARC tag guidance. Do not add pct, rf, or ri to new records. pct is historic; use t=y only when you want to signal testing mode. rf and ri are historic because aggregate reporting is specified in RFC 9990 and failure reporting is specified in RFC 9991. np, psd, and t are active tags, but psd=y belongs only on public suffix DMARC records.
Active domain DMARC recordDNS
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject;" "np=reject; adkim=s; aspf=s;" "rua=mailto:dmarc@example.com"
Strict DKIM and SPF domain matching are optional in DMARC, but I prefer them on high-risk defensive domains because relaxed matching expands what counts as the same organizational domain. For everyday production domains, strict mode needs a sender-by-sender check first.
No-send domain recordsDNS
example.com. MX 0 . example.com. TXT "v=spf1 -all" _dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject;" "np=reject; rua=mailto:dmarc@example.com"
For domains that never send mail, the SPF record says no IP is authorized, the null MX says the domain does not accept inbound mail, and DMARC tells receivers to reject mail that fails DMARC. DKIM does not need a default record. DKIM selectors only exist when a sender signs with a selector.
Public suffix operator exampleDNS
_dmarc.gov. TXT "v=DMARC1; p=reject; sp=none; np=reject;" "psd=y; rua=mailto:dmarc-reports@gov.example"
Do not publish psd=y on a normal organizational domain. It is for public suffix domains. If you need to create a policy safely, use a DMARC record generator, then validate it with a DMARC checker before changing DNS.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After publication, query the exact TXT name and send a real test message through each approved sender. The DNS record being valid is only half the job. The authentication result in the message header has to show that at least one mechanism passed DMARC with a matching domain.
Implementation checklist
The safest implementation path depends on whether the domain sends mail. I treat a real sending domain differently from a dormant defensive registration, because one needs sender repair and the other needs a clean no-send posture.
- Inventory first: List every owned domain, typo domain, parked domain, and subdomain used in email.
- Separate senders: Mark each domain as active sender, inbound-only, parked, defensive, or unknown.
- Monitor reports: Use RFC 9990 aggregate reports to find valid mail before reject blocks anything.
- Fix authentication: Make each sender pass SPF or DKIM with a domain that matches the visible From domain.
- Publish reject: Move the domain to reject only after real mail consistently passes DMARC.
- Keep watching: Continue monitoring for new vendors, DNS drift, and unexpected mail after enforcement.
A practical staging rule
For active mail domains, do not skip monitoring. For defensive domains that never send mail, publish no-send SPF and DMARC reject immediately, then watch reports for abuse attempts and accidental use.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped's Hosted DMARC flow is useful when the policy needs controlled staging across many domains. It lets teams manage policy changes centrally, add reporting, and reduce DNS handoffs during the move to reject.
What reject will and will not stop
A reject policy reduces direct domain spoofing, but it does not remove every abuse path. A receiver can override the requested action, quarantine instead of reject, or use local policy when DNS is broken. Some receivers also handle missing domains differently, especially when they have older DMARC discovery behavior.
Readiness for p=reject
Use aggregate report data to judge whether enforcement is ready.
Ready
0-1%
All known production mail passes DMARC.
Review
1-5%
A small number of known senders still need fixes.
Unsafe
5%+
Legitimate mail is still failing regularly.
Unknown
No data
No reliable report data exists yet.
For non-existent whole domains, reject is not something you can add after the fact unless you can make the domain exist in DNS. The practical options are to register the high-risk variant, ask the registry or public suffix operator to publish PSD DMARC, or report abusive traffic to receiving networks.
This is also where blocklist (blacklist) and reputation monitoring can help operations teams spot abuse patterns, but those checks do not replace DMARC. They answer a different question: whether a domain or IP has a poor reputation elsewhere.
Where Suped fits
For teams managing more than a few domains, Suped's product turns raw authentication reports into domain-level fixes. The practical workflow brings together DMARC policy monitoring, SPF and DKIM visibility, hosted policy controls, blocklist (blacklist) monitoring, alerts, and multi-tenant dashboards for agencies and managed service providers.
For this exact non-existent-domain problem, the useful Suped workflow is simple: add every owned and defensive domain, confirm whether it sends mail, publish the correct reject or no-send records, and use issue detection to catch anything that breaks. That is more reliable than trying to remember which parked domains still have old vendors attached.
Manual DNS handling
- Visibility: You have to collect and parse aggregate reports yourself.
- Policy changes: Every domain change depends on DNS access and careful record editing.
- Failure triage: Broken SPF, missing DKIM, and domain mismatch issues need manual diagnosis.
- Scale: Large portfolios become hard to keep consistent.
Suped workflow
- Visibility: DMARC reports are normalized into sources, pass rates, and issue groups.
- Policy changes: Hosted policy controls reduce direct DNS editing after setup.
- Failure triage: Issues include tailored steps to fix authentication failures.
- Scale: Agencies can manage client domains in one multi-tenant dashboard.
Views from the trenches
Best practices
Publish explicit DMARC on every owned domain before relying on parent policy discovery.
Use no-send SPF and DMARC reject for parked domains that should never send mail.
Record who owns each defensive domain so DNS holds do not block urgent policy fixes.
Common pitfalls
Assuming a held or NXDOMAIN name can still accept new DNS records causes response delays.
Relying on receiver rejection for missing domains gives inconsistent protection in practice.
Publishing p=reject without checking real senders can block wanted operational messages.
Expert tips
Add np=reject to make non-existent subdomain policy explicit in each DMARC record.
Ask the public suffix operator about PSD DMARC when abuse targets an entire namespace.
Keep monitoring after reject because new vendors can create fresh DMARC failures later.
Marketer from Email Geeks says a registry hold means nameservers do not resolve, so adding DMARC records is not available until DNS works again.
2024-09-06 - Email Geeks
Marketer from Email Geeks says some receivers still accept mail that claims a non-resolving domain, so relying only on NXDOMAIN rejection leaves gaps.
2024-09-06 - Email Geeks
The practical path to reject
To prevent spam using non-existent names under domains you own, publish p=reject, sp=reject, and np=reject after confirming legitimate mail passes DMARC. For domains that never send mail, publish no-send SPF and DMARC reject now. For names you do not own and cannot publish under, push the issue to the registry or public suffix operator, or defensively register the domain if that is appropriate.
The key is not only the DNS syntax. The key is knowing which names you control, which names actually send mail, and which names need parent-level policy. That is where a monitored DMARC rollout beats a one-time DNS edit.
