Domain without email: the Null MX configuration
By CaptainDNS
Published on August 29, 2026
- Publish one MX record with priority
0and target.: having no MX still triggers fallback to the A or AAAA address. - For sending, use the bare SPF value
v=spf1 -alland DMARC withp=reject; sp=reject; np=reject. Putruaon another domain that can receive email. - Do not publish any DKIM selector. An empty
p=revokes an old key; it is not the policy for a domain that sends no email. - The public audit awards full inbound credit, but a reference zone remains in the Good band, usually around 80-85 depending on
ruaand DNSSEC.
A domain without email looks easy to administer: there is no mailbox and no SMTP server, so there appears to be nothing to configure. That is the trap. A zone left with its registrar defaults may still contain a default MX record. An overly broad SPF policy may continue to authorize a former provider. Without a DMARC policy, recipients receive no firm instruction about messages that impersonate the domain.
Another common mistake is to delete every MX record and assume inbound delivery is closed. SMTP defines a fallback to the A or AAAA addresses when no MX exists. For a website, that fallback points directly to the server hosting the site. It may respond incorrectly or slowly, but the remote sender will still have tried to deliver mail to it.
The configuration below covers two uses with the same reference zone: a brochure site or HTTPS application with no mailbox, and a defensive domain with no site and no certificate. Their email baseline is identical. Their CAA policies differ because the first must keep renewing its certificate, while the second must prohibit all certificate issuance.
Check the zone, then generate your DMARC policy
The problem with a zone left at its defaults
A domain without email should state explicitly that it neither receives nor sends mail. DNS silence preserves fallback behavior and old authorizations.
Start by inventorying the zone. Look for MX records added by the registrar, historical SPF TXT records, _dmarc, selectors below _domainkey, A and AAAA addresses, and then CAA records. An MX pointing to a free email offer is not harmless. If someone can create a mailbox later by mistake, the domain starts receiving mail again. An SPF record containing include: still authorizes the named service to present this domain in the SMTP envelope.
A zone without DMARC also leaves each recipient to decide what to do with a spoofed message. SPF may fail, but DMARC is the layer that connects authentication to the domain visible in the From address and publishes a policy. The objective for this closed configuration is clear: no legitimate source exists, so every message claiming to come from the domain should be rejected.
The expected result is not a collection of email mechanisms. It is one consistent negative declaration: no inbound destination, no authorized sender, a rejection policy, and no invented DKIM key. There are fewer records, but every record has a precise meaning.
Null MX explicitly closes inbound delivery
A Null MX is a single MX record with priority 0 whose target is the DNS root name .. RFC 7505 defines it as the way to announce that a domain accepts no email.
The zone representation is short:
example.com. IN MX 0 .
Depending on the DNS interface, the target may appear as a dot, an empty value, or a dedicated "Null MX" option. The published result must remain one MX with preference zero and an empty exchange name. Do not add a second backup MX: any other target contradicts the declaration.
No MX does not mean the same thing
Without an MX answer, an SMTP sender may try the domain's A or AAAA address as an implicit mail exchanger. This historical behavior is the main reason to publish Null MX even for a domain that hosts no website.
With Null MX, the sender understands that delivery is impossible and does not try the web server. In the CaptainDNS audit, this configuration receives full inbound credit. MTA-STS, DANE, and TLS-RPT are then unnecessary: they protect an SMTP transport that does not exist, and the audit awards the corresponding points.
The distinction also matters when the domain has neither A nor AAAA. No MX remains an absence, not a Null MX declaration. Publishing 0 . documents the intent, survives a future web-address addition, and gives senders an unambiguous answer.
Close outbound use with SPF and DMARC
The bare SPF value v=spf1 -all declares that no IP address is authorized to send for the domain. DMARC completes that declaration with a rejection policy for the domain and its subdomains.
Publish this at the apex:
example.com. IN TXT "v=spf1 -all"
Keep the value bare. Do not add a, mx, include, or an IP range. Each of those mechanisms would reintroduce an authorized sender. The -all qualifier is a hard failure; ~all would express only a soft failure, which serves no purpose when there is no legitimate source to preserve. The SPF generator can help check the syntax, but the final value contains only these two elements.
Then publish this at _dmarc:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc@captaindns.com"
p=reject covers the organizational domain. sp=reject applies rejection to existing subdomains, while np=reject covers nonexistent subdomains when a recipient supports that tag. Strict adkim=s and aspf=s alignment is appropriate because no legitimate flow depends on relaxed alignment.
The rua report changes the score
The rua tag is not decorative. Omitting it changes the DMARC score in the audit. It receives aggregate reports that reveal sources presenting the domain, even when the policy rejects their messages.
The address must never belong to the domain without email. rua=mailto:dmarc@example.com would create an orphaned address because Null MX says that example.com receives nothing. Use an address on another domain that really accepts email, such as dmarc@captaindns.com, or use a DMARC ingestion service. The same principle applies to ruf if you use it and to the iodef address in a CAA record.
External reports may require an additional DNS authorization at the destination domain under DMARC. Check that delegation with the selected provider. CaptainDNS ingestion at 5 euros is a possible second layer for centralizing these reports; it is not required to run the first free audit.
DKIM: publish no selector
There is no ideal DKIM record to paste into a domain that sends no email. The correct configuration is the absence of every selector below _domainkey.
DKIM authenticates a signature carried by a message. No legitimate message leaves this domain. Publishing an RSA or Ed25519 key "just in case" would create unused configuration surface. Publishing an empty value would be worse because that value already has a defined meaning.
RFC 6376 describes an empty p= tag as the revocation of a previously published key. A signer that knows the selector wants signatures using it to fail. The same RFC explains that a verifier gives no different meaning to a revoked key and a deleted key record: neither permits successful DKIM validation. RFC 5863 presents the empty value as a tombstone used while withdrawing a selector so that it is not reused accidentally.
That mechanism does not create a general "this domain sends no email" policy. A *._domainkey wildcard with an empty p= applies revocation semantics to selector names that may never have existed. M3AAWG removed this old recipe from its 2022 BCP: DKIM is unnecessary for a domain without email, and no DKIM record should be published.
CaptainDNS follows that interpretation. The public audit leaves DKIM and BIMI at zero and retains their recommendations. When Null MX and bare SPF are present, it also displays this exact note: "If this domain does not send email, DKIM and BIMI are not necessary. The score does not change." The note explains the case; it does not disguise the score.
In monitoring, the "This domain does not send email" option changes the evaluation layer. DKIM and BIMI are removed from the monitored score, and an alert is raised if a real MX or DKIM key appears. The two views are consistent: the public tool shows general recommendations and the capped score, while monitoring applies the domain's declared intent.
No orphaned address in the zone
Every mailto: URI published by a domain without email must point to another domain that can receive messages. This rule covers DMARC, CAA incident reports, and any operational address added later.
Search the exported zone as text. The usual locations are rua, ruf, and iodef. A contact address in a custom TXT record deserves the same check. If the right-hand side after @ is the domain that Null MX has just closed, the report will be lost.
For a website without email, do not confuse the address visible on a web page with email service for the domain. You may display an address hosted by another domain or a form connected to an external system. The site's DNS remains without email. For a defensive domain without a site, no local address has a reason to exist.
This separation avoids a quiet contradiction: asking certification authorities or DMARC receivers to send a report to a destination that DNS declares nonexistent. The security policy might look complete in a zone file, but nobody would read its alerts.
Two cases, one email baseline, and two CAA policies
The HTTPS website and the domain without a site share Null MX, SPF, and DMARC. They differ in their A/AAAA records and permission to issue a certificate.
| Element | Website without email | Domain without a site |
|---|---|---|
| A / AAAA | Present according to hosting | Absent |
| MX | 0 . | 0 . |
| SPF | v=spf1 -all | v=spf1 -all |
| DMARC | p=reject; sp=reject; np=reject | p=reject; sp=reject; np=reject |
| DKIM | No selector | No selector |
| CAA | CA actually used, plus external iodef | 0 issue ";" |
| Certificate | Allowed and renewable | Prohibited |
CAA for the HTTPS website
A website must authorize the CA that actually issues its certificate. Also add an iodef destination on another receiving domain. A complete policy can earn 100 for the CAA control in the DNS pillar, although DKIM prevents the overall score from reaching the top band.
example.com. IN CAA 0 issue "ca.example.com"
example.com. IN CAA 0 iodef "mailto:security@captaindns.com"
Adapt the identifier to your CA. Do not publish issue ";" on this website: it would prohibit issuance, and the next renewal could fail. The CAA guide explains inheritance, issuewild, and ACME parameters.
CAA for a domain without a certificate
A domain with no site, no A/AAAA address, and no certificate can prohibit every CA:
example.com. IN CAA 0 issue ";"
In the CaptainDNS audit, this choice earns 90 for CAA, not 100. The difference reflects the absence of an iodef channel, while a closed domain should not publish a local mailto: address. Naming a CA is not an interchangeable alternative because it would reopen certificate issuance.
DNSSEC also protects the website from a silent outage
DNSSEC signs DNS answers and lets a resolver detect tampering. A broken chain makes the domain invalid for validating resolvers even when the records remain present at the hosting provider.
For the website without email, this is the only part of the recipe that can make the website silently unreachable after a bad rotation. A stale DS at the registrar, a KSK removed too early, or expired signatures commonly produce SERVFAIL. The browser will not say "DNSSEC is broken"; it will show only a resolution error.
Deploy DNSSEC while checking the chain between the child zone and its parent. When changing DNS providers, coordinate the keys and DS before removing the old zone. The DNSSEC activation guide covers that sequence.
For the domain without a site, a DNSSEC failure does not break a nonexistent web page, but it prevents recipients from reading Null MX, SPF, and DMARC. Protection against spoofing therefore still depends on a valid chain. Monitor it like any other security record.
What the public audit will show
The public audit evaluates three pillars: outbound email 50, inbound email 35, and DNS 15. A properly configured domain without email receives Good, generally around 80-85 depending on the presence of rua and DNSSEC.
Inbound credit is full with one Null MX. MTA-STS, DANE, and TLS-RPT are not requested because the domain receives no email. By contrast, MXCount == 0 is an error: fallback to A remains possible and the closure has not been declared.
On the outbound side, strict SPF and DMARC reject clearly state that no legitimate source exists. DKIM and BIMI nevertheless remain at zero in the public tool, with their recommendations. The displayed note explains that those mechanisms are unnecessary if the domain sends no email and that the score does not change. As a result, the top band starting at 90 remains unreachable without DKIM. This behavior is deliberate and visible.
The DNS pillar depends in part on CAA and DNSSEC. The website can receive full CAA control credit with an authorized CA and external iodef. The domain without a certificate receives 90 for that control with issue ";". These figures are control subscores, not a promise about the overall score.
Monitoring changes only the email intent
The "This domain does not send email" option is a monitoring feature. It removes DKIM and BIMI from the monitored score and raises an alert if the zone starts accepting or signing email again.
It does not manufacture a flattering screenshot in the public audit. It changes neither the need for Null MX nor the requirements for SPF, DMARC, CAA, or DNSSEC. Its value is operational: if an administrator adds a real MX or an old DKIM selector reappears, monitoring reports that the "no email" contract has been broken.
The first CaptainDNS tool is free. Start with the zone audit, correct the records, and then enable monitoring if the domain warrants continuous alerts. The Monitor costs 5 euros. Other tools follow account pricing, 3 euros and then 5 euros, with no separate offer dedicated to this case.
Differences among published recommendations
Online guides do not all prescribe the same configuration. We use the newest texts and the RFC semantics, and identify differences directly.
GOV.UK still recommends a _domainkey wildcard containing an empty p= on a page updated March 1, 2021. EasyDMARC and Mimecast also repeat the 2015 M3AAWG BCP. We do not copy that value: M3AAWG removed it in the June 2022 edition, while the RFCs define it as revocation of an old key. Having no selector is more accurate and does not trigger the critical dkim.empty_p_tag recommendation in our own audit.
The condition "Null MX only if an A or AAAA exists" comes from the December 2015 edition: "M3AAWG recommends the use of a null MX record only if the domain has an A and/or AAAA record." It was intended for compatibility with receivers that had not yet implemented the RFC. The June 2022 edition removed the restriction, and its "Single Parked Domain" example, with neither A nor AAAA, publishes example.com. MX 0 .. We follow the 2022 text and publish it in both cases: no MX still means "no MX," not "explicit refusal," and a future A address would reactivate SMTP fallback.
internet.nl also recommends Null MX for a domain without a mail server and treats several email tests as not applicable to this profile. CaptainDNS keeps a uniform public view of its three pillars: the zone receives Good around 80-85, not the top band. Both interfaces describe the same objective with different scoring models.
What this article does not cover
This guide describes a zone that neither sends nor receives email. It does not replace the DMARC generator, which composes a policy from your choices, or the audit, which reads the DNS answers actually published.
It is not a sender guide either. It does not cover key rotation, provider selectors, or campaign deliverability. Articles devoted to DKIM retain that role. Adding a sending platform changes the requirement: the domain is no longer without email, and the configuration must be reviewed.
CAA is covered only at the decision point between an allowed certificate and a prohibited certificate. Its inheritance and variants belong in the CAA guide. DNSSEC is limited here to the risk of a broken chain; the complete tutorial remains separate. Domain retention and expiration are covered by the domain life cycle guide, not by email configuration.
Final zone verification
Check a coherent zone from the outside after propagation. Confirm that exactly one MX 0 . is visible, SPF contains only v=spf1 -all, and _dmarc publishes the expected rejection policy.
Then search for every name below _domainkey: nothing should remain except an old key being withdrawn under a dated plan. Confirm that each mailto: points to another receiving domain. Finish with CAA, DNSSEC, and any A/AAAA records.
Run the audit again after the TTL. Expect Good and read the DKIM and BIMI recommendations alongside the explanatory note. If you enable "This domain does not send email" in monitoring, also test the alert during a planned change and then restore the reference zone.
FAQ
What is the difference between Null MX and no MX?
Null MX publishes an explicit MX with priority 0 and target .. Without MX, an SMTP sender may fall back to A or AAAA, so the two configurations are not equivalent.
Should I publish a DKIM record?
No. Publish no selector below _domainkey. An empty p= is used only to withdraw an old key; it is not a template for declaring that a domain sends no email.
Why keep rua if the domain sends no email?
Aggregate reports reveal sources attempting to use the domain, and omitting the rua tag changes the DMARC score. Send the reports to an address on another domain that can actually receive them.
Is Null MX enough to prevent spoofing?
No. Null MX closes inbound delivery. SPF v=spf1 -all and DMARC p=reject address spoofed outbound use; each mechanism covers a different direction.
Which CAA record should a website without email publish?
Authorize the CA that issues the website certificate and add an external iodef when possible. Never publish issue ";" on that website because it would block certificate renewal.
Which CAA record should a domain without a website publish?
Publish 0 issue ";" if no certificate should be issued. In the CaptainDNS audit, this choice earns 90 for the CAA control, not 100.
Why does the public rating remain Good?
The public audit keeps DKIM and BIMI at zero with their recommendations, even though a note explains that they are unnecessary here. The monitoring option removes them from its score but does not alter the public audit.
