Why mixed Google and custom MX records cause random delivery

Quick answer for mixed mx records google

SMTP follows public MX as IETF RFC 5321 — Simple Mail Transfer Protocol describes. DNS stores those records as IETF RFC 1035 — Domain names describes. If the set contains Google hosts and MailerZ hosts, senders are allowed to choose. Preference numbers bias the order. They do not merge mailboxes. A message that hits Google never creates a MailerZ hop. Empty history is not “MailerZ lost it.” MailerZ never saw it.

People leave Google MX “for Calendar” or “until we are sure.” Calendar does not require remaining an MX target. Sure is two public resolvers showing one set, plus probes from a non-Google mailbox. Dual MX is leftover MX. MailerZ treats leftover MX as a hard stop.

Typical leftover names: aspmx.l.google.com, alt1 through alt4, older googlemail.com hosts, and Microsoft equivalents if you mixed 365 too. Delete all of them in the zone the NS records actually point at. Confirm with two resolvers. Then probe. Docs: docs. Troubleshooting: troubleshooting.

The real decision: one inbound owner

The user problem is “some emails arrive and some do not.” Teams blame spam, catch-all, and SMTP passwords. The split is MX. Google-heavy senders (Workspace, Gmail business) often prefer Google’s hosts when those hosts are still published. Other senders prefer the custom host. Your test corpus is biased if you only mail yourself from Gmail.

Decision: Workspace owns inbound, or MailerZ owns inbound. If Workspace owns it, do not publish MailerZ MX. If MailerZ owns it, delete Google MX even if you still pay for Drive. Seats and MX are different purchases. Google Workspace — product overview is a suite. MailerZ is a forwarder.

Why “Google at 20” is not failover

Operators publish MailerZ at preference 10 and Google at 20 thinking senders will only use Google if MailerZ is down. Many senders still try Google. Some cache the whole set. Some pick randomly among equal or near-equal preferences. The 20 still receives a fraction forever. That fraction is your “random” loss. Failover you do not monitor is leftover MX with a story.

When mixed MX happens

• Registrar wizard added MailerZ and left the old Google five-pack.
• Someone edited the unused DNS panel. NS still served Google.
• A “rollback” re-added aspmx after a scare.
• Calendar migration advice was misread as “keep MX.”
• Two agencies published two products on the same Friday.

Agencies should photograph MX at intake. If both Google and a forwarder appear, stop alias work. Unmix first. Otherwise every later ticket is unprovable.

Free still holds unknowns and has no send-as. Mixed MX is independent of plan. Upgrading will not merge Google’s copy into MailerZ history.

Technical mail flow when MX is mixed

Sender A resolves MX, sorts by preference, connects to Google, delivers to a Workspace user or a Google bounce. Sender B connects to MailerZ, matches an alias, SRS on the envelope, Header From untouched, destination Gmail or Outlook. You see B in history. You do not see A. The customer saw A vanish or land in an old Workspace user nobody opens.

Gmail can short-circuit mail to itself. A founder emails hello@ from the same Gmail that is the destination. Gmail never uses public MX. The test “proves” MailerZ while the public set is still mixed. That is why this failure survives demos.

TTL extends the split after you delete Google MX. Some resolvers still answer the old set. Keep Workspace accepting during TTL if you still need those copies, then cancel. Do not add aspmx back when one vendor is slow. You restart the coin flip.

Catch-all FORWARD on MailerZ does not catch messages that went to Google. SPF and DKIM do not unmix inbound. Send-as 550s are a different path. Fix MX first. Tools exist to look at public DNS before you rotate SMTP secrets.

Step-by-step unmix

1. Look up MX from two public resolvers. Write every hostname. Circle Google and Microsoft leftovers.
2. Confirm NS. Edit the live zone, not the unused registrar panel.
3. Create named aliases on MailerZ before you delete Google if those names only exist in Workspace. Inventory first.
4. Delete Google MX (and Microsoft if present). Leave only the MailerZ set the dashboard lists.
5. Re-check two resolvers. Wait TTL if Google still appears.
6. Probe from a non-Google mailbox to each printed alias. Unique titles. History plus destination.
7. Search old Workspace for copies that arrived during the split. That is your “missing” mail. Move what you need. Then decommission.

Worked examples

A studio kept alt1.aspmx “just in case.” Half of Shopify notifications hit a forgotten Workspace user. MailerZ history looked healthy. They deleted the Google five-pack. Two resolvers matched. Shopify landed in the Gmail destination. The Workspace user was the graveyard.

An agency published MailerZ at Cloudflare and left Google MX at the registrar. NS was Cloudflare, so the registrar copy did nothing—until someone changed NS to the registrar during a domain transfer. Mixed MX appeared overnight. Photograph NS and MX together.

A founder’s Gmail tests always worked. Customers on Microsoft 365 failed half the time. The customers’ senders preferred the custom MX or Google depending on their resolver. External probes from two providers exposed the split. Self-send never would.

A team re-added Google MX after a weekend scare. The scare was destination spam, not MX. Dual MX returned. They deleted Google again and trained people to check spam before touching DNS.

A retailer needed Workspace Calendar. They kept Drive and Calendar seats and deleted MX. Mail went to MailerZ. Calendar still opened. The “we need Google MX for Calendar” belief was the whole incident.

Failure modes and proof

Migration planner should list “delete Google MX” as a hard gate. Proof is public DNS plus a non-Google probe plus a search of the old Workspace user.

Duplicates happen when both hosts deliver to the same Gmail. That is still mixed MX. People call it “fine” until one host starts bouncing. Delete the leftover. One path.

MailerZ workflow and product boundary

Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. Leftover Google MX is a hard stop. MailerZ will not pretend dual MX is high availability.

What MailerZ does

• Accept mail only on its MX hosts.
• Show hops it actually received.
• Preserve Header From. Envelope SRS only.
• Hold unknowns on Free. Optional paid FORWARD.
• Refuse open relay with SMTP 550.

What MailerZ does not do

• Import the copy that went to Workspace.
• Remove Google MX from your zone for you.
• Replace Calendar.
• IMAP or send-as on Free.
• Inbox SLAs, review counts, SOC 2, ISO 27001, HIPAA. Controls: Security and Trust Center.

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

Forwarding: email forwarding. MX must be exclusive first.

Cost, alternatives, and trade-offs

Best practice for mixed mx records google: unmix. Search the old Workspace user for the “lost” week. Delete aspmx. Prove from another mailbox. Do not score this with invented reviews. Score it with two resolver answers that match.

Keeping Workspace seats for Drive while MailerZ owns MX is a normal split. Paying for seats and leaving MX mixed is how you pay twice and still lose mail.

Microsoft leftovers are the same bug with different hostnames. Delete those too. The article title says Google because that is the common leftover. The rule is one inbound product.

After unmix, wait one TTL before you declare victory. Then keep a calendar reminder at 30 days: look up MX again. Rollback habits re-add aspmx. The check is cheap.

If legal hold lives in Workspace, export it before you lose the user. MailerZ history is 14 or 90 days of hops, not the Workspace archive. Mixed MX does not copy that archive into Gmail.

Two owners is a coin flip, not a backup

Why mixed Google and custom MX records cause random delivery is simple: senders pick a host from the MX set. Priority is an order, not load balancing. Some senders will still try the second host. A leftover Google host with a better preference skips MailerZ entirely. A leftover with a worse preference still accepts on retry or when the first host looks slow. History in MailerZ looks random because hop one never ran for half the mail. Empty history is leftover, not a dest filter.

Exclusive MailerZ MX means delete Workspace, Google, Microsoft, Cloudflare routing, and registrar forwarding hosts. Save the old set as text. Print 8.8.8.8 and 1.1.1.1. Agreement on exclusive MailerZ is done for hop one. Agreement on a leftover means delete. Disagreement is TTL or the wrong NS. Waiting a week does not delete a leftover. Wizards restore leftovers. Recheck after wizards.

Print NS first. Editing a registrar tab while Cloudflare answers is a silent mixed set. Probe from another mailbox after views agree. Self-send from Gmail to the dest Gmail can hide the leftover for days. Unique subject. Dest including spam. History accepted then forwarded.

MailerZ is not Workspace. It is inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From stays. Not IMAP. Not an open relay. Confirm /pricing. Free proves inbound. Solo is forty dollars per year when From must travel. Caps are not an inbox SLA.

The “backup MX” ticket

An operator left Google MX “in case MailerZ is down.” Customers vanished on a pattern that matched sender resolver and retry. They called it propagation. It was mixed owners. They deleted Google, waited two views, probed from Outlook.com. History filled. The backup they wanted is dest store redundancy, not two inbound owners.

Related: leftover MX article, troubleshooting, docs, tools. RFC 5321. Do not add a second MX for safety. Hold unknowns. Do not catch-all to paper over a split.

Close

Print MX. If two vendors appear, you have the incident. Delete leftovers. Two views. Foreign probe. Then talk about aliases or send-as. Start free on a domain you can break. Sign in if the zone already lives here. That is why mixed Google and custom MX records cause random delivery.

Agencies: templates that restore Google MX will reopen the coin flip tomorrow. Offboard deletes MX you own. Not SOC 2. Not HIPAA. Store windows are recovery.

Who hits which host

Some libraries try MX preference order. Some cache an old host past TTL. Some retry the second host on a 4xx. Mixed Google plus MailerZ therefore looks like “some customers work.” It is not random at the dest. It is two inbound owners. Print both views. Delete Google. Wait. Probe. Do not leave Google as backup. Dest store redundancy is Gmail already having the mailbox, not Google still answering MX.

Null MX plus MailerZ is also mixed in spirit: one host rejects all. Delete null MX. Confirm /pricing after hop one is exclusive. Free is enough to prove inbound. Related: leftover MX, troubleshooting, tools, docs.

Close phrase

If two vendors appear on MX, stop talking about spam and aliases. Exclusive one owner. Two views. Foreign probe. Start free on a breakable domain. Sign in if the zone already lives here. That is why mixed Google and custom MX records cause random delivery.

Wizards restore Google. Recheck after every helper. Agencies: clone templates carefully. Not an inbox SLA.

Random is two owners, not a moody internet

Mixed Google and custom MX feels random because senders cache different answers and some providers prefer the Google hostname they already know. It is not random. It is split. Priority 10 MailerZ plus priority 20 aspmx is leftover MX. Some mail hits the hop. Some hits a Google Group nobody opens. Hop history looks like a coin. Delete leftovers. The coin stops.

Calendar is the usual excuse. Consumer Google Calendar does not need Workspace MX on the brand domain. Drive does not need aspmx if you pay Google for Drive without mail MX. Keep leftover aspmx “for invites” and you will lose invoices. Invites can live on the Google account. Invoices need exclusive MX on the printed domain.

Registrar “backup MX” and “keep Google connected” toggles republish aspmx after a clean Friday. Morning resolver paste is part of unmix. If aspmx is back, the phone app ran. Unmix again. Do not add a third host for luck.

Self-send during mixed MX is the worst proof. Gmail-to-Gmail may short-circuit and look fine while Outlook users hit leftover Google. Probe from Proton or Outlook.com. Unique subject. Empty history on MailerZ during mixed MX is expected for the half that went to Google. That empty is evidence, not a reason to add more Google MX.

TTL overlap after you delete leftovers can still look mixed for one old cache. Two public resolvers that already agree on exclusive MailerZ mean you wait remaining TTL for stragglers. You do not republish aspmx to “help” them. Helping is leftover MX with a story.

HOLD after unmix is a map issue. The hop is exclusive. The name was never created. Create it. Do not remixed MX because HOLD scared you. HOLD means the message arrived. Mixed MX means some messages never will.

How to talk to a founder who wants both

Both is leftover MX. Say that once. Then show two resolver pastes. Circle aspmx. Circle MailerZ. Ask which host should own invoices. If they say both, they have not chosen. Choosing is the product decision. MailerZ can be the hop. Google can be the destination inbox. Google cannot also be a second MX owner “just in case.” Case is the probe.

Workspace seats are not MX. Buying a seat does not require aspmx on the brand if the brand’s mail is forwarded. People conflate seat and MX because Google’s wizard does. Decline the wizard. Keep exclusive MailerZ MX. Destinations stay Gmail.

Facts: leftover MX is a hard stop. Envelope SRS. Header From intact. Not IMAP. No inbox SLA. Start free after leftovers are gone. Sign in when the hop already exists. /troubleshooting names leftover MX on purpose.

Unmix order that does not create a new split

Screenshot the mixed set. Delete Google, Microsoft, registrar, and old forwarder hostnames. Leave one MailerZ set from the dashboard. Query two resolvers. Probe. Then tell humans. If you tell humans during mix, they will restore aspmx from a blog. The blog is why this article exists.

Rollback if you must is exclusive old Google, MailerZ deleted, not both. Then schedule a second unmix. Two exclusive owners in sequence is a runbook. Two owners at once is the bug.

A two-resolver paste you can teach in five minutes

Open two public resolvers. Query MX. Circle every hostname family. One family is exclusive. Two families is mixed. aspmx plus MailerZ is mixed even when the Google line is priority 20. Teach the founder to fear the second family, not the priority number. Priority folklore is how leftovers survive reviews.

Paste again the morning after unmix. Registrar upsells republish overnight. If morning is mixed, delete again. Do not add a third host. Probe from a stranger mailbox after the morning paste is exclusive. Then tell customers. Telling them during mix trains them to restore Google from a screenshot titled backup.

If they need Google Calendar, keep the Google account. Do not keep Google MX. Say that twice. The second time is for the person who will open the registrar app at dinner.

Close mixed MX only when morning is still exclusive

Same-day exclusive paste is not close. Close after the next morning paste is still one family and a stranger probe still lands. That rule catches registrar republish. If you close at 5 p.m., leftovers return at 9 p.m. and Monday looks random again. Random is two owners. Morning is part of unmix.

FAQ

Key takeaways

• Mixed Google and custom MX is a sender coin flip.
• MailerZ history only shows the MailerZ half.
• Google at preference 20 is still leftover MX.
• Calendar does not require Google MX.
• Self-send from Gmail hides the split.
• Delete aspmx and alt hosts. Confirm two resolvers.
• Search old Workspace for the missing copies.
• Catch-all and plan upgrades do not unmix MX.
• Header From stays original on hops that arrive. Envelope SRS only.
• MailerZ is not IMAP, not a suite, and not SOC 2.

Conclusion and next action

If you came here because mixed Google and custom MX records cause random delivery, the fix is exclusive MX, not another alias. Senders will not honor your rollback story. They will pick a host from the public set. Make that set one product.

MailerZ fits after Google MX is gone. It cannot show hops it never received. Next action: look up MX twice, delete leftover Google hosts, probe from a non-Google mailbox, and search the old Workspace user for the week you thought MailerZ was flaky.

Review quarterly, or sooner if a rollback re-adds aspmx. Author: MailerZ editorial, Secuno LLC.