A domain that never sends can use restrictive SPF and DMARC policies with no provider ranges to maintain. It may still receive mail: keep its receiving records if it does. Null MX is only for a domain that accepts no incoming mail. Check application use where uncertain, and revisit the policy if its purpose changes.
A business can own a domain for an old brand, a future product or a defensive registration without using it to send email. Messages can still claim that domain, so a deliberate non-sending policy is useful.
With no authorised senders, the SPF policy can be simple and static.
“Unused” can mean different things
A parked domain may have no intended email service at all. A receive-only domain may still accept enquiries for an old brand. A domain with no staff mailboxes may nevertheless be used by an application to send receipts.
Those distinctions determine the policy. For a small domain collection, confirming them may be straightforward. A larger or poorly documented estate may need more investigation. Neither situation warrants assuming that every domain hides a forgotten sender.
A non-sending policy states what the domain permits
SPF can explicitly authorise no sending servers. DMARC can request enforcement against messages that fail authentication and alignment for the visible From domain. The UK Government's non-sending-domain guidance applies this principle to defensive and retired domains.
The two policies address different identities. SPF alone does not stop someone putting your domain in the visible From field while passing SPF for another domain. The receiving system's DMARC evaluation connects that visible identity to qualifying authentication.
These controls do not cover display-name impersonation or another registrant's lookalike domain, and the receiving system retains control over its handling.
Receiving is a separate decision
A null MX record declares that a domain does not accept email. It should not be published where incoming enquiries, replies or delivery failures still need to arrive.
Removing ordinary MX records is different: SMTP can fall back to address records when no MX exists. RFC 7505 explains why null MX makes the absence of service explicit.
An old brand can therefore have a restrictive sending policy while retaining a working receiving route. “No staff send from here” is not enough reason to disable incoming mail.
Domain use matters more than a quiet DNS check
Public DNS shows published policy; it cannot establish that no application is configured to use a domain. Where use is uncertain, existing account settings and relevant mail records can help establish it before enforcement changes.
Subdomains can also have their own purposes. SPF does not automatically inherit from a parent, while DMARC has domain discovery and subdomain policy rules. A non-sending root can coexist with a legitimate application sender on a subdomain. Microsoft's SPF documentation covers SPF's scope.
Once a domain is correctly configured as non-sending, there may be no SPF changes to make unless its purpose changes. There are no provider ranges to track in a policy that authorises nobody.
If the domain is reactivated, its sending and receiving policies need to match the new use. Messages using it as an envelope domain would still fail SPF while a policy authorising nobody remains in place.
Sources and further reading
- GOV.UK: Protect domains that do not send email
- RFC 7505: A Null MX No Service Resource Record
- Microsoft: Set up SPF
Sources reviewed 8 September 2026. Our editorial standards.