A domain can have no employee mailboxes and still send invoices, website notifications or supplier messages. Establish its actual use before declaring it a non-sending domain.
Once that evidence is available, configure the controls for their separate purposes. SPF describes authorised envelope sending, DMARC addresses aligned use of the visible From domain, and a null MX states that the domain accepts no mail. Those are related decisions, not interchangeable records.
Check for legitimate and dormant use
Review business applications, web forms, acquired systems, outsourced campaigns and periodic notifications. Ask whether the domain appears in visible From addresses, envelope return addresses, reply handling or reporting destinations.
Check subdomains separately. A non-sending parent domain does not establish that every child has the same purpose, and a child sending service can have its own configuration.
Combine observed data with owner confirmation and configuration evidence. A quiet reporting window is useful context but cannot prove that an annual or dormant workflow does not exist.
Make the sending declaration explicit
For a domain genuinely authorised to send no mail, an illustrative SPF policy at that domain is:
v=spf1 -allUnder RFC 7208 §4.6.2 and RFC 7208 §5.1, this gives no sending permission for the evaluated SPF identity. It is not an instruction to add a second SPF policy beside an existing one. Investigate and replace obsolete permissions through an approved change.
SPF checks HELO and MAIL FROM identities as specified in RFC 7208 §2.3 and RFC 7208 §2.4. It does not, on its own, prevent an unrelated service from placing the domain in a visible From address. Consider the applicable DMARC policy as a separate part of the plan.
Assess the DMARC policy for that domain
After confirming there are no legitimate From-domain flows that the change would disrupt, a scoped non-sending-domain example at _dmarc.example.com is:
v=DMARC1; p=rejectThis is an illustrative policy for the stated purpose, not a template for staff correspondence domains. Confirm applicable discovery and subdomain behaviour under RFC 9989 §4.10.1 and RFC 9989 §4.7, and retain the general-purpose interoperability distinction.
If reports are requested, use a collection address that actually receives mail. A domain configured to accept no mail cannot also be assumed to receive its own reporting mailbox. Under RFC 9990 §4, an external destination needs the relevant reporting permission and collection checks.
Decide whether the domain also accepts no mail
A non-sending domain may still receive mail. Do not remove a legitimate receiving route merely because no outbound use was found.
When the separate decision is that the domain accepts no email, RFC 7505 §3 defines a null MX. In DNS master-file notation, its exchange data is:
0 .It must be the only MX record for that domain. The final dot represents the null exchange, not a server hostname to invent. Follow the DNS editor's input model and verify the published answer.
Under RFC 7505 §4.2, domains SHOULD NOT publish null MX when used in SMTP MAIL FROM or visible From addresses because receivers may reject their mail. Check those uses before publishing.
Work through a hidden-service example
In this synthetic example, a parked brand domain has no mailboxes, but an outsourced renewal application still uses it in From and expects replies at the domain.
Publishing the non-sending controls immediately could disrupt that workflow. The team first identifies the service owner and decides whether to migrate the identity, preserve a legitimate mail function or retire the application.
Only then can it document that the old domain has no remaining authorised sending and, if applicable, no receiving requirement. The evidence changes the classification; the initial absence of mailboxes did not settle it.
Verify the final state and keep an owner
Save the previous records and the approved domain-purpose decision. Verify authoritative SPF, applicable DMARC and receiving configuration independently. Record the scope of the subdomains reviewed and any exceptions.
Continue checking for unexpected use, ownership changes and newly introduced services. A configuration for an unused domain needs someone responsible for noticing when it becomes used.
Use the sender inventory to establish dependencies and policy selection for domains with active legitimate mail.
Record the decision and its limits
In the hidden-renewal scenario, hold both the no-sending classification and the no-receiving decision until the owner resolves the active From identity and expected replies. After migration, verify the replacement route before retiring the old one. A null MX does not publish SPF or DMARC policy; a reject policy does not guarantee that every receiver rejects. These examples authorize no change and claim no executed queries.