MX priority explained in one line: senders try the lowest preference number first and use higher numbers only when those hosts fail. That is ordered failover, not load balancing. Publishing Google at 10 and MailerZ at 20 does not split traffic fairly. It leaves leftover MX in charge until Google fails — which it rarely does — so MailerZ never sees the mail. One operator. One set.
Quick answer for mx priority explained
MX lookup returns hosts and preference numbers. DNS email routing uses that list. The mail exchanger with the smallest preference is the one a well-behaved sender tries first. RFC 1035 describes the record. RFC 5321 describes how SMTP uses it. Neither document promises a weighted farm.
People keep two vendors “for safety.” Safety would be a documented rollback and a saved old set, not two live primaries. If the leftover host still accepts mail, it is not a backup. It is the path.
Equal preference values can be tried in an order the sender chooses. That is still not a load balancer you control. Different networks will pick differently. You will debug ghosts.
MailerZ treats leftover MX as a hard stop because customers cannot see the mail that went to the other operator. Priority numbers do not fix that. Deletion does.
MailerZ Free is one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.
mx lookup: the real decision
Registrars add their own MX when you click “email forwarding.” You later add MailerZ at a different priority and think you layered services. You layered loss.
Cloudflare routing MX left beside a new forwarder is the same bug with a trendy name. Cut routing hosts if you left that product.
Enterprises ask for dual-vendor MX as a checkbox. Unless both operators share a designed failover contract, you have two inboxes and no map.
Criteria: who is the only inbound operator, what the public lookup shows, whether you saved the old set, and whether an external probe lands in the destination you named.
| What you published | What senders do | What you should do |
|---|---|---|
| One operator, one or more equal hosts they documented | Use that operator | Keep it |
| Google 10 + MailerZ 20 | Use Google until it fails | Delete Google MX if you left the suite |
| Two operators at the same preference | Undefined split | Pick one |
| Registrar forwarding + anyone | Whoever the registrar still lists | Turn it off |
Prove the hop on one domain before you print a new address on a invoice or a form.
Start free — one domainTechnical mail flow for mx priority explained
A sending resolver queries MX. It sorts by preference. It connects to the first host that answers SMTP. If that host accepts the recipient, the higher preference never runs. Backup MX only matters when the primary refuses connections or is unreachable — not when it cheerfully accepts and stores mail you will not read.
That is why leftover Google MX is fatal. Google accepts. Your new map never executes. Priority 20 is a museum label.
TTL delays the story. You deleted a record. A resolver still has the old set. Probes from one network look clean. Another network still hits leftover. Wait and check more than one public view.
AAAA and IPv6 paths can surprise you if only one host is dual-stack. That is still not load balancing. It is reachability.
Transport still follows IETF RFC 1035 — Domain names. Envelope commands are not the header block people see. MailerZ may rewrite only the envelope return path with Sender Rewriting Scheme. MailerZ is a product of Secuno LLC. It is inbound MX plus authenticated SMTP. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. It is not Google Workspace, not IMAP, not webmail, and not an open relay. Unhosted or unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Probe from another mailbox. MailerZ is not SOC 2, not ISO 27001, and not HIPAA.
dns email routing: step-by-step setup
Treat MX like a single door. Decorate it with the hosts the operator listed. Do not hang a second door with a higher number and call it architecture.
- Screenshot the current MX set. Save it for rollback.
- Add and verify the domain on MailerZ. Recreate aliases.
- Publish only the MX hosts MailerZ shows, at the preferences they show.
- Delete every other MX, including registrar helpers and old suite records.
- Check more than one public lookup. Confirm leftover names are gone.
- Probe from another mailbox. Confirm Header From and history.
- Keep the screenshot until you trust the cut.
- After any host or nameserver change, re-audit MX before you talk about catch-all or SMTP.
Client clicks for Gmail live in IETF RFC 5321 — Simple Mail Transfer Protocol. Outlook uses a manual SMTP identity when you also send as the domain. Incoming mail stays at the destination mailbox.
Failure modes and proof
“We load balanced email” — you split it. Pick the operator.
Backup MX that accepts mail and has no alias map. That host is a black hole or a surprise inbox.
Priority flipped but TTL not expired. Wait. Do not add a third vendor.
Self-send still works via Gmail short-circuit while the world hits leftover. External probe.
Editing records at the registrar while nameservers are at Cloudflare. You edited a copy nobody queries. See the nameserver article next.
Use a public MX view before you cut. Leftover hosts split mail even when the new record looks correct in one resolver.
Open leftover MX troubleshootingMailerZ workflow and product boundary
MailerZ inbound is the MX set we publish for your domain. We do not ask you to keep Google “as backup.” We ask you to delete leftover hosts. Tools on this site help you see what the public sees.
Outbound SMTP is unrelated to MX priority. Send-as does not fix inbound splits.
Not a DNS host. Not SOC 2. Not an inbox SLA. If you need designed dual-site mail, you are buying a suite or an enterprise MTA, not a forwarder layer.
Related pages: troubleshooting, tools, docs. Those routes exist on this site. Do not invent a second MX religion beside them.
mail exchanger
The cost of a wrong priority story is missing customers, not an extra invoice line. Solo cannot see mail Google accepted.
Time spent on dual-vendor MX is better spent on a rollback screenshot and a probe checklist.
Agency books of business fail the same way, forty times. Teach priority once.
MailerZ Free is one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise. Time is part of cost. An afternoon on leftover MX usually costs more than Solo.
Preference 0 is not “more professional.” Use the numbers the operator documented.
CNAMEs at the zone apex are a different footgun. MX should be MX records to the hosts you were given.
If a migration needs overlap, overlap in time with a planned cut, not overlap in two live primaries.
Teach the client to read an MX lookup. That skill prevents the next leftover.
Field notes you can reuse
Worked example: Google 10 and MailerZ 20
The screenshot looks like architecture. Senders try Google first. Google accepts. MailerZ is idle. Customers who “vanished” were delivered to a leftover suite mailbox nobody reads. MX priority explained is an order. The higher number is not a share. Delete the leftover. One operator.
Equal preferences across two vendors are worse. Different networks pick differently. You will get “it works on my phone.” That is an mx lookup disagreement, not a flaky inbox. Dns email routing should have one story. The mail exchanger you want is the one whose alias map you can see.
Backup MX that accepts mail and has no map is a black hole. Backup MX only helps when the primary cannot be reached. A healthy leftover host is not unreachable. It is hungry.
TTL and multiple views
You deleted a record. One public view is clean. Another still shows the suite. Wait. Check again. Do not add a third vendor while caches die. Self-send from Gmail can stay green the whole time. External probe is the test.
Registrar forwarding products rewrite MX when you click a friendly toggle. They do not care about your priority essay. Turn the product off if it is authoritative. If NS already left the registrar, the toggle may be editing a dead copy. Look at NS first.
Outbound SMTP does not repair inbound priority. You can send as the domain and still miss inbound on leftover MX. People conflate the two hops because both say “email.” Keep them separate in the ticket.
What to save
Screenshot the old set before delete. Agencies that skip this cannot roll back. The migration planner exists so the screenshot has a home. Preference numbers should match what MailerZ documented, not a superstition that 0 looks serious.
Teach the client to read MX. That skill prevents the next leftover more cheaply than a retainer hour. Priority is not load balancing. Say it until it sticks.
Operator brief
A longer operator brief for mx priority explained
Teams that bookmark MX Priority Explained: Why It Is Not Load Balancing usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about mx priority explained as a send-as, catch-all, or comparison problem.
MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is not a hosted mailbox, not IMAP, not webmail, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.
If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening mx priority explained. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.
Catch-all forward is not a safety feature for mx priority explained why it is not load balancing. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.
Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.
Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear mx priority explained works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.
Agencies should keep mx priority explained per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.
Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.
Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.
When MX Priority Explained: Why It Is Not Load Balancing is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how mx priority explained stays a runbook instead of an incident.
A second worked pass for mx priority explained: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a mx priority explained mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.
A third worked pass: print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.
How to read a live MX set with a client on the call
Open two public lookups. Read preference numbers out loud. The lowest number is the path if that host accepts SMTP. If Google is 10 and MailerZ is 20, you are not load balanced. You are still on Google. Delete the leftover. If two vendors share the same preference, you have an uncontrolled split. Pick one operator.
Ask whether anyone clicked a registrar forwarding product last year. Those toggles rewrite MX without a meeting. Ask where NS points. If the client edited the registrar while Cloudflare answers, the screenshot is a copy. Edit the live zone. Then look at MX again.
Save the old set before delete. Wait through TTL. Probe from another mailbox. Do not add a third vendor while caches die. Do not call a backup MX that accepts mail and has no alias map a safety feature. It is a black hole or a surprise inbox.
Outbound SMTP will not repair a leftover inbound host. You can send as the domain and still miss inbound. Keep the hops separate on the call. Priority is an order. It is not a percentage. Say it until the client can repeat it.
Teach the client to run the lookup themselves next quarter. That skill prevents the next leftover more cheaply than a retainer hour. Preference 0 is not more professional. Use the numbers the operator documented. CNAMEs at the apex are a different footgun. MX should be MX records to the hosts you were given.
FAQ
- What is the safest way to handle mx priority explained?
- Publish only the MX hosts your inbound operator listed, delete leftover hosts, and confirm a public lookup. Do not keep a second vendor at a higher preference as fake backup.
- Does this require a new mailbox?
- No. MX selects the inbound operator. Gmail or Outlook remains the store when you use a forwarder.
- Will it work with Gmail or Outlook?
- Those products are destinations or leftover MX sources. If they still publish MX, senders may never reach MailerZ.
- What DNS records are involved?
- MX, plus the nameservers that actually answer. Verification TXT. Sending records are separate.
- What should I test before production?
- Public MX view from more than one resolver, then an external inbound probe. Do not trust self-send.
Key takeaways
- Lower preference is tried first.
- Priority is not load balancing.
- A leftover host that accepts mail wins forever.
- Equal preferences are an uncontrolled split.
- Save the old set before delete.
- Probe from another mailbox.
- Outbound SMTP does not fix inbound MX.
- MailerZ wants one operator set.
Conclusion and next action
Read MX as an order, not a percentage. Publish one operator. Delete leftovers. Keep a screenshot. Prove inbound.
Next action: look up the domain from a public tool, delete every host that is not MailerZ, send a unique subject from another mailbox.
Start free after the lookup is honest. Sign in if MX already points here and mail is still missing — then we talk leftover cache, not priority theory.
One MX set
Start free after you can show a single operator in a public lookup.
Save the old set. Publish MailerZ. Delete leftovers. Probe from another mailbox.
Review quarterly, or sooner if provider behavior, pricing, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.