DNS Provider Guides

Route 53 MX record priority and formatting explained

Priority is order. Demoting is not deletion. Hostnames not IPs.

MailerZ editorial · Secuno LLC16 min read

Route 53 MX priority is not load balancing. Lower numbers are tried first. Two owners at different priorities is still leftover MX if the second owner is an old host. Formatting is priority plus a hostname ending with a dot in some views. Do not put an IP in MX. Do not keep Google MX at 10 “as backup.” Exclusive MailerZ values from the dashboard. Priority tricks are not deletion.

route 53 mx priority: the decision
Priority is order, not a safety net between vendors.

Quick answer for route 53 mx priority

Priority chooses order among records you meant to publish together.

RFC 1035 MX points at hostnames.

A second vendor at priority 20 is leftover MX with extra steps.

Route 53 will store whatever you type. It will not save you from a split.

Null MX is 0 and a dot. That rejects all inbound. Do not leave it if you want mail.

Start free, copy dashboard MX, publish exclusive, probe.

Authoritative mail transport is defined in IETF RFC 1035 — Domain names. Product path: docs, tools, and troubleshooting.

User problem and decision criteria

People think priority is HA across Google and MailerZ. It is a split.

Formatting: missing trailing dot or a trailing domain duplication breaks lookups.

IPs in MX are invalid.

CNAME at zone apex plus MX confusion is a different mess.

No inboxing from pretty priorities.

Agencies should screenshot the MX set.

Do not invent MailerZ priorities. Copy them.

TTL still applies.

Technical mail flow

route 53 mx priority flow
Exclusive MX. SRS envelope. Header From intact.

Resolver asks MX. Gets a set. Tries lowest preference first.

If that set contains two companies, senders split as they fail or as they pick.

Exclusive set: one company.

Then MailerZ hop.

Two resolvers to see what the world sees.

Step-by-step setup / decision path

route 53 mx priority steps
Map, exclusive MX, third-mailbox probe.
  1. Copy MailerZ MX lines from the dashboard.
  2. In Route 53 create those only.
  3. Delete other MX including demoted leftovers and unexpected null MX.
  4. Save. Query two resolvers.
  5. Confirm hostnames match.
  6. Probe.
  7. Do not add a backup vendor.
  8. Screenshot.

Classify the next failure before a second DNS edit.

HOLD unknown unless you wrote a FORWARD reason.

Quote live pricing before promising alias counts.

Failure modes and proof

Google at 10, MailerZ at 0: still two owners if both answer.

Demote not delete.

IP in MX.

Typo hostname.

Null MX left.

Self-send.

Edited ghost zone.

Two v=spf1 while you were there.

Inboxing claim.

Priority as load balance story.

Missing map before MX.

TTL ignored.

MailerZ workflow and product boundary

MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. Not Workspace, not IMAP, not an open relay, not a campaign ESP.

Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. Exclusive MX. Hold unknown on Free. Copy SMTP host, port, and TLS or STARTTLS from the dashboard when you send.

Free: one domain, three aliases, one seat, fourteen-day store, fifty outgoing a month, no send-as. Solo forty dollars a year, fifteen aliases, ninety-day store, one hundred outgoing, five send-as per hour. Starter eight or eighty. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote pricing. No SOC 2, ISO, HIPAA, SLA, or inboxing percentage.

Cost, alternatives, and trade-offs

A format typo is a silent reject.

Leftover demoted Google is an incident.

Time in the wizard is cheaper than a split week.

Agencies: teach priority myths once per team.

TTL wait still costs calendar.

No fake SLA.

Probe is cheap.

Dashboard copy-paste beats memory.

Operational depth

Read the dashboard every time. Do not reuse last year’s hostname from memory.

Route 53’s record wizard may put the zone name on the value if you type a relative host wrong. Open the row and read it.

If MailerZ shows two MX hosts, that is still one vendor. That is fine. Two vendors is not.

Null MX is a published “we do not receive.” Remove it to receive.

Priority 0 versus 10 inside one vendor is their design. Do not add a third party at 20.

Query dig or the site tools, not only the console.

HOLD and aliases still required.

No ports in MX.

Explain to clients that priority is not HA across brands.

Screenshot before delete.

Re-query after.

TOFU honesty: this is formatting, not a folder guarantee.

Route 53 formatting that actually publishes

Route 53 MX is a priority number and a mail hostname. The hostname is not an IPv4 address. It is not a CNAME you invented for “mail.” Copy the hostnames and priorities from the MailerZ dashboard. If the console wants a trailing dot, use it the way Amazon documents for that record type. Guessing the dot is how you publish a relative name that does not resolve.

Priority is try-order among records you intend as one service. MailerZ may publish more than one host in one exclusive set. That is still one owner. Google aspmx at 10 and MailerZ at 20 is two owners. Senders that still prefer 10 never appear in MailerZ history. Demoting the old host is leftover MX with a smaller number. Delete it.

Weighted routing, latency routing, and failover policies that people love for websites are the wrong tools for MX. Mail exchangers are an ordered list in RFC 5321. A Route 53 alias to a load balancer is not an MX. If a blog told you to “health-check MX,” stop. You will split delivery in ways hop history cannot explain.

Apex CNAME conflicts still exist on some setups. If someone CNAMEd the zone apex, MX may refuse to coexist. That is a zone design problem, not a MailerZ outage. Fix the apex. Then publish exclusive MX.

Null MX is a lone-dot refuse. A refuse plus a real MailerZ host is a contradictory zone. Some senders bounce. Some try the host. Remove the refuse if you intend to receive.

Two resolvers after every save. Route 53’s own test button is not a second public resolver. If both still show aspmx, you did not delete leftovers or you edited the wrong hosted zone. Nameserver mismatch — registrar NS still pointing at Cloudflare while you edit Route 53 — is the usual “I saved it and the world disagrees” ticket.

TTL on MX is the clock after a correct exclusive publish. If two resolvers already agree on leftovers, you are not waiting. You are staring at a wrong RRset. If they disagree after a correct exclusive set, write the remaining TTL and wait. Do not add Google back “until it propagates.”

Verification TXT is a different record. It does not move mail. Do not rotate it to “fix priority.” SPF, DKIM, and DMARC matter when you send. They do not explain empty inbound history.

Self-send from Gmail to the same Gmail can hide a bad MX. Probe from another provider. Empty history plus leftover aspmx is leftover MX. Empty history plus exclusive MailerZ MX is a missing alias, a Free hold, or destination refuse after 250.

Formatting screenshots belong in the ticket: hosted zone name, each MX line, both resolver answers, hop row. Verbal “it looks like 10” is how a 20 leftover survives.

Multi-account AWS: confirm you are in the account that owns the zone. Editing a lookalike zone in another account publishes a perfect exclusive set nobody queries.

After a provider migration into Route 53, clone exclusive MailerZ MX on the new zone before you change NS. An empty Route 53 zone plus a NS cut is an outage. Priority theater will not save an empty zone.

Paid send-as will not fix a leftover MX. 550 on From is plan and identity. Free cannot send. Do not republish MX to debug SMTP.

Monthly: leftover lookup on two resolvers. The outage you avoid is a Friday restore of aspmx “as backup.” Route 53 makes that restore one click. The hop cannot refuse a published leftover.

Console traps and a copy-paste runbook

Route 53 record name for apex MX is often `@` or the bare zone name depending on the view. A mistaken `mail` name publishes MX for mail.example.com, not example.com. Customers send to hello@example.com. History stays empty. Check the record name before you debate priority.

Value field: `10 inbound.example-mailerz-host.` not `10 192.0.2.1`. IPs in MX are a format error. CNAME targets in MX are a format error. Copy dashboard hosts exactly, including any hostname MailerZ shows this month. Do not reuse last year’s blog comment.

Multiple MailerZ hosts at 10 and 20 can be one exclusive set. aspmx at 10 and MailerZ at 0 is still leftover if aspmx remains. Lowest number wins first. Delete the foreign owner. Do not “win” by numbering tricks.

Import zone file from Google: it will happily import aspmx. That is leftover MX with extra steps. Diff after import. Delete foreign MX before you change NS toward Route 53.

Private hosted zones do not serve public senders. If you edited the private zone, the public zone still has leftovers. Two resolvers on the internet, not inside the VPC.

IAM: the person who can change MX should not be “anyone with AWS console.” Write the role. Offboard that role when they leave. A departed admin restoring aspmx is a leftover MX incident with an HR date.

Change batches: do not mix A/AAAA website edits with MX in one apply if you can avoid it. When the site breaks, people revert the batch and restore leftovers.

Probe after apply: other mailbox, unique subject, hop row. If empty, copy both resolver MX answers into the ticket before the next apply. One change at a time.

SPF TXT is not MX. A missing include does not empty inbound history. Do not “fix priority” by editing SPF. Do not add a second include for a leftover hop.

TTL 300 feels fast until you publish leftovers and wait 300 seconds times every retry. Lower TTL before a planned exclusive cut. After leftovers exist, you wait the old TTL anyway.

Null MX and a real MX in the same zone is a lie. Remove the lone-dot if you receive. Priority will not reconcile a refuse plus a host.

If Route 53 is not the delegated NS, you are editing a diary. Fix registrar NS first. Then format MX. Then probe.

Send-as stays dashboard values. Route 53 will not authorize a Free From. 550 is not a priority bug.

Keep a rollback card: previous exclusive MX lines. Restore means those lines, not Google. Restoring Google is a class change, not a format undo.

Monthly leftover check belongs on the same calendar as AWS bill review. The click is cheap. The split inbound is not.

Worked scenarios for Route 53 MX priority

A startup keeps Google MX at priority 10 and adds MailerZ at 0 'so Google is the backup.' Senders that prefer the lower number hit MailerZ. Senders that fail over, or that still cache the old set, hit Google. That is leftover MX with extra vocabulary. Priority did not create high availability. It created a split.

Someone types an IPv4 address into the Route 53 MX value because a forum said it was faster. MX points at hostnames. RFC 1035 is not optional. The record may save. The internet will not treat it as a valid exchanger. Delete it. Paste the dashboard hostname.

A relative hostname is entered without understanding Route 53's origin rules. The console shows mail.example.com.example.com. Lookups fail or land on a host you do not operate. Open the row. Read the fully qualified name. Trailing dots matter in some views. Guessing is how you publish a fiction.

A leftover null MX (priority 0 and a single dot) sits next to a real MailerZ line because a prior 'we do not receive mail' experiment was never cleaned up. Some implementations will treat the set as hostile. Remove the null MX if you want inbound. Do not 'out-prioritize' it. Delete it.

An agency copies last year's MailerZ hostname from a screenshot instead of the live dashboard. The host has changed or the set now has two names for one vendor. Memory is leftover MX's cousin. Copy today. Query two resolvers. Then probe from a third mailbox.

A Terraform apply recreates an old google MX module because nobody removed it from state. The UI looked exclusive last week. This week it is not. Infrastructure as code is still leftover MX if the module still exists. Grep the repo. Treat the module like a live record.

Practice and anti-patterns in Route 53

Practice: copy the exact MX set from the MailerZ dashboard every cut. Anti-pattern: reuse a hostname from a Slack thread dated last spring.

Practice: delete every MX that is not that set. Anti-pattern: demote Google to 20 and call it a safety net. Safety nets that still answer are second owners.

Practice: query two public resolvers after save, not only the Route 53 console. Anti-pattern: trusting the pencil icon because the form did not error.

Practice: screenshot the MX set before delete. Anti-pattern: deleting from memory during a launch window and then arguing about what used to exist.

Practice: keep website A and AAAA records out of the MX conversation. Anti-pattern: pointing MX at the web host because 'the site and mail are the same company.' They are not the same record type.

Practice: one vendor. If MailerZ shows two hostnames, that is still one vendor. Anti-pattern: adding a third-party at 20 'for HA.' That is a split, not HA.

Practice: HOLD unknown and named aliases after MX is exclusive. Anti-pattern: celebrating a pretty priority table while catch-all FORWARD dumps typos into finance.

Operator closeout after an MX edit

Closeout lists every MX name and priority the world can see on two resolvers. If a leftover remains, the ticket is not closed. Priority tricks do not close leftover MX.

Closeout includes a unique third-mailbox probe to each public alias. Self-send from the founder's Gmail is not the gate. Open the original. Confirm Header From.

Closeout names the TTL you actually read, not a folklore day. Wait that clock plus a buffer before you cancel an old mailbox seat. Cancel too early and the leftover host still answers for cache holders.

If send-as is in scope, closeout says paid plan and dashboard SMTP values. Do not write 587 from memory. Free has no send-as. A 550 is not a reason to add Google MX back.

Terraform or pulumi state is part of closeout if you use it. The console and the repo must agree. Otherwise next Monday's apply undoes tonight's honesty.

Agencies attach the screenshot to the client ticket. Juniors should be able to replay the edit without a call. That is the point of a runbook.

Edge cases in MX formatting

CNAME at the zone apex plus an MX at the same name is a different class of pain. Some providers forbid it. Do not 'fix' it by stuffing an IP into MX. Fix the apex story with the records the DNS host supports.

Weighted or latency routing on the MX name's A record is not MX priority. Do not confuse Route 53 alias tricks on A with the MX preference field. Mailers follow MX preference, then look up the host.

A secondary hosted zone in the same account still has old MX. You edited the pretty one. Resolvers still see the zone that NS actually names. Confirm NS at the registrar before you congratulate yourself.

Private hosted zones do not answer the public internet. Publishing MailerZ MX only in private DNS is a silent reject for customers. Public zone, exclusive set, then probe.

Internationalized domain names and unexpected Unicode in a hostname paste will fail in ways that look like 'DNS is fine.' Paste ASCII from the dashboard. Do not retype from a phone screenshot.

A null MX you published during a brand pause will keep rejecting after you 'added MailerZ at 10.' Delete the null. Exclusive real hosts. Then wait TTL.

Field notes from Route 53 tickets

The most expensive tickets are demotions. Someone read that lower numbers are tried first and concluded the old host at 50 is harmless. It is not harmless if it still answers. Delete.

The fastest tickets are copy-paste from the dashboard plus a two-resolver query. The slowest are 'we will keep both until we are sure.' Sure is exclusive plus a probe, not a week of coin flips.

Website teams will republish email products from a wizard. Morning re-query after a site launch is cheaper than a donor complaining. Route 53 is not immune to a sibling product writing MX.

Priority 0 versus 10 inside one vendor is their design. Do not add a story about load balancing across brands. That story is how leftovers survive reviews.

Use /tools and /troubleshooting when the console looks right and the world disagrees. The console is one view. RFC 1035 is what senders implement.

No ports belong in MX. If someone asks for 587 in the Route 53 row, they are mixing SMTP client settings with inbound DNS. Separate those tickets.

Handoff memo for the DNS owner

The live MX set is whatever two public resolvers return, not whatever the last PR description claimed. Paste those listings into the memo.

The dashboard is the source for hostnames. The memo says 'copy again on the next change,' not 'these names are eternal.'

NS ownership is in the memo. If Route 53 is not authoritative, your beautiful MX set is a diary entry. Confirm registrar NS.

Leftover delete is a hard stop. The memo forbids demote-as-delete. Juniors will still try. The sentence has to exist.

Link /docs and /email-forwarding. Inbound MX is not send-as. Free has no send-as. Paid SMTP is a later chapter with dashboard ports.

Acceptance criteria for Route 53 MX

Two resolvers show only MailerZ hosts and the priorities MailerZ published. No Google, Microsoft, host, or null MX leftovers.

No IP literals in MX values. Hostnames match the dashboard, including trailing-dot behavior you verified in the console.

A unique third-mailbox probe landed for each public alias. Header From intact. Hop history exists. Self-send was not the gate.

IaC state matches the console, or you documented that the zone is console-only and locked the module out.

HOLD and named aliases exist. Pretty MX without a map is an incomplete cut.

No inboxing claim in the ticket. Priority is order. It is not a folder guarantee.

Operations review of MX sets

Quarterly: grep the repo for mx and google. Quarterly: re-query production zones. Those two habits catch silent republish and silent modules.

When MailerZ updates the recommended set, do not merge it with the old set. Replace. Two generations of one vendor plus an old vendor is still a mess.

Teach the team that failover in SMTP is not multi-vendor HA. RFC 5321 retries are not a license to keep a second company published.

If a record wizard duplicated the zone name, fix the value, do not add a third record to 'override' it. Overrides in DNS are fiction.

Quote /pricing before you promise alias counts on the same ticket as MX. MX exclusive does not raise Free's three-alias cap.

Start free on a lab hosted zone if the junior has never published MX. The first production edit should not be the checkout domain.

Quarterly review for Route 53 email DNS

Did any apply resurrect old MX? Did any website wizard? Re-query. Delete. Probe again.

Did anyone invent a port or an IP in MX? Remove the folklore from the internal wiki.

Does the screenshot in the last ticket still match live resolvers? If not, the packet is stale. Refresh it.

Are NS still at Route 53? A registrar change with an empty new zone is a different article, and it will break mail faster than a priority typo.

Confirm dashboard values again. Do not treat last quarter's hostname as scripture.

Author: MailerZ editorial, Secuno LLC. Review when provider UI, pricing, or MailerZ MX guidance changes.

Closing notes on priority myths

Route 53 MX priority orders records you meant to publish together for one vendor. It is not a safety net between Google and MailerZ. Formatting is hostname plus preference, not an IP, not a CNAME-as-MX stunt, not a leftover demotion.

Copy the dashboard. Publish exclusive. Query two resolvers. Probe from a third mailbox. Delete leftovers instead of ranking them. That is the whole job.

Start free, keep Gmail as the inbox, and do not let a priority table talk you into a split. Product path: /docs, /tools, /troubleshooting.

Priority myths that create leftover MX

Myth: priority 20 backup Google is safe. Fact: senders that still prefer 10 never hit MailerZ. History empty. Delete Google.

Myth: equal priority load-balances vendors. Fact: you get vendor lottery. Exclusive one owner.

Myth: weighted Route 53 records apply to MX like A records. Fact: MX is an ordered list. Do not health-check MX.

Myth: IP in the MX value is fine. Fact: MX needs a hostname. Copy the dashboard host. Trailing dot if the console requires it.

Myth: record name mail covers hello@example.com. Fact: that is mail.example.com. Apex name is the zone.

Myth: private hosted zone is “more secure email.” Fact: public senders never see it. Empty public history.

Myth: import from Google then add MailerZ. Fact: import is leftover MX until you delete aspmx.

Myth: SPF fix empty inbound. Fact: SPF is send path. Empty inbound is MX or alias or destination.

Myth: wait 48 hours no matter what. Fact: two resolvers already agreeing on leftovers means edit now. Disagreement after exclusive publish is remaining TTL.

Myth: send-as 550 is bad priority. Fact: Free cannot send. Unauthorized From is 550. Do not republish MX.

Myth: registrar and Route 53 both have MX is redundancy. Fact: only the delegated NS answers. The other is a diary. Or worse, you think you published and did not.

Myth: CNAME at apex plus MX. Fact: many providers refuse the mix. Fix apex. Then MX.

Myth: null MX plus MailerZ. Fact: contradictory zone. Remove the lone-dot refuse.

Runbook line: screenshot zone name, each MX line, two resolvers, hop row. Then stop or do one edit.

RFC 1035 names. RFC 5321 try-order. Dashboard hosts only. Exclusive. Probe from another mailbox.

Monthly leftover lookup. AWS makes aspmx one click. The hop cannot stop the click.

Start free after exclusive MX exists and a stranger can reach one alias. Priority theater is not a setup.

Rollback is last exclusive MailerZ set, not Google. Restoring Google is a class change.

FAQ

What is the safest way to handle route 53 mx priority?
Publish only MailerZ MX hosts from the dashboard. Use the priorities MailerZ shows. Delete every other MX. Do not demote old hosts. Query two resolvers.
Does this require a new mailbox?
No. MailerZ is not IMAP. Keep Gmail or Outlook unless you need a suite for other reasons.
Will it work with Gmail or Outlook?
Yes as destinations. Self-send is not proof. Use a third mailbox and open original.
What DNS records are involved?
MX: priority and mail hostname. Not A. Not CNAME as MX. One exclusive set.
What should I test before production?
A uniquely titled probe from an unrelated provider to each public alias. Confirm Header From and hop history.

Key takeaways

  • Priority is order, not multi-vendor HA.
  • Delete leftovers. Do not demote.
  • Hostnames, not IPs.
  • Copy dashboard set.
  • Null MX rejects all.
  • Two resolvers.
  • One vendor.
  • Then probe.

Conclusion

Format the MailerZ set correctly and delete everything else. Priority will not save a leftover host.

Start free, copy the dashboard MX, publish it exclusive in Route 53, and probe.

Start free on MailerZ