Can a sending domain use a null MX record?
Published 4 Aug 2026
Updated 11 Oct 2026
12 min read
Summarize with
Updated on 11 Oct 2026: We clarified null MX rejection risks and added practical checks for SMTP errors and receiving routes.
A sending domain should not publish a null MX record. The DNS value MX 0 . states that the domain accepts no email, and RFC 7505 says domains used in either the envelope sender or visible From address should not publish it. Sending anyway creates a real risk of rejection, even when the Return-Path uses a different, routable domain.
Reserve null MX for domains that are not used in sending or receiving email addresses. For an active sending domain, publish a real MX that accepts replies and operational mail. At minimum, the receiving setup should handle postmaster and abuse messages, plus any reply address shown to recipients.
Practical rule
If the domain appears in RFC5321.MailFrom, RFC5322.From, or Reply-To, give it a working mail route. A separate bounce domain fixes only the envelope return path. It does not reverse the sending domain's public statement that it accepts no mail.
What a null MX record means
A null MX record has preference 0 and a single dot as its exchange value. The dot is the DNS root, not a hostname. It tells a compliant sending server that there is no SMTP destination for the domain, so the server should fail delivery without trying the domain's A or AAAA address.
Null MX recordDNS
example.com. 3600 IN MX 0 .
This record is useful because an absent MX record has different behavior. When MX is absent, an SMTP sender can fall back to the domain's address record and attempt delivery there. Null MX removes that ambiguity. It makes an explicit no-mail declaration. The RFC 7505 specification defines this behavior and explains the sending-domain caveat.
No MX record
The sending SMTP server can try the domain's A or AAAA address as an implicit MX destination. That works only when an SMTP service at that address accepts mail for the domain.
Null MX record
The domain explicitly accepts no email. A sender should stop instead of falling back to an address record or opening an SMTP connection.
Null MX does not authenticate outbound email. It does not replace SPF, DKIM, or DMARC, and it does not tell a receiver which outbound systems are authorized. Its purpose is limited to declaring that the domain has no inbound mail service.
Why sending domains need a working mail route
Ordinary messages need a deliverable envelope sender for delivery status notifications (DSNs). Bounce messages themselves use an empty reverse path to prevent response loops. Human communication also creates replies, vacation responses, complaints, and requests for help. A domain that sends mail while declaring that it accepts none presents a contradiction receivers can use as a negative signal.
- Bounce handling: A routable envelope sender lets remote systems return non-delivery reports and lets the sender suppress bad recipients.
- Recipient replies: People reply to transactional and marketing messages, even when the original message was designed as one-way communication.
- Operational contacts: Postmaster and abuse addresses give receivers a route for delivery problems and complaints.
- Receiver checks: A receiver can reject a message when the sending identity publishes null MX because the address cannot receive mail.
The relevant identity depends on the receiver's checks. The envelope sender matters for SMTP error handling and SPF. The visible From domain matters to recipients and DMARC. The Reply-To domain matters when a person responds. A separate domain for each role is valid, but every address intended to receive mail needs a working route. An explicit MX is recommended; SMTP also supports A or AAAA fallback when MX records are absent, as defined in RFC 5321.
Decision path for choosing null MX or a receiving MX for an email domain.
This decision applies to subdomains as well as organizational domains. MX lookup uses the exact address domain; a parent domain's MX does not automatically apply to a subdomain. A dedicated tracking host that never appears in an email address can use null MX. A campaign subdomain used in the visible From address should have a real receiving route, even if its Return-Path points elsewhere.
A separate Return-Path does not remove the risk
Using a separate, routable Return-Path is good practice. It gives delivery failures somewhere to go and lets SPF authenticate the envelope domain. It does not make null MX appropriate on the visible From domain. RFC 7505 addresses both RFC5321.MailFrom and RFC5322.From identities because receivers can inspect either one.
|
|
|
|---|---|---|
From | Visible sender | Real route |
Return-Path (non-empty envelope sender) | Bounces | Working bounce receiver, including a managed service |
Reply-To | Human replies | Real route |
DKIM signing domain | Signature verification | No inbox needed solely for signing |
Tracking host | Links | No inbox needed |
Email identities and their inbound requirements
DMARC requires a passing SPF or DKIM result whose domain matches the visible From domain under the configured strict or relaxed rules. Strict matching requires identical domains; relaxed matching requires the same organizational domain, as specified in RFC 9989. It does not test whether the From domain accepts replies. A message can pass DMARC and still be rejected or filtered because null MX conflicts with the domain's use as a sender. Authentication success and address validity are separate checks.
Null MX is different from the null reverse path MAIL FROM:<>. A delivery status notification uses that empty SMTP envelope sender to prevent bounce loops; it is not a DNS record and does not justify null MX on its visible From domain. RFC 7505 explicitly keeps these mechanisms separate.
DMARC passes are not delivery guarantees
SPF, DKIM, and DMARC establish authorization and domain association. Receivers still apply syntax, DNS, reputation, content, and local policy checks. Null MX can fail that broader review.
An MX hostname that does not accept SMTP does not solve this. That changes the DNS appearance but keeps the operational problem. The MX target should resolve correctly, accept connections, and deliver the addresses the sender publishes or needs for administration.
How mailbox providers can treat null MX
A receiver can reject a null-MX sending identity at SMTP time. If it accepts the message, other filtering decisions still apply. The exact treatment depends on the identity checked and the receiver's current policy. A successful campaign at one provider does not prove the configuration is portable.
What null MX communicates
- Inbound service: The domain accepts no mail.
- Address validity: Replies cannot reach that domain.
What a receiver can infer
- Sender consistency: The domain contradicts its DNS declaration.
- Delivery decision: The receiver can reject the message under its acceptance policy.
The supplied Yahoo reports are anecdotes, not evidence of a universal rejection rule. RFC 7505 warns that mail sent with a null-MX identity risks rejection. A configuration should not depend on every receiver overlooking that condition.
When troubleshooting, change one variable at a time. Replace null MX with a working route, confirm DNS propagation, send a new message, and record the SMTP response. If delivery recovers, keep the valid MX and continue checking authentication and reputation.
How to diagnose a null MX rejection
Compare the SMTP response with DNS for the exact From, envelope-sender, and Reply-To domains. RFC 7505 recommends distinct status codes for sender and recipient null MX failures:
|
|
|
|---|---|---|
550 5.7.27 | Sender address has null MX | Envelope-sender or visible From domain |
556 5.1.10 | Recipient address has null MX | Recipient domain, including a reply or bounce destination |
Recommended null MX status codes; receivers also use other diagnostic text.
Check the exact domain and its MX targetBASH
dig +short MX example.com dig +short MX bounce.example.com dig +short A inbound.example.com dig +short AAAA inbound.example.com
Replace the example names with the actual domains and returned MX hostname. An answer of 0 . is null MX. An empty short answer is inconclusive; inspect the full DNS response to distinguish absent records from NXDOMAIN or lookup errors.
Check authoritative DNS and the resolver used by the sending system after a change. Cached answers persist until their TTL expires. If public DNS is correct but a local server still rejects mail as a local recipient, inspect its routing configuration and recipient acceptance. Local routing can bypass public MX lookup.
How to configure the domain safely
Start by listing every domain and subdomain used in From, Return-Path, Reply-To, DKIM signing, and tracking. This prevents a narrow MX change from hiding an identity mismatch elsewhere. The receiving route can use an existing mailbox system or a dedicated inbound service, provided it accepts the required addresses.
- Remove null MX: Delete the MX 0 . record from active From, non-empty envelope-sender, and Reply-To domains.
- Publish a real target: Add the fully qualified MX hostname supplied by the inbound mail operator and verify that it resolves directly to A or AAAA records, not a CNAME.
- Create working addresses: Route postmaster, abuse, and the published reply address to monitored destinations.
- Retest the message: Check the new DNS answer, then send a fresh message and inspect the authentication results.
Example receiving MXDNS
example.com. 3600 IN MX 10 inbound.example.com.
The hostname and preference in that example are illustrative. The MX target needs A or AAAA records, but it does not need a separate MX of its own solely because it receives mail for example.com. Use the exact target provided by the receiving system. Do not point MX at a web server unless that host runs a properly configured SMTP service. Also remove the null MX instead of leaving it beside normal MX records, because a null MX must be the domain's only MX record.
After changing MX, use Suped's domain health checker to review published DMARC, SPF, and DKIM configuration. This DNS check does not test SMTP acceptance or discover every DKIM selector; verify selectors from actual message headers and test delivery separately.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Check one valid SPF record on each envelope-sender domain, usable DKIM keys at the selectors used by active senders, and an applicable DMARC policy for the visible From domain. Add a rua destination for aggregate reports, then confirm that a real message passes SPF or DKIM with matching domains. Reporting is recommended, but rua is not required for a valid DMARC record.
Suped's DMARC platform processes aggregate reports, identifies sending sources, and alerts on authentication failures. After the MX correction, use those results to find unrecognized senders or SPF and DKIM domain-matching problems.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
For ongoing operations, DMARC monitoring adds reported authentication results that a one-time DNS lookup cannot provide. Use Suped's reports to confirm that observed traffic uses the intended domains. Separate blocklist (blacklist) results add reputation context; neither proves that replies or bounces reach their destinations.
The strongest validation is a real delivery test. Send to representative mailbox providers and confirm that a reply reaches its intended inbox. Test a controlled invalid recipient and verify that the failure reaches the bounce processor. An immediate SMTP rejection can be recorded directly by the sending service without a separate bounce email.
When null MX is the right choice
Null MX is correct for a domain that is not used in sending or receiving email addresses. A domain used solely for DKIM signing or tracking does not need an inbox for that role. Common cases include parked domains, defensive registrations, unused product domains, and web-only hosts that should never receive mail. Pairing null MX with restrictive SPF and DMARC records makes that intent clearer to receivers.
Safe null MX test
- No outbound mail: The domain never appears in From or Return-Path.
- No inbound mail: No person or system expects mail at the domain, including Reply-To addresses.
- No mail operations: The domain has no receiving service; operational contacts use an active organizational domain.
- Clear policy: SPF authorizes no senders and DMARC requests rejection of messages that fail authentication and domain matching.
For a domain that does not send email, the related DMARC reject setup should include SPF that authorizes no senders and a DMARC policy at reject. Null MX handles inbound SMTP routing, while those records address unauthorized outbound use.
Non-sending domain recordsDNS
example.com. 3600 IN MX 0 . example.com. 3600 IN TXT "v=spf1 -all" _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject"
Before publishing reject, use a DMARC record check and confirm that the domain truly has no legitimate senders. Suped's hosted DMARC workflow can stage policy changes and keep reporting visible, which helps teams avoid applying a non-sending configuration to an overlooked service. If the rua address is outside the policy domain's organizational domain, configure external reporting authorization as specified in RFC 9990. An address on the null-MX domain cannot receive emailed reports.
Views from the trenches
Best practices
Use a working mail route for every domain in From, Reply-To, or Return-Path addresses.
Route postmaster and abuse mail to monitored inboxes with clear internal ownership.
Test replies and controlled bounces after DNS changes, not only record syntax checks.
Common pitfalls
Using a separate Return-Path does not make null MX safe on the visible From address domain.
Adding a real MX beside null MX creates an invalid and contradictory MX record set.
A passing DMARC result does not cancel receiver checks for a valid sending address.
Expert tips
Keep null MX for domains absent from sending and receiving addresses, including parked names.
Check every email identity separately because each domain can have different DNS records.
Record SMTP responses before and after the MX correction to confirm the delivery effect.
Marketer view
Marketer from Email Geeks says null MX should be reserved for domains absent from sending and receiving addresses, since active sending creates a conflicting signal.
2026-07-28 - Email Geeks
Marketer view
Marketer from Email Geeks says a null MX prevents bounce receipt when the Return-Path uses that domain, which gives receivers a strong reason to reject mail.
2026-07-28 - Email Geeks
Frequently asked questions
Technically, yes. Null MX controls inbound routing rather than outbound transmission. RFC 7505 says domains used in the envelope sender or visible From address should not publish null MX because receivers can reject their mail.
No. A routable Return-Path receives bounces, but null MX on the visible From domain still says that domain accepts no mail. A working Reply-To elsewhere can route human replies, but it does not remove receiver checks on the From domain.
No. With no MX record, an SMTP sender can fall back to the domain's A or AAAA address if an SMTP service there accepts mail. Null MX explicitly states that the domain has no inbound mail service.
The supplied Yahoo reports do not establish a universal rule. RFC 7505 warns of rejection risk, but receiver policies differ. Configure a working mail route and inspect the actual SMTP response instead of assuming every provider behaves the same way.
Use null MX only if the domain also receives no legitimate mail. For a domain that neither sends nor receives, publish null MX, SPF with -all, and DMARC at reject after checking for overlooked senders. A receive-only domain still needs a working mail route.
