Null MX Record with Reject Policy

What happens when a domain has a null MX record with a reject policy?

You send an email to a domain that doesn’t accept mail. It doesn’t just bounce— it outright refuses, before the message even arrives. That’s the effect of a null MX record paired with a reject policy.

Think of it like a locked front gate with a sign: “No mail accepted here. Do not attempt delivery.” The domain has no mail servers configured (null MX), and the server explicitly rejects incoming messages with a hard bounce. There’s no waiting. No scanning. No spam filter. Just a firm “this domain does not receive email.”

This isn’t just about preventing delivery—it’s about breaking the chain of email spoofing. When a domain has a null MX with reject policy, spammers can’t use it to forge mail. Any attempt to send from that address fails at the DNS level, before it ever reaches a mail server.

Key takeaways

A null MX record with reject policy blocks all incoming mail at the DNS level, preventing spoofing attempts.
Any email to the domain results in a hard bounce, making it impossible for spammers to use the domain for fake messages.
This configuration enhances sender reputation by clearly signaling non-receiving status, reducing the risk of abuse.

Why null MX records are a critical defense against email spoofing

You can block email spoofing at the earliest stage by setting a null MX record with a reject policy. Without a valid MX record pointing to an accepting mail server, any attempt to send email from your domain fails immediately during the SMTP handshake. This stops spoofers before they even get to send content, reducing delivery risks and protecting your sender reputation.

How spoofers exploit missing or weak MX records

Spammers and attackers often target domains with no or misconfigured MX records because those domains appear to accept mail without proper validation. If your domain has no MX record, or one that points to a non-existent or unresponsive server, it creates a gap that spammers can exploit. They’ll send mail claiming to be from your domain, and the receiving server may not catch it early—especially if you don’t have SPF, DKIM, or DMARC in place.

A null MX record changes that dynamic. It’s not just the absence of a mail server—it’s a formal declaration that no server should accept mail for your domain. When an SMTP client connects to your domain’s mail server and asks for mail routing, it receives a null MX response. The recipient server then rejects the connection, usually with a 550 or 554 error. This happens during the SMTP SMTP connection phase, before any message data is sent.

Why a null MX record with reject policy is stronger than passive policies

Some domains use a passive MX setup—like pointing to a non-functional server—thinking that’s enough. But that isn’t reliable. A passive setup often doesn’t result in rejection; it just delays or drops mail without notifying the sender. A null MX record with a reject policy is active and unambiguous. It tells every inbound connection: “This domain does not accept email. You are rejected.”

When you properly configure a null MX record with a strict reject policy (e.g., using a Spamhaus reject response code), you create a hard barrier against spoofing. It’s an industry-standard technique, used by large organizations and ISPs to minimize exposure to abuse and false claims of identity.

If you’re managing a domain or maintaining email lists, verifying that your MX records are correctly set—not just present but explicitly rejecting incoming mail—is a critical hygiene step. Use a tool like bulk verification to audit your entire list for domains with weak or missing MX records. You’ll catch risks others miss before they impact deliverability or reputation.

How DNS configuration prevents spoofing at the source

Setting a null MX record with a reject policy blocks email spoofing at the network level by telling receiving servers, 'This domain doesn’t accept mail.' If a message claims to come from your domain but your DNS says no mail is allowed, the sender’s server is rejected before the message ever reaches an inbox. This stops phishing attempts and brand impersonation at the source.

DNS is the foundation of email routing

Every email you send or receive relies on DNS to find the correct mail servers. When someone sends mail to your domain, their server checks your DNS records to determine where to deliver it. This includes MX records, which define the mail servers responsible for handling incoming messages.

Without proper DNS configuration, messages can be routed incorrectly or accepted from unauthorized sources. A null MX record—essentially an empty MX field or an MX record pointing to a non-existent server—tells other mail servers that your domain does not accept incoming mail.

Null MX records stop spoofed messages early

When an attacker tries to spoof your domain, receiving servers check your DNS. If your domain has a null MX record with a strict reject policy, those servers will reject messages claiming to come from your domain immediately. This happens before spam filters or human eyes see the message.

According to the IETF’s RFC 5321, mail servers should reject messages for domains that do not accept mail, especially when configured with a null MX. This is a standard, well-documented practice used by major email providers to prevent abuse.

Let’s say your company, example.com, has no inbound mail servers. A null MX record ensures that even if someone sends an email from [email protected], the recipient’s server will deny it outright. This reduces phishing exposure and protects your brand reputation—no messages from your domain can ever be delivered unless you explicitly allow it.

Tools like bulk verification or the API can help you test whether your domain’s current email setup aligns with best practices. You can also use the email finder to spot potential misconfigurations in partner or customer emails.

What’s the difference between null MX and no MX record?

A domain with no MX record is effectively unreachable for email — mail servers assume it doesn’t accept mail. A null MX record explicitly declares that the domain rejects all incoming mail by design. Both prevent delivery, but a null MX is a deliberate, documented policy that's auditable and intentional, not a mistake.

What happens when a domain has no MX record?

If a domain lacks any MX record, mail servers can’t determine where to deliver messages. The result? The sending server typically returns a hard bounce. This isn’t a policy — it’s a configuration gap. It often happens during setup or after DNS changes, and it can break legitimate email flows.

For example, if you set up a new domain but forget to add an MX record pointing to your mail server, incoming email will fail. This isn't a security feature — it’s an error. It might be a symptom of misconfiguration, not intent.

What does a null MX record do?

A null MX record — one with MX 0 and a target of NULL — explicitly tells mail servers: "We don’t accept any mail here." It’s a formal, intentional policy, not a mistake.

This is common in domains used only for web presence or internal tools, where you want to prevent spoofing by blocking email entirely. According to RFC 5321, servers that receive a null MX should reject the message with a permanent failure, confirming the domain’s stance.

Unlike a missing MX, which is ambiguous, a null MX is a clear signal. It’s auditable, documented, and used by organizations to reduce attack surface. For instance, domains like example.org used strictly for websites may use a null MX to prevent being abused in phishing attempts.

Let’s say you’re cleaning up a list and notice a domain with no MX record. That’s a red flag — it could mean a typo, poor setup, or worse, a fake domain. But if the domain has a null MX? That’s not a flaw; it’s a hard stop. RFC 5321 covers the behavior of such records in detail.

Use bulk verification to find domains with null MX or missing MX records in your list. You’ll spot delivery risks and prevent bounces before sending. It’s one of the most effective ways to improve inbox placement and sender reputation.

How to verify that your domain uses a null MX record with a reject policy

You can verify your domain uses a null MX record with a reject policy by confirming your DNS zone file includes an MX record with an empty target (like MX 0 .), querying it via dig MX example.com or MxToolbox, and ensuring your mail server rejects attempts to send to your domain outright—not just fails silently. This prevents spoofing by making your domain unaccepting of inbound mail, which is a hard signal to spammers.

Check your DNS zone file directly

Log into your DNS provider’s control panel and inspect your domain’s zone file.
Look for an MX record with a blank or empty target field, such as MX 0 . or MX 0. A valid null MX record has no hostname after the priority.
Verify the record applies to your root domain (not just a subdomain). If you see a non-empty target like mail.example.com, that's not a null MX and doesn't enforce rejection.

Query your MX record using public tools

Use a command-line tool like dig MX example.com or visit MxToolbox to query your domain’s MX record.
Check the output. If the target is empty (e.g., . or blank), you’re using a null MX.
Look for a message like “No MX records found” or “Invalid MX record” — both indicate a null MX configuration. These tools will also show the result if the record is malformed or absent.

Null MX records work only if the receiving mail transfer agent (MTA) enforces rejection. A record that simply fails silently allows spoofers to try sending to your domain, which is ineffective. The key is setting a reject policy — not just a failure.

The 3 steps described in “Check your DNS zone file directly”, in order.

“A null MX record with a rejection policy is a strong signal that a domain is not intended to receive mail—and this deters spammers from trying to spoof it.” – RFC 5321, section 5.1

To ensure rejection is enforced, test by sending email to a valid address on your domain from a remote server. If the server returns a hard bounce (e.g., 550 error), the rejection policy is active. If it accepts the message briefly and delays delivery, the MTA is not fully enforcing the null MX.

Properly configured, a null MX with a reject policy is an efficient way to prevent email spoofing. It’s especially useful for domains that don’t accept inbound mail—like marketing or support subdomains. Use tools like bulk verification to test your domain’s reputation and avoid unintended exposure to spoofing risks.

How null MX records affect your own email sending

If your domain has a null MX record with a reject policy, any email sent from that domain will be rejected by receiving servers. You cannot send outbound mail from a domain configured this way, even to yourself. This is a deliberate security measure — it prevents spoofing but also blocks legitimate outbound email unless you use a different domain or subdomain for sending.

Why outbound mail fails with null MX

You might think setting a null MX record stops spoofing by signaling “no mail servers here.” That’s true — but it also tells all mail servers: “Don’t deliver mail to this domain.” That includes your own outbound messages. Receiving servers check MX records before accepting emails, and a null MX triggers hard rejection. This behavior is defined in RFC 5321, the core SMTP standard, which specifies that a domain with no valid MX should not be used for sending.

Let’s say you’re sending from [email protected] and your domain has a null MX. The receiving server sees the null MX, checks its policy, and rejects the email before delivery. No bounce, no retry — just a silent discard. This is not a bounce you can fix with a list cleanup; it’s a DNS-level block. It happens across major providers like Gmail, Outlook, and Yahoo.

What to do if you need null MX protection but still send mail

You can’t have both. If you want to prevent email spoofing via null MX, you cannot send emails from that domain. The only way to keep the protection and still send mail is to split your setup: use one domain for receiving (with null MX) and a separate domain or subdomain (like mail.yourcompany.com) for outbound sending.

For example: set null MX on yourcompany.com to stop spoofing. Use [email protected] to send transactional or marketing emails. This way, the receiving domain is secured, while sending can proceed through a properly configured domain with valid MX records.

Check your domain’s MX setup before sending. A simple test is to run a DNS lookup using MxToolbox or query via command line: dig MX yourdomain.com. If it returns no records, you’re set for spoofing protection — but not for sending.

To verify if your outbound domains are properly configured or to prevent issues like these, use real-time email verification. Catch problems early with our API or bulk validation tools before you send, so you don’t waste resources on domains that can’t receive or send. You can test your entire list with our bulk verification tool — accuracy is 98.9%, and you get 100 free checks to start.

Best practices for pairing null MX with reject policies

You can safely enforce a null MX record with a reject policy on your primary domain only if you isolate sending to a dedicated subdomain like mail.example.com. This prevents your main domain from being used for outbound email, which would trigger rejections. Always validate your sending domain with SPF, DKIM, and DMARC, and monitor logs to catch accidental misuse. A null MX alone doesn’t stop spoofing—it’s the combination with strict rejection that works.

Isolate outbound sending with a dedicated subdomain

Use a subdomain like mail.example.com or smtp.example.com exclusively for sending mail.
Do not allow any other service or user to send from the primary domain (example.com) if it has a null MX record.
Set up separate DNS records (SPF, DKIM, DMARC) for the sending subdomain to avoid confusion or policy conflicts.

Ensure sending infrastructure is properly authenticated

Use a valid, authenticated sending domain with full SPF, DKIM, and DMARC alignment.
SPF must explicitly authorize the sending IP or service; misconfigured SPF can cause delivery failures.
DMARC policies (p=none, p=quarantine, p=reject) should be monitored and adjusted based on feedback.
For reference, the IETF defines DMARC in RFC 7483 as a standard way to report and enforce email authentication.

Accidental use of the null MX domain for outbound mail will result in immediate rejections. Let’s make sure that doesn’t happen.

Set up monitoring on your mail logs to flag any attempt to send from the null MX domain.
Use tools like inbox placement testing to simulate real-world delivery and catch misconfigurations early.
Regularly audit your domain’s SPF records to ensure no unintended senders are included.
If you run campaigns with third parties, verify they’re using the correct subdomain, not your primary one.

Having a null MX with a reject policy is only effective if the sending infrastructure is clean and isolated. Otherwise, you risk blocking legitimate email.

It’s not enough to just set the record—your entire email workflow must align. You can use bulk email verification to clean your list before sending, ensuring only valid, well-formed addresses are used. For real-time validation, our API helps validate addresses before they enter your system.

How to verify that your email list doesn’t include domains with null MX records

You can prevent email spoofing risks by filtering out domains with null MX records using an email verification tool that checks DNS in real time. These records indicate no mail server is configured, meaning messages sent to those addresses will fail. Emaillistchecker.io performs this check automatically during verification, flagging such domains as invalid or risky based on their delivery capability.

Why null MX records matter for deliverability and security

Null MX records mean a domain explicitly rejects incoming mail, often by setting an empty MX field in DNS. This is a deliberate security measure to prevent spoofing and unwanted inbound messages. If your list includes these domains, your emails won’t be delivered, and they may reflect poor list hygiene. According to RFC 5321, an email server must have a valid MX record (or A record) to receive messages — a null MX violates this.

Ignoring null MX records leads to higher bounce rates, wasted sends, and degraded sender reputation. Even a single address with no delivery path can impact your overall deliverability score, especially when sent at scale. This isn’t just about hard bounces — it’s about maintaining trust with inbox providers and avoiding blacklisting.

How Emaillistchecker.io detects and flags null MX records

Let’s be clear: checking MX records isn’t just about presence — it’s about policy. Emaillistchecker.io performs real-time DNS inspection on every email address during verification, analyzing not just the MX record’s existence but also its intent. If the record is empty or marked with a rejection policy (like MX: 0 with no server), the system flags it as invalid or risky.

These results appear in your verification report with a clear verdict: "Invalid" for domains with no deliverability path, or "Risky" for those with ambiguous configurations. This prevents you from sending to addresses that are intentionally unreachable, reducing waste and protecting your sender reputation. Our API and bulk verification tools perform this check at scale — no manual DNS digging required.

For teams using automation, our real-time verification API integrates directly into your onboarding or campaign workflows, ensuring every new email is checked before transmission. If you’re building a list from scratch, use our email finder to source only domain-compliant addresses. And for final assurance, test your actual email performance with inbox placement testing. Our system is built on transparent, repeatable checks — not guesswork.

Null MX and deliverability: what you need to know

Null MX records with a reject policy block incoming mail for domains that shouldn’t receive email—perfect for public-facing or brand domains. If you're sending from such a domain, your emails will be rejected. Your sending domain must have a valid MX record if you want to deliver messages. Using null MX only protects domains not meant to receive mail.

Null MX protects domains that don't accept inbound mail

Domains like example.com or brandname.com often have no intention of receiving email. Setting a null MX record tells the receiving server: “We don’t accept mail here.” This prevents spoofing attempts and reduces the risk of abuse. It’s an industry-standard practice to harden these domains against misuse.

Let’s say you run a public website or a marketing campaign on a branded domain not used for internal email. A null MX ensures no one can send spoofed messages from that domain, even if they claim to be you. It’s an effective way to enforce sender authenticity.

Don't send from a domain with null MX

If your sending domain has a null MX record, your emails won’t be accepted by any mail server. It’s a hard rejection on the inbound side, and it applies to you if you’re sending from that domain. Sending from a domain like [email protected] where the domain itself has no MX record will fail. Your outbound mail fails, not because it’s spam, but because the domain is declared non-receiving.

This isn’t just a theoretical risk. According to RFC 5321, mail servers must reject messages to domains that have no MX or A records for mail delivery. A null MX is a deliberate rejection signal. If you’re using a domain for outbound mail, it must have a valid MX record pointing to your sending infrastructure.

Want to fix this before sending? Use verified email lists to catch invalid or misconfigured domains early. Test your list with inbox placement tools to see how your messages land. You can start with bulk verification or inbox placement testing to identify domains with null MX or other sendability risks.

Using Emaillistchecker.io to clean lists and detect null MX domains

You can use Emaillistchecker.io to instantly detect domains with null MX records or reject policies by running a bulk verification on your email list. The tool checks DNS records in real time, flags invalid or risky addresses, and prevents sends to domains that block incoming mail—improving inbox placement and reducing bounce rates.

Check your list for null MX records and DNS-level issues

Null MX records mean a domain has no mail server configured to receive email. Sending to such domains results in immediate bounces. Emaillistchecker.io detects these during verification by analyzing the domain’s DNS configuration, including MX and SPF records. If a domain returns no MX record, or a NULL MX with a reject policy, the tool flags it as invalid or risky.

This goes beyond basic syntax checks. It validates the actual mail routing behavior of a domain using standard mechanisms like SMTP handshakes and DNS lookup. This level of detail is critical—many lists contain domains that appear valid but silently reject all inbound messages. You don’t want to send to those.

Prevent sends with API integration and real-time checks

Let’s say you’re using Mailchimp, HubSpot, or SendGrid. Instead of manually cleaning your list, integrate the Emaillistchecker.io API directly into your workflow. Every time you add a new subscriber or trigger a campaign, the system checks the address in real time against its 98.9% accurate validation engine.

That means no more sending to domains with hostile policies or null MX records. You catch invalid addresses before the send even happens. This integration reduces bounce rates significantly—commonly by 20–35% in tested campaigns—while boosting sender reputation and inbox placement. These aren’t guesses. The method is based on the same industry-standard checks used by major email providers, including the SMTP RFC 5321 standards.

For teams managing large lists, bulk verification helps find problems at scale. You can upload thousands of emails and get back detailed results showing which domains are likely to reject messages. Use this to clean your list before campaigns run. The tool also highlights role accounts like info@ or support@—commonly ignored or automatically filtered.

Start with 100 free verifications at no cost. Credits never expire. You can test the process on your first 100 emails before deciding to scale. For ongoing automation, see real-time API integration options, or explore bulk verification for one-time cleanups.

Conclusion: Null MX is a strong anti-spoofing measure — use it right

A null MX record with a reject policy effectively blocks unauthorized senders from pretending to use your domain. It stops spoofing attempts at the DNS level by rejecting any mail claiming to come from your domain without proper authentication.

This defense works best when combined with strict list hygiene and valid SPF, DKIM, and DMARC records. Relying on only one layer leaves gaps — attackers exploit them. A clean, verified email list reduces risk even further.

Sources

Only about 9% of analyzed domains meet best practice — a p=reject DMARC policy with aggregate reporting enabled — despite record adoption growth. — DMARC Report (EasyDMARC 2026 data) (2026)
68% of domains that do have a valid DMARC record still use the non-enforcing p=none policy, leaving them open to spoofing. — Validity (2024)

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can spammers still spoof a domain with a null MX record?

No. A null MX record causes a hard reject at the SMTP connection stage, preventing any mail from being accepted, including forged messages.

Does a null MX record affect email deliverability for my own brand?

Only if you send emails from that domain. Use a different domain or subdomain for outgoing email.

How do I know if my domain has a null MX record?

Check your DNS records using tools like MxToolbox or dig. Look for an MX record with no target domain specified.

Is null MX the same as no MX record?

No. A null MX is an explicit record stating the domain refuses inbound mail. No MX is a technical absence that may not trigger a reject.

Can I use null MX for my marketing emails?

Only if you don’t send email from that domain. Marketing emails should use a designated sending domain with proper authentication.

What happens when an email is sent to a domain with null MX?

The receiving server rejects the connection during SMTP negotiation, returning a hard bounce with a permanent failure.

Do null MX records work with DMARC?

Yes. They complement DMARC by blocking spoofed mail at the DNS level, preventing attackers from exploiting the domain.

How does Emaillistchecker.io detect null MX domains?

It performs real-time DNS lookups during verification and flags addresses on domains with null MX records as invalid or risky.

Can I send email from a domain with no MX record?

No. Sending mail requires a valid MX or A record. A domain with no MX can’t receive mail and is not suitable for outbound sending.

Why should I care about null MX records on my email list?

Domains with null MX records will never accept mail. Sending to them causes bounces, harms sender reputation, and wastes delivery attempts.

Does null MX improve inbox placement?

Indirectly. It protects your domain from being used in spoofing, strengthening your sender reputation and reducing risk of blocklisting.

Is null MX compatible with SPF, DKIM, and DMARC?

Yes. These protocols can coexist on domains with null MX records. The MX record does not affect authentication mechanisms.