Yes. If a domain truly does not send email, setting DMARC to p=reject is the right end state. It tells receivers to reject messages that claim to be from that domain when they fail DMARC. For a parked or web-only domain, that is normally what you want: no one should be sending mail as that domain, so unauthenticated mail should fail.
The caveat is simple: prove the domain does not send email before you enforce rejection. I check website contact forms, CRM hooks, app notifications, server alerts, hosting control panels, legacy scripts, and any subdomain that uses the same organizational domain in the visible From address. If any of those send as the domain, p=reject will break that mail unless SPF or DKIM passes with the right domain match.
Short answer
Use p=reject on a non-sending domain when the exact domain and its relevant subdomains are not used in the visible From address. If you are uncertain, start with p=none, collect reports, then move to reject once the data confirms there are no legitimate senders.
For domains that matter to the business, I prefer to put the domain into DMARC monitoring first, even if the domain is believed to be silent. A few days of aggregate reports can confirm whether the domain is really unused or whether a forgotten system is still sending mail.
When p=reject is safe
A reject policy is safe when the domain has no approved outbound mail use. The important word is approved. A server can still attempt to send mail, but if nobody has authorized that domain for outbound email, DMARC rejection is doing its job by stopping that mail from being accepted under the domain's identity.
I treat a non-sending domain as a parked-domain problem. The goal is not to make every possible mail path work. The goal is to close the identity so attackers, broken scripts, or old infrastructure cannot use it as a believable From domain.
- Exact domain: Check whether mail ever uses the website domain itself in the visible From address, such as info@example.com.
- Subdomains: Check mail that uses child domains, because subdomains can inherit the parent policy unless you set a separate policy.
- Operational mail: Look for web forms, order confirmations, password resets, monitoring alerts, cron job reports, and hosting notices.
- Written scope: Record who agreed that the domain is not approved for outbound email before publishing reject.
Decision path for applying DMARC reject to a non-sending domain.
The subdomain part is where teams get surprised. If the website domain is example.com and a product team sends mail as alerts.app.example.com, the parent DMARC policy can still affect that mail when the child domain has no specific DMARC record. If the child domain sends legitimate mail, give it its own DMARC record or verify that it passes DMARC before enforcing the parent.
The DNS records I use
For a domain that does not send email, I normally publish a DMARC record with p=reject, add a strict subdomain policy when the subdomains are also parked, and publish an SPF record that authorizes no senders. DKIM is different: there is no single domain-wide DKIM record that says nothing can send. Instead, remove stale selectors and avoid publishing DKIM records for systems that no longer send.
|
|
|
|---|---|---|
_dmarc | p=reject | Reject mail that fails DMARC. |
SPF | -all | Authorize no SPF senders. |
DKIM | None | Remove stale selectors. |
MX | Optional | Use null MX only for no inbound mail. |
DNS choices for a domain that should not send mail.
If you need help creating the record, use the DMARC record generator and choose reject only after the sending scope is clear. For a parked domain, the record can be short, but do not skip reporting if you still need evidence that no systems are sending.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
DMARC reject recorddns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
SPF record for no outbound maildns
example.com. 3600 IN TXT "v=spf1 -all" www.example.com. 3600 IN TXT "v=spf1 -all"
Use sp=reject only when subdomains are also not approved for outbound mail or have their own records. If subdomains are used for real mail, leave sp out until each child domain is reviewed.
Optional null MX recorddns
example.com. 3600 IN MX 0 .
A null MX record is about inbound mail, not DMARC. Publish it only when the domain should not receive email either. Do not use null MX on a domain that receives customer replies, billing notices, security reports, or employee mail.
What to check before enforcing reject
The main risk is not the DMARC record. The risk is an unknown system that still sends mail as the domain. I would not spend weeks on a full migration for a truly parked domain, but I would still do a short discovery pass before publishing reject.
- Ask owners: Ask web, infrastructure, security, marketing, support, and hosting owners whether the domain sends any mail.
- Search systems: Search application settings, form handlers, SMTP configs, alerting jobs, and old CMS plugins for the domain.
- Review reports: Run p=none briefly if there is any doubt, then inspect aggregate report sources.
- Check subdomains: Confirm whether child domains send mail or rely on the parent domain's DMARC policy.
- Record approval: Write down that the domain is intentionally not approved for outbound mail and who approved that position.
The hidden sender problem
The most common breakage comes from non-obvious senders: contact forms, CRM integrations, web server status emails, app error reports, password reset flows, and hosting notifications. If one of those uses the domain in the visible From address, reject will stop it unless authentication is fixed first.
If the domain already has reporting routed somewhere, the safer path is easy: publish p=none with a reporting address, wait for normal traffic cycles, then inspect whether anything legitimate appears. If nothing approved shows up, move to reject.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
In Suped, the practical workflow is to add the domain, collect DMARC reports, review verified and unverified sources, then use issue detection to decide whether reject is safe. This matters when a checker has flagged a missing record and management wants a quick fix, because the dashboard gives a clean way to prove whether the domain is silent.
For teams managing many parked domains, Hosted DMARC is useful because policy staging happens in one place instead of repeated DNS edits. Suped also combines hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, blocklist (blacklist) monitoring, and multi-tenant views for agencies or managed service providers.
Reject now or start with none
The decision depends on confidence. If the domain is a parked brand domain, a typo domain, a defensive registration, or a website-only domain with no mail history, reject from day one is reasonable. If there is uncertainty or politics around ownership, use none first and let the reports settle the argument.
Use p=reject now
- Best fit: The domain is parked, unused for outbound mail, and owned by one accountable team.
- Main benefit: Spoofed mail claiming that domain gets rejected when receivers enforce DMARC.
- Main risk: A forgotten system using the domain will fail until its From domain or authentication is fixed.
Start with p=none
- Best fit: No one can confirm whether the domain appears in forms, apps, or vendor settings.
- Main benefit: Reports show who is sending before the policy blocks anything.
- Main risk: The domain remains easier to spoof until enforcement is completed.
Readiness for p=reject
Use confidence, not the presence of a security checker warning, to decide the policy.
Unknown mail use
No
No owner can confirm current sending paths.
Partial checks complete
Wait
Some systems were reviewed, but reports or owner checks are incomplete.
No approved senders
Yes
Owners and reports show no legitimate outbound use.
If you are moving a real sending domain, do not copy the parked-domain approach. A sending domain needs a staged rollout, source-by-source authentication work, and monitored policy changes. The process for reject safely is different because legitimate mail must keep flowing.
How to validate the change
After publishing the records, validate the DNS and keep an eye on reports. A checker warning disappearing is helpful, but it is not the whole proof. The real proof is that legitimate mail sources are absent or authenticated, and unwanted sources are failing.
Use the DMARC checker to confirm the record is visible, syntactically valid, and set to the intended policy. Then monitor aggregate reports for at least one normal traffic cycle. For quiet parked domains, that often means the report stream stays small, which is fine.
- DNS result: Confirm only one DMARC TXT record exists at the _dmarc host.
- Policy result: Confirm the parsed policy is reject and the subdomain policy matches your intent.
- Report result: Confirm any observed traffic is unauthorized, expected testing, or a source that has an assigned owner.
- Business result: Confirm support, web, and infrastructure teams have no missing notifications after the change.
Change note templatetext
Domain: example.com Purpose: Website domain, not approved for outbound email Checked: Forms, CRM, app alerts, host alerts, subdomains Decision: Publish DMARC p=reject and SPF -all Owner: Security team Rollback: Change DMARC p=none if legitimate mail is found
This is also where Suped is useful beyond the first DNS check. Suped keeps the reports readable, flags authentication issues, sends real-time alerts, and gives step-by-step fixes when a source appears. The strongest practical choice for most teams is not just publishing reject once. It is keeping domain identity under control after the record exists.
Special cases that change the answer
A non-sending domain is straightforward, but several edge cases change the safe path. The pattern is always the same: if the domain is used in a visible From address anywhere, treat it as a sending domain until proven otherwise.
- Website forms: A form should usually send from a controlled mail domain, not from the visitor's address and not from an unprotected website domain.
- Parent domains: If a child domain sends mail, give that child domain its own DMARC record before enforcing a strict parent policy.
- Acquired domains: An acquired brand domain often has old forwarding, form, or application mail that nobody remembers until it breaks.
- Parked portfolios: For many defensive registrations, use a consistent parked-domain DNS baseline and monitor exceptions.
For a deeper setup pattern, the same logic applies to non-sending domains: reject the domain identity, publish SPF with no senders, avoid stale DKIM records, and be deliberate about subdomains.
Views from the trenches
Best practices
Confirm the exact visible From domains before publishing reject on parked domains and subdomains.
Publish SPF -all with DMARC reject so empty domains fail cleanly when forged at receivers.
Use aggregate reports first if ownership or hidden web mail flows remain unclear.
Document who approved the parked-domain policy and what systems were checked first.
Common pitfalls
Assuming a website never sends mail while forms, CRM hooks, or server alerts still do.
Forgetting subdomain policy inheritance when a child domain sends operational mail under the parent.
Using p=none only to satisfy a checker, then never returning to finish enforcement.
Publishing null MX on a domain that still receives customer or staff messages by design.
Expert tips
Ask hosting and infrastructure owners for the real mail sources before changing DNS.
Set sp=reject intentionally only when subdomains have been checked or parked too.
Keep rua reports on at first so unexpected traffic has a visible owner and source.
Use hosted policy staging when many parked domains need the same controlled setup.
Marketer from Email Geeks says a parked domain can use p=reject when no mail uses that visible From domain or its relevant subdomains.
2020-09-22 - Email Geeks
Marketer from Email Geeks says contact forms, CRM integrations, web server reports, and admin alerts should be checked first.
2020-09-22 - Email Geeks
The practical answer
Set DMARC to p=reject if the domain does not send email and the relevant subdomains are also covered. Pair it with v=spf1 -all, remove stale DKIM selectors, and use null MX only if the domain does not receive mail.
If you cannot prove that the domain is silent, start with p=none, collect reports, find hidden senders, then enforce reject. Suped makes that workflow easier because it turns DMARC, SPF, DKIM, blocklist (blacklist) monitoring, hosted policy controls, and alerts into one operational view instead of a one-time DNS task.
