For a domain that does not send email, I configure it as an explicit no-mail domain: publish SPF with v=spf1 -all, publish DMARC at _dmarc with p=reject, and do not publish DKIM selector records unless a real sender has matching private keys. If the domain will not receive email either, add a null MX record as well.
The short version is simple: you do not need SPF and DKIM to pass DMARC when the domain sends no legitimate mail. You still publish SPF because it tells SPF-checking receivers that no IP is authorized. You publish DMARC because it tells DMARC-checking receivers to reject messages that claim the domain. DKIM is different because receivers only look up a DKIM key when a message carries a DKIM signature.
- SPF: Use v=spf1 -all at the exact domain or subdomain that must not send.
- DMARC: Use p=reject and add reporting when you will monitor the reports.
- DKIM: Do not create fake selectors or wildcard keys for normal parked domains.
- MX: Use a null MX only when the domain also accepts no inbound mail.
The DNS records I would publish
For a completely unused domain, I start with the records below. Replace example.com and the reporting mailbox with your own values. In a DNS UI, enter the DMARC content as one TXT value. The split below is only to keep each line readable.
No-send DNS baselinedns
example.com. TXT "v=spf1 -all" _dmarc.example.com. TXT ( "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; " "rua=mailto:dmarc-reports@example.com" ) example.com. MX 0 .
That setup says: no host is allowed to send for this domain, mail that claims this domain should be rejected by receivers that enforce DMARC, and subdomains should inherit the reject policy unless you override them. The null MX line says the domain does not accept inbound email. Do not add the null MX line if you need mailboxes, aliases, forwarding, or bounce handling for that domain.
|
|
|
|
|---|---|---|---|
SPF | Root | v=spf1 -all | The domain sends no mail. |
DMARC | _dmarc | p=reject | No mail should claim the domain. |
DKIM | Selector | None | No sender signs mail for it. |
MX | Root | 0 . | No inbound mail is accepted. |
Use the table as a compact checklist, not as a full zone-file example.
I also validate the final record after publishing because DNS providers rewrite TXT values in different ways. The DMARC checker is useful for confirming that the policy parses, the reporting address is present, and the record has one valid DMARC version tag.
Why SPF still belongs on no-send domains
SPF and DMARC answer different questions. SPF says which IP addresses can send for the domain in the SMTP envelope. DMARC says what to do when the visible From domain fails the required authentication checks. Since no mail should originate from the domain, SPF should authorize nobody.
Do not list the VPS IP unless it sends mail
Adding your VPS IP to SPF feels harmless, but it changes the security model. If that host later sends unwanted mail, that mail can pass SPF for the domain. For a no-send domain, the safest SPF record is v=spf1 -all.
This matters because not every receiver applies DMARC in the same way. Some systems still use SPF as a separate signal. A hard SPF fail gives those systems a clear answer: the domain owner authorized no sending sources.
Bad no-send setup
- SPF: Authorizes a web server that should never send mail.
- DMARC: Uses monitoring only, so rejected spoofing is not requested.
- Risk: A compromised sender can look more legitimate than it should.
Good no-send setup
- SPF: Authorizes no IP addresses with a hard fail.
- DMARC: Requests rejection for mail using the domain.
- Risk: Receivers get a clearer no-mail signal.
What the DMARC record should contain
The minimum DMARC record for a no-send domain is v=DMARC1; p=reject. I add reporting when somebody will read the reports, because the reports show which IPs and services are attempting to use the domain. For a domain that has no legitimate senders, any non-zero sending pattern deserves attention.
The aspf=s and adkim=s tags make DMARC use strict domain matching for SPF and DKIM. On a no-send domain, they are fine, but they are not the main protection. The important tag is still p=reject.
Decision path for choosing SPF and DMARC records on a no-send domain.
A reporting address also creates a maintenance duty. If you publish rua and never inspect the reports, you still get protection from p=reject, but you miss the evidence. Suped's DMARC reporting workflow turns those aggregate reports into source lists, authentication results, issue detection, and real-time alerts when a domain that should be quiet starts generating mail.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Why I usually skip DKIM records
DKIM is not a domain-wide declaration that a domain sends or does not send mail. It is a signature check. A receiver looks up a DKIM public key only after a message contains a DKIM-Signature header naming a selector and a signing domain.
That is why I do not publish random DKIM records for no-send domains. If there is no legitimate sender, there is no private key to match, no rotation plan, and no selector inventory. A missing selector cannot verify a forged DKIM signature. A signature from some other domain can verify for that other domain, but it does not make DMARC pass for your visible From domain.
Revoked DKIM keys are a narrow exception
A DKIM record with an empty p value can explicitly revoke a selector. I reserve that for a selector that previously existed and was misused or exposed. For ordinary no-send domains, deleting old selectors and publishing SPF plus DMARC is cleaner.
Wildcard DKIM records are also poor defaults. They can make DNS harder to reason about, and they do not change the core fact that DKIM verification starts with a selector named inside a signed message. If nobody signs legitimate mail for the domain, no DKIM selector needs to exist.
Subdomains need deliberate policy
Apex domains and subdomains need separate thinking. If example.com sends no mail and no subdomain sends either, use sp=reject in the organizational DMARC record. If a subdomain sends mail, do not rely on a blanket inherited reject policy. Give the sending subdomain its own SPF, DKIM, and DMARC setup.
No-send subdomain exampledns
app.example.com. TXT "v=spf1 -all" _dmarc.app.example.com. TXT "v=DMARC1; p=reject"
For mixed estates, I prefer explicit records on important subdomains. It removes guesswork when someone later connects a marketing tool, help desk, or application server. If you need a fuller walkthrough, the subdomain DMARC setup page goes deeper into inheritance and overrides.
Domain will never send
- Policy: Move straight to reject.
- SPF: Publish a hard fail.
- DKIM: Leave selectors absent.
Domain might send later
- Policy: Change DNS before launch.
- SPF: Authorize only the real sender.
- DKIM: Publish only provider-issued selectors.
Testing and ongoing monitoring
After DNS publishes, test the domain rather than assuming the provider saved the value correctly. I check that there is only one SPF record, only one DMARC record at the expected host, and no old DKIM selectors left behind by a previous sender.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped is the practical default when this has to be maintained across several domains because it brings DMARC, SPF, and DKIM monitoring together with hosted DMARC, hosted SPF, SPF flattening, Hosted MTA-STS, blocklist (blacklist) monitoring, and deliverability insights. The point is not just publishing the first TXT record. The point is noticing when a quiet domain starts showing mail, when a subdomain needs a specific override, or when a future sender changes the DNS requirements.
For ongoing protection, DMARC monitoring gives you the evidence behind the policy. For teams that need staged policy changes without touching raw TXT records every time, Hosted DMARC keeps the operational workflow simpler. If you are creating the first record, the record generator helps produce a valid starting point.
A practical monitoring rule
For a no-send domain, treat any authenticated volume as an incident until explained. The only normal baseline is zero legitimate sending. That makes alerting much easier than it is for an active marketing or transactional domain.
Common mistakes to avoid
Most no-send domain mistakes come from copying a normal sending-domain setup. A parked domain does not need broad includes, vendor selectors, or soft-fail SPF. It needs a clear denial posture and enough monitoring to catch unexpected use.
- Soft fail: Do not use ~all for a domain that should authorize nobody.
- Duplicate SPF: Do not keep an old SPF record beside the no-send SPF record.
- Forgotten subdomains: Do not assume every important hostname inherits what you intended.
- Fake DKIM: Do not publish made-up DKIM keys to look complete.
- No reporting: Do not add reporting addresses unless reports go somewhere reviewed.
Public sector guidance reaches the same operational answer for domains that do not send mail: make the domain explicit, not silent. The UK guidance is a useful reference point for the SPF, DMARC, and null MX pattern.
If your only question is whether a reject policy is valid when the domain sends no mail, the answer is yes. A no-send domain is one of the cleanest cases for reject because there is no legitimate mail stream to break. The deeper reject policy discussion covers that specific point.
Views from the trenches
Best practices
Publish SPF -all and DMARC reject on domains with no legitimate sending use case.
Keep DKIM selectors absent unless a real mail system owns the matching private key.
Use reporting and alerts so any sudden mail volume from a quiet domain gets reviewed.
Common pitfalls
Adding a VPS IP to SPF can let unwanted mail pass if that host starts sending mail.
Wildcard DKIM records add DNS risk without improving normal no-send domain protection.
Leaving old SPF includes behind weakens the no-send signal receivers should evaluate.
Expert tips
Use null MX only when the domain has no inbound mailboxes, aliases, or bounce handling.
Set subdomain policy carefully when some child domains send and others are parked.
Treat any authenticated mail on a no-send domain as suspicious until it is explained.
Marketer from Email Geeks says no-send domains do not need SPF or DKIM to pass DMARC, because no legitimate mail should pass.
2020-06-05 - Email Geeks
Marketer from Email Geeks says a no-send domain should publish SPF -all with a DMARC reject policy.
2020-06-05 - Email Geeks
The practical setup
For a domain that does not send email, I publish SPF -all, DMARC p=reject, and no DKIM selector records. If it also receives no mail, I add null MX. If subdomains are involved, I set explicit policies where needed instead of assuming inheritance will stay obvious months later.
The only caveat is future use. Before any real sender uses the domain, replace the no-send SPF record, publish the sender's DKIM selectors, keep DMARC reporting on, and confirm passing authentication before sending at volume. That change should happen before the first campaign, application alert, or transactional message leaves the system.
