Say a nine-person insurance brokerage moves its mailboxes to Google Workspace on a Friday. By Monday the mail mostly works. Staff send and receive normally. But the quote form on the website has stopped arriving, and when the office manager emails info@ from her own account on the same domain, a bounce comes back within seconds:
550 5.4.6 mail for example.com loops back to myselfNothing in that line mentions DNS, SPF or Google, so the usual reaction is to open the DNS editor and start changing records. We have been called in after three days of that. The records are almost always fine. The problem is a single setting on the old hosting account, which still believes it owns the domain's email.
What the bounce is actually telling you
A loop bounce is a routing dead end, not a reputation problem, not a spam filter and not an authentication failure. Some server accepted your message, looked up where mail for the recipient's domain should go, and the answer came back as itself. It then checked its own list of domains it delivers locally, found either no entry for the domain or no mailbox for that address, and had nowhere left to pass the message. The enhanced status code attached to it, 5.4.6, is the registered code for a routing loop in RFC 3463.
Two details in the bounce decide everything that follows. The first is which host generated it. The reporting server named in the bounce is the one with the wrong idea, and in a small business setup that is almost always the web host rather than Google. The second is the domain in the "mail for" part. If it is your main domain, you are looking at mail routing. If it is a hostname such as mail.example.com or the server's own fully qualified name, you are looking at mail the server generated about itself, from cron or a monitoring script, and the fix belongs in that server's configuration rather than in your business mail.
The three setups that produce it
In practice the cause is one of three things, and they are easy to tell apart once you know they are different problems.
- The hosting panel still routes the domain locally. You moved the MX records, but the server that hosts the website was never told. It keeps accepting mail for the domain, looks for a local mailbox, and finds none because the mailboxes now live at your provider. This is the common one, and it is the one that breaks contact forms and same-domain mail while everything else looks healthy.
- DNS still points somewhere at your own server. An old MX record survived the cutover, or a lower-numbered MX points at the hosting IP, so some senders are told to deliver to a machine that has no mailboxes.
- The mail server lists the domain as its own final destination. On a VPS you administer, the domain is in the list of local destinations even though it should be relayed or ignored entirely.
The reason this is so often misdiagnosed is that external mail keeps working. Gmail, Outlook and everyone else read public DNS, see your provider, and deliver there. Only the machine with the stale local route gets it wrong, and the traffic that passes through that machine is exactly the traffic a business notices last: website forms, invoicing scripts, and mail between two addresses on the same domain.
What we check first, in order
This is the order we work through on a client domain, because each step rules out a whole class of cause.
First, read public DNS rather than the panel's copy of it. Google's Admin Help lists a single MX record for Workspace: host @ or blank, priority 1, value smtp.google.com, with some registrars wanting a trailing dot or the priority and value on one line.
dig +short MX example.com
1 smtp.google.com.What matters is not which Google record set you have. Older domains carry a longer list and still receive mail. What matters is that nothing in the answer resolves to your own web server. If something does, fix DNS first and stop there, because no amount of server configuration will beat a wrong MX record. Our walkthrough on how to change MX records to Google Workspace without downtime covers that cutover properly.
Second, identify the reporting host in the bounce and confirm it is the hosting server. Third, open that server's mail routing for the domain. Fourth, check for leftovers on the old account: a local mailbox, a forwarder, or a catch-all for the same address can keep the server convinced it should deliver locally. Fifth, send one test message from the website form and one from an account on the domain to another account on the domain, because those two paths fail for different reasons and a single test can mislead you.
The fix on cPanel hosting
cPanel has one setting for this, under Email, then Email Routing. You pick the domain and tell the server what it is. The four options behave differently, and only one of them is right once your mailboxes have moved.
| Setting | What the server does with mail for the domain | When it is the right choice |
|---|---|---|
| Remote Mail Exchanger | Stops accepting mail for the domain and hands it to the lowest-numbered MX in DNS | Mailboxes live at Google Workspace, Microsoft 365 or any other provider |
| Local Mail Exchanger | Always accepts the mail and delivers it to a mailbox on this server | The mailboxes really do live on this hosting account |
| Backup Mail Exchanger | Holds the mail until a lower-numbered mail exchanger becomes available | A deliberate backup MX, which a small business almost never needs |
| Automatically Detect Configuration | Reads the local zone file to guess Local or Remote, with no live DNS lookup, and does not revisit the guess later | Rarely, and never when DNS is hosted somewhere other than this server |
That last row is the trap. cPanel's own documentation is explicit that automatic detection reads local zone file entries rather than performing a real DNS lookup, and that the setting does not update itself after it has been configured. So a domain whose DNS lives at Cloudflare or at the registrar can be pointed at Google in public DNS while the server's local zone still shows the old record, and the server happily keeps delivering locally. Set the option explicitly to Remote Mail Exchanger and the guess stops mattering.
Two follow-ups on the same account. Remove or rename any local mailbox and forwarder for addresses that now live at your provider, because leaving them in place means two copies of the truth. And if the hosting panel generated its own DKIM record for the domain, it signs only mail the panel sends, so it should not be the record your provider's authentication depends on.
Other control panels have the same switch under a different name. The principle does not change: a server that no longer holds the mailboxes must not be configured to deliver the domain's mail locally.
The fix on a server you administer
On a plain Postfix host, the equivalent lives in the configuration parameters that define which domains the machine treats as its own. mydestination is the list of domains for which the machine is the final destination. Read the current values before changing anything:
postconf mydestination relay_domains virtual_mailbox_domains virtual_alias_domainsIf the business domain appears in any of them while the mailboxes live elsewhere, that is the loop. Remove it, reload, and the machine will resolve the MX record and deliver outward like any other sender. A domain you deliberately accept mail for on behalf of another server belongs in relay_domains, not in mydestination. The postconf(5) manual page is the reference for the exact meaning of each parameter, and it is worth reading rather than guessing, because these lists overlap and a domain sitting in the wrong one produces the same loop.
The part everyone forgets: the website's own mail
Fixing the route gets the bounce to stop. It does not make the website's mail trustworthy. A contact form that hands a message to the local mail server is now sending unauthenticated mail from a shared hosting IP address that is nowhere in your SPF record, to a mailbox at Google. Best case it lands in spam. Common case it disappears quietly.
The durable fix is to have the site authenticate and send through your provider instead of through the web server. Google documents two routes for mail from an app or a device. The SMTP relay service accepts mail at smtp-relay.gmail.com on ports 25, 465 or 587, with TLS, and authenticates either by SMTP credentials or by IP address, where authentication by IP is the only option without TLS. It is configured in the Admin console under Apps, Google Workspace, Gmail, Routing, then SMTP relay service, and only the top-level organization can change it. The alternative, smtp.gmail.com, signs in as a single account and carries a lower daily ceiling, which is usually fine for one contact form and not fine for an invoicing system. Those details are from Google's own help pages, checked 30 October 2026. Our guide to Google Workspace SMTP relay and Send mail as walks through both.
What to watch over the next two weeks
After the route changes, mail that was being swallowed locally starts arriving, and that can look like a new problem. Expect a short burst of form submissions and script notifications that had been queueing or vanishing. Check your provider's inbound logs for the domain to confirm messages are now entering from the outside, send one test from every automated sender the business has, and watch for anything still using the old mailbox names you removed. If the website now sends through authenticated SMTP, confirm the sending address is one your DNS authorises, not a made-up address on the domain, or you will have traded a loop bounce for an authentication failure.
How Guanacos Tech helps
Most of the work here is diagnosis. The change itself is one setting, but choosing the right one means reading the bounce, reading public DNS, and knowing which of three machines is lying to you. We do this as part of email deliverability consulting for small business, usually alongside a Workspace cutover or right after one that left loose ends. Book a 30-minute call and bring one bounce message with full headers; that is normally enough for us to tell you which server to change and what else the cutover left behind.
Sources
- Email Routing (cPanel documentation)
- Email Routing Configuration (WHM documentation)
- Set up MX records for Google Workspace (Google Workspace Admin Help)
- Send email from an app, device or printer, including the SMTP relay service (Google Workspace Admin Help)
- postconf(5) configuration parameters (Postfix documentation)
- RFC 3463: Enhanced Mail System Status Codes