Null MX explained: why your domain rejects all email

Quick answer for null mx record

RFC 7505 defined null MX so parked and web-only domains could say no without inviting A-record fallback. The record is ordinary MX syntax with a special target. IETF RFC 5321 — Simple Mail Transfer Protocol still governs SMTP after a real host is chosen. Null MX means no host is chosen. Senders fail at lookup.

You will not see a MailerZ hop. History stays empty. The bounce lives at the sender. That is why “email is down” tickets have no Message-ID on your side. Public DNS is the evidence. Two resolvers showing 0 . is the whole diagnosis.

Keep null MX if the domain must never receive mail: a static site, a tracking domain, a brand you do not staff. Delete it if humans should reach aliases in Gmail or Outlook. Publish one MailerZ MX set. Leftover null MX next to real MX is invalid and unpredictable. Leftover Google MX next to a null MX is worse. One policy.

MailerZ does not publish null MX for you. The dashboard lists real hosts. If your registrar or a “harden this zone” wizard added ., that wizard is why the domain rejects all email. Product path after removal: docs and troubleshooting.

The real decision: refuse versus receive

Teams meet null MX in three stories. A security template added it to every zone. A previous vendor parked the domain. A developer copied a web-only checklist onto a domain that already printed hello@. The bounce looks like “email is broken.” The policy is working.

Decision one: should this apex receive mail at all. If no, null MX is the honest record. If yes, it must go. Decision two: who accepts mail after removal. One product. MailerZ or a suite. Not both. Decision three: what happens to the website. MX and the web host are independent. Deleting null MX does not move the site.

Keep null MX when

• No human address is printed and none will be.
• You want to block A-record fallback to a web server that should not speak SMTP.
• The domain is a pixel, CDN, or click-tracking host.
• You can document “this zone refuses mail” for the next operator.

Remove null MX when

• Invoices, support, or personal mail must arrive.
• You just added MailerZ aliases and nothing hits history.
• A wizard added . during a “secure DNS” pass.
• You migrated from a park and forgot the refuse record.

Agencies should grep client zones for exchange . during intake. It is cheaper than a week of “we cannot email you” after a marketing site launch that reused the company domain.

Null MX is not a spam filter. It refuses everyone, including your accountant. It is not catch-all hold. Hold still accepts the SMTP session. Null MX never starts one. It is not a 550 from MailerZ for an unknown local-part. There is no session to 550.

Do not use null MX as a temporary “maintenance mode” if vendors will retry for days and then give up. Use it only for domains that should stay silent. For a weekend cutover, keep the old real MX or flip to the new real MX. Silence is a policy, not a pause button.

Security teams like null MX because it shrinks the inbound surface. That is valid on zones with no printed recipients. It is malpractice on the company apex that still lists support in the footer. Shrink the surface by naming three aliases and holding unknowns, not by refusing the accountant. MailerZ Free is built for that smaller surface: three names, hold the rest, no send-as until you pay.

Do not confuse null MX with a firewall drop on port 25. A host can publish real MX and still refuse connections. That produces retries and different bounce text. Null MX fails earlier, at DNS. If you see connection timeouts to a real MX host, you do not have a null MX problem. If you see immediate “domain does not accept mail” style bounces and public MX is a dot, you do.

Some bounce messages say “no MX records.” That can mean empty MX, not necessarily 7505. Always look up the record. The words in a DSN are not standardized enough to trust. The wire answer is.

Technical mail flow with a null MX

The sender queries MX. RFC 7505 says a single MX with exchange “.” and preference 0 means do not deliver and do not use implicit A/AAAA. Older senders that ignore 7505 may still try the A record. That is why a web host sometimes sees surprise SMTP after you thought you “turned mail off” with no MX at all. Null MX is stricter than silence—for senders that honor it.

IETF RFC 1035 — Domain names still describes how the record is stored. The special target is the policy. You cannot CNAME around it. You cannot “priority 10 to MailerZ and 0 to dot” as a cute hybrid. Extra MX next to null MX violates the spirit of 7505 and produces sender-dependent behavior. One record. Or a real set. Not both.

After you publish MailerZ MX, flow returns to the usual path: connect, RCPT TO, alias table, SRS envelope, destination inbox. Header From stays original. Free holds unknowns. Paid FORWARD is optional. Send-as is a different hostname. Null MX has nothing to do with outbound SPF except that a domain which refuses inbound can still send if you publish SPF and SMTP. Those are separate. A click-tracking domain with null MX plus SPF is a normal pattern. A company domain with null MX plus printed hello@ is a mistake.

TTL applies. After you delete ., caches may keep refusing until TTL dies. Senders that already bounced may not retry soon. Ask them to resend after two resolvers show the new set. Do not add the null MX back “until we are sure.” You extend the refuse.

Step-by-step: keep or replace

1. Look up MX from two public resolvers. Write the exact answer. If you see 0 . and nothing else, you have a null MX.
2. Decide receive versus refuse. If refuse, stop. Document it. Do not create MailerZ aliases that will never fire.
3. If receive: add the domain in MailerZ, verification TXT, named aliases, then delete the null MX in the authoritative zone (the one NS points at).
4. Publish only the MailerZ MX set. No leftover Google, Microsoft, or ..
5. Confirm two resolvers. Wait TTL if they still show the dot.
6. Probe from another mailbox to each printed alias. Unique titles. History plus destination.
7. Tell vendors to resend anything that bounced during the null window. MailerZ cannot replay mail it never accepted.

Worked examples

A marketing site used a “secure zone” preset. The preset added null MX. The footer still said hello@. Every press email bounced. Two resolvers showed 0 .. They deleted it, published MailerZ MX, mapped hello on Free, and asked three journalists to resend. History filled. The preset was the outage.

A tracking domain clicks.brand.test had no MX and a web host that accepted SMTP. Spam landed on the app server. They published null MX. Surprise SMTP stopped. Correct use. They did not add MailerZ. Nobody should mail clicks.

An agency left . at the apex and added MailerZ MX at preference 10. Some senders refused all mail. Some tried MailerZ. The split looked like leftover MX. They removed the null record. One set remained. Probes stabilized.

A founder tested by emailing himself from Gmail to hello@ on the same Gmail destination. Gmail short-circuited and showed the message. External senders still hit null MX and bounced. The “it works for me” demo was the lie. Unrelated mailbox plus public MX ended it.

A park page at the registrar included null MX. After they moved the site to another host they forgot DNS. Six months of bounced invoices. The archive was empty because nothing was accepted. They replaced MX, mapped billing, and asked vendors to resend PDFs. Null MX does not hold mail for later.

Failure modes and proof

Migration planner keeps “delete null MX” on the same list as leftover Google MX. Both are inbound location bugs. Neither is a mailbox seat.

MailerZ hop recovery cannot replay messages refused at the sender. 14-day Free and 90-day paid stores start after accept. Null MX never accepts.

MailerZ workflow and product boundary

Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. Null MX is your DNS. MailerZ cannot override a public refuse.

What MailerZ does

• Accept mail only after real MX points at it.
• Treat leftover MX, including a leftover null, as a hard stop.
• Map named aliases to Gmail or Outlook.
• Hold unknowns on Free. Optional paid FORWARD.
• Preserve Header From. Envelope SRS only.

What MailerZ does not do

• Publish or remove null MX in your zone.
• Catch mail that senders never transmitted.
• IMAP, Calendar, or webmail.
• Send-as on Free.
• Inbox SLAs, review counts, SOC 2, ISO 27001, HIPAA. Controls: Security and Trust Center.

Plans: pricing. Free $0, 1 domain, 3 aliases, 1 seat, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/year, 3 domains, 15 aliases, 90-day, 1,000 outgoing, 5/hour. Starter $8 or $80, 5/50/5, 2,000, 10/hour. Business $19 or $190, 25/200/25, 4,000, 15/hour. Agency $39 or $390, 100/500/50, 8,000, 25/hour. Unlimited is $99/month or $990/year. Annual Starter, Business, and Agency include two months free versus monthly. Solo is yearly only.

Forwarding model: email forwarding. MX must be real before any of it matters.

Cost, alternatives, and trade-offs

Best practice for a null mx record: keep it only on zones that must stay silent. On a working company domain, delete it, publish one real set, prove from two resolvers, then probe. Do not invent review counts when you compare receiving products.

RFC 7505 is the spec: IETF RFC 7505 — Null MX. Read it if a vendor argues that “dot MX” is a typo. It is a standard refuse.

A website-only brand can keep null MX and still send transactional mail from a different domain that has real MX and paid SMTP. Do not force the silent apex to receive just because a form library defaulted From to the apex. Change the From to a domain that accepts replies, or accept that replies bounce.

Wizards, parks, and leftover dots

Registrar “email off” toggles often write null MX. Cloudflare and other DNS hosts sometimes offer a similar switch. The label is rarely “RFC 7505.” It is “disable email” or “prevent mail to this zone.” If two people manage DNS, one can enable that switch while the other adds MailerZ MX. Intake should include “who can toggle mail off.”

Parked domains at a registrar frequently ship with null MX plus a parking page. When you connect the domain to a site host, the park MX may remain. Site go-live is not mail go-live. Check MX on the same day you change A and CNAME records. The marketing win of a new homepage is how null MX survives into invoice season.

Subdomains inherit nothing useful here. Null MX on the apex does not automatically null mail.brand.test. A real MX on the apex does not cover app.brand.test. Each name that people type after the @ needs its own policy. If you print hello@brand.test, the apex is the name that matters. If you print hello@app.brand.test, the apex null MX is irrelevant and the subdomain needs its own records.

IPv6-only stories do not rescue a null MX. There is no host to reach. SPF alignment does not rescue it. DKIM does not rescue it. Catch-all FORWARD does not rescue it. Those features start after a sender connects. The dot forbids the connect.

If legal or finance requires a specific address to remain deliverable, that requirement forbids null MX on that domain. Write the obligation next to the zone. A refuse record cannot satisfy a contract to accept mail. A named alias plus a test Message-ID can—after real MX exists.

Communicate the change. If you remove null MX and start receiving, spam you never saw will arrive at named aliases and at hold. That is not a regression. That is the internet finding a door that was locked. Name the aliases you staff. Leave Free hold on. Do not answer the first week of harvest by enabling permanent FORWARD.

Proof packet: two resolver screenshots of 0 . (before), two screenshots of MailerZ hosts only (after), NS hosts, Message-IDs of probes, and the date you asked vendors to resend. Without the before shot, someone will claim MailerZ “was down.” The before shot shows there was no door.

After go-live, schedule a 48-hour check. TTL on some resolvers is stubborn. If one public resolver still shows the dot, do not add more aliases. Wait. If both show MailerZ and probes still fail, the problem left DNS and entered leftover hosts, alias table, or destination spam. Work that list in order. Null MX is done when the dot is gone everywhere you look.

If a second domain must stay silent (the tracking host) while the apex receives, write both policies in the same runbook. Operators who “copy MX from brand.test to clicks.brand.test” will accidentally make the tracker receive mail—or copy the null onto the apex. Two names. Two intents. Two records.

Do not pay for a higher MailerZ plan to fix null MX. Extra aliases and send-as cannot create hops that DNS forbids. Spend the afternoon on the zone, not on the upgrade card. Upgrade later if you need more names or SMTP after mail actually flows.

If you operate many client zones, add a CI or weekly check: any zone whose footer contains an @ but whose MX is . fails the audit. That single rule catches the wizard-and-footer collision faster than another status call. Null MX explained for an agency is an inventory rule, not a glossary slide.

FAQ

Key takeaways

• Null MX is MX 0 to “.” — an explicit refuse.
• Empty history is expected. Senders never connected.
• Do not mix null MX with real MX.
• No MX is not the same as null MX. A fallback may hit the web host.
• Delete the null record before you expect MailerZ hops.
• One real MX set after removal. Leftover hosts are a hard stop.
• Ask vendors to resend. Nothing was stored.
• Header From stays original once mail actually flows. Envelope SRS only.
• Free holds unknowns and has no send-as.
• MailerZ is not IMAP, not a suite, and not SOC 2.

Conclusion and next action

If you came here for null MX explained, the domain rejects all email because public DNS told senders to stop. That is a policy, not a downed mailbox. Keep the policy on silent zones. Remove it on zones that print addresses. Then publish one real MX set and prove it.

MailerZ cannot accept what senders never send. Next action: look up MX twice. If you see a dot and you need hello@, delete it, add one domain, map the names, and probe from another mailbox.

Review quarterly, or sooner if DNS presets add null MX by default. Author: MailerZ editorial, Secuno LLC.