How can I implement a DMARC reject policy for non-existent domains to prevent spam?
Published 15 May 2025
Updated 22 Oct 2026
12 min read
Summarize with
Updated on 22 Oct 2026: We clarified DMARC reject inheritance and corrected the DNS examples for non-sending domains and external reporting.
If you control the domain, publish a DMARC TXT record with p=reject, sp=reject, and np=reject after checking legitimate senders. The np policy applies to non-existent subdomains that return NXDOMAIN. If the domain is unregistered, or a registry hold removes its DNS delegation, you cannot make a DMARC record discoverable there. A public suffix policy, published by the suffix operator with psd=y and np=reject, can cover the missing name when the receiver supports it.
DMARC is a DNS-published preference. A receiver has to find the applicable policy, test SPF or DKIM against the visible From domain, and then decide whether to apply the reject request. Rejection normally happens during the SMTP transaction; it does not remove spam already delivered.
For owned domains, Suped's DMARC monitoring workflow helps identify legitimate senders before reject is enforced. For typo domains, dormant domains, and non-sending domains, the same workflow helps detect accidental use and investigate unauthenticated traffic before the policy gets stricter.
Which domains you can protect
Non-existent-domain protection depends on DNS control and receiver behavior. DMARC handles mail that claims a visible From domain under an applicable policy. DNS delegation determines whether the receiver can discover that policy.
- Owned domain: Publish p=reject at _dmarc.example.com after every legitimate sender passes DMARC.
- Subdomain coverage: Add sp=reject so failing mail using existing subdomains inherits reject unless it has its own applicable policy.
- Non-existent names: Add np=reject to state the policy for subdomains that return NXDOMAIN under your organizational domain.
- Whole missing domains: Ask the public suffix operator about PSD DMARC, or register an available domain and publish no-send records.
Registry holds prevent policy discovery
A clientHold or serverHold status removes the domain from the DNS. Records stored at a DNS host are not publicly discoverable through that delegation until the hold is resolved. In that state, rejection depends on receiver-side DNS checks or an applicable public suffix policy. See ICANN's status definitions.
How non-existent domain policy works
RFC 9989 defines DMARC and obsoletes RFC 7489 and RFC 9091. RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting. The np tag applies to non-existent subdomains under the organizational domain or public suffix supplying the policy. If np is absent, receivers apply sp if present, otherwise p. Publishing np=reject explicitly documents the intended handling. On an active organizational domain, it requests rejection for missing subdomains while p=none continues monitoring the existing domain.
Flowchart showing how DMARC selects policy for non-existent subdomains.
Non-existent subdomains and whole non-existent domains need different DNS control. If someone sends as billing.random.example.com and example.com exists, an RFC 9989 receiver can use the DNS Tree Walk to find the applicable policy. If someone sends as a completely unregistered second-level domain, the public suffix operator has to publish a policy and the receiver has to honor it. A valid DMARC record at the exact From domain takes precedence over an inherited 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 inherit the applicable organizational-domain policy.
- Typo domains: You can register available 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 restore public DNS delegation while the hold remains in place.
- 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.
Missing SPF and DKIM do not bypass DMARC
An SPF result of none or neutral and a missing DKIM signature do not produce a DMARC pass. With an applicable policy, DMARC fails unless at least one mechanism passes with a domain matching the visible From domain under the configured matching rules.
For a message claiming to be from billing@missing.example.com, the receiver can apply the inherited reject policy even though missing.example.com has no SPF record or DKIM keys. SPF records do not automatically inherit, but DMARC policies can. You do not need to create every invented subdomain or publish wildcard SPF records. This pass requirement also exists in the original DMARC specification.
NXDOMAIN and NODATA are different
RFC 9989 treats a name as non-existent only when the DNS response for that name is NXDOMAIN. A NOERROR/NODATA response means the queried record type is absent but the name exists. A subdomain can therefore have no A, AAAA, or MX record and still count as existing because another DNS record is present. An empty non-terminal, a name with records below it but none at the name itself, also exists in DNS, as clarified in RFC 8020.
- NXDOMAIN: The Author Domain, the domain in the visible From header, does not exist. An applicable inherited policy uses np, then falls back to sp or p if np is absent.
- NOERROR/NODATA: The name exists, so an applicable inherited policy uses sp or falls back to p.
- Wildcard DNS: A wildcard can make an otherwise unused name return an answer, so test the exact names instead of assuming np applies.
- DNS errors: SERVFAIL and timeouts do not establish that a domain is non-existent. Receivers handle these errors separately, including temporary rejection when appropriate.
Test the DNS response code
Do not decide that a subdomain is non-existent only because it lacks an MX record or does not host a website. Check whether the exact Author Domain returns NXDOMAIN. That response determines whether np is the applicable inherited policy.
The DNS records to publish
For a domain you own, 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 under the configured rules. Then publish reject at the organizational domain and add explicit subdomain and non-existent-name policies.
|
|
|
|---|---|---|
Active domain | p=reject | Request rejection of failing mail using the domain. |
Existing subdomains | sp=reject | Request rejection where the organizational-domain policy is inherited. |
Non-existent subdomains | np=reject | Request rejection of failing mail using NXDOMAIN names. |
Public suffix | psd=y | Identify a public suffix policy; p, sp, and np set the requested actions. |
Policy tags for owned domains and public suffix operators.
RFC 9989 makes pct, rf, and ri historic. Omit them from new records. The optional t=y test flag requests one level less enforcement: reject becomes quarantine, and quarantine becomes none. Older receivers ignore this flag, so use explicit p=none and p=quarantine stages when testing must work across receiver versions. Omit t or use t=n for enforcement. The np and psd tags remain active, but psd=y belongs only on public suffix DMARC records.
Active domain DMARC recordDNS
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com"
Strict DKIM and SPF domain matching are optional in DMARC. Omitting adkim and aspf keeps the relaxed defaults, which allow domains sharing the same organizational domain. Strict matching requires identical domains. Check production senders before using adkim=s or aspf=s on any active domain. On a non-sending subdomain of an active organization, strict matching also prevents an authenticated sibling or parent domain from satisfying the matching requirement.
No-send and no-receive domain recordsDNS
example.com. IN MX 0 . example.com. IN TXT "v=spf1 -all" _dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@reports.example.net"
For domains that neither send nor receive mail, SPF says no IP is authorized, the null MX says the domain does not accept inbound mail, and DMARC requests rejection of mail that fails DMARC. RFC 7505 defines null MX. Use it as the only MX record, not alongside real mail servers. For an inbound-only domain, retain working MX records and use no-send SPF plus reject DMARC. DKIM does not need a default record; remove obsolete selectors if no authorized system needs them.
The no-receive example sends reports to a separate domain because a mailbox at example.com cannot receive reports with null MX. Replace the sample address with a working destination. Under RFC 9990, an external reporting destination also needs authorization in its DNS. For this example, the operator of reports.example.net publishes the following record; it belongs in the reporting destination's zone, not the protected domain's zone.
External aggregate reporting authorizationDNS
example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1;"
Illustrative public suffix operator policy, not live DNS dataDNS
_dmarc.gov. IN TXT "v=DMARC1; p=reject; sp=none; np=reject; psd=y; rua=mailto:dmarc@reports.example.net"
Do not publish psd=y on a normal organizational domain. It is for public suffix domains. The illustrative suffix policy above leaves existing registrants at sp=none while requesting rejection for missing names; its external reporting address also needs authorization for the suffix. To prepare an owned-domain policy, use Suped's DMARC record generator, then validate it with Suped's DMARC checker before changing DNS.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Publish one DMARC policy TXT record per name, replacing an existing record rather than adding a second one. In DNS panels that append the domain automatically, enter _dmarc as the host. The examples above use complete zone-file names and single-line TXT values. After the previous DNS TTL expires, query the exact TXT name and test each approved sender. Check the receiving server's Authentication-Results header for dmarc=pass; an SPF or DKIM pass alone does not prove the required domain match.
Implementation checklist
The implementation path depends on whether the domain sends mail. An active sending domain needs sender verification; a dormant defensive registration needs a confirmed no-send configuration.
- 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: For active domains, start with p=none and review aggregate reports across normal sending cycles. Add np=reject for missing subdomains, but check wildcard DNS and remember that older receivers ignore np.
- Fix authentication: Make each sender pass SPF or DKIM with the required domain match. RFC 9989 requires domains publishing p=reject to sign their mail with valid DKIM rather than rely solely on SPF, which forwarding commonly breaks.
- Stage enforcement: Use p=quarantine as an intermediate step while investigating legitimate failures, then move to p=reject after known mail consistently passes. Check subdomains with their own DMARC records because they override inherited policy.
- 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 verified never to send mail, publish no-send SPF and DMARC reject immediately, then watch reports for abuse attempts and accidental use. Reports cover participating receivers, so a lack of reports does not prove that no mail was sent.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped's Hosted DMARC workflow supports controlled staging across multiple domains. After the initial DNS setup, teams can manage policy changes centrally and add reporting without repeating DNS handoffs for each policy change.
What DMARC reject stops
A reject policy reduces direct domain spoofing used in phishing and spam, but it does not stop display-name impersonation or mail sent through lookalike domains. A receiver can override the requested action or apply local handling when DNS is broken. Receivers that ignore np still apply inherited sp or p policies under older DMARC rules. With p=none; np=reject and no enforcing sp policy, those receivers receive no request to reject missing-subdomain mail.
Evidence for p=reject
Use aggregate report data and sender ownership to decide whether enforcement is ready.
Ready
No known failures
Every known production source consistently passes DMARC with the required SPF or DKIM domain match, with no known legitimate failures.
Review
Fix first
A known sender still fails DMARC or has no confirmed owner.
Unsafe
Unclassified traffic
High-volume unauthenticated traffic has not been classified as legitimate or abusive.
Unknown
Collect reports
No reliable aggregate report data exists yet.
For non-existent whole domains, you cannot publish your own discoverable policy without registering the domain and restoring working DNS. The practical options are to register an available high-risk variant, ask the public suffix operator about PSD DMARC, or use inbound receiver controls for traffic reaching your own network.
Monitor reject policies with Suped
Suped's DMARC reporting and email authentication platform turns raw authentication reports into sending-source and domain-level results. Use it to investigate legitimate failures before enforcement and track unexpected sending activity after reject is enabled.
For non-existent-domain protection, add every owned and defensive domain, confirm whether it sends mail, publish the correct reject or no-send records, and review detected issues. This helps identify parked domains that still have sending systems attached.
Manual DNS handling
- Visibility: Collect and parse aggregate reports for each protected domain.
- Policy changes: Update DNS records and verify the published values.
- Failure triage: Investigate broken SPF, missing DKIM, and domain mismatch issues.
- Scale: Track policy ownership and configuration across the domain portfolio.
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 verified never to send legitimate mail.
Record each defensive domain owner so registry holds do not delay urgent policy fixes.
Common pitfalls
Assuming a held or NXDOMAIN name can still publish discoverable DNS records delays fixes.
Relying only on receiver rejection for missing domains leaves protection inconsistent.
Publishing p=reject without checking legitimate senders can block operational messages.
Expert tips
Add np=reject at the organizational domain to state the missing-subdomain policy explicitly.
Ask the public suffix operator about PSD DMARC when abuse targets an entire namespace.
Keep monitoring after reject because new vendors can create legitimate DMARC failures.
Marketer view
Marketer from Email Geeks says a registry hold that removes DNS delegation prevents receivers from discovering DMARC records until DNS works again.
2024-09-06 - Email Geeks
Marketer view
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
Frequently asked questions
No. You need control of working DNS where the _dmarc TXT record is published. For an unregistered second-level domain, register it if available or ask the public suffix operator about an applicable PSD DMARC policy.
Yes, when the organizational-domain policy applies and np does not override it. RFC 9989 uses sp for missing subdomains if np is absent, then p if sp is absent. Older receivers that ignore np also inherit sp or p. An explicit np=reject documents the missing-name policy.
Yes, for domains you control and have verified do not send mail. Publish SPF with -all and DMARC with p=reject, sp=reject, and np=reject. Add null MX only if the domain receives no mail, and send aggregate reports to a separate working destination.
No. DMARC reject requests receiver handling for mail that fails authentication with the required domain match. It reduces direct spoofing where enforced. Display-name impersonation, lookalike domains, and receiver overrides remain outside that protection.
Yes. Publish it at your organizational domain to cover non-existent subdomains where that policy applies. Do not add psd=y unless you operate a public suffix. If p=reject and sp=reject already apply, np=reject makes the intent explicit rather than adding a new requirement for rejection.
NXDOMAIN means the DNS name does not exist, so np can apply. NOERROR/NODATA means the name exists but the requested record type is absent, so an inherited policy uses sp, with p as the fallback. Wildcards and empty non-terminals affect this distinction.
