# 550 mail loops back to myself: your old host still thinks it delivers your email

Published: 2026-10-30  
Author: Guanacos Tech (https://guanacostech.com)  
Canonical: https://guanacostech.com/blog/550-mail-loops-back-to-myself-fix

> Read the bounce, tell a stale local mail route from a bad MX record, switch the domain to remote delivery, and get your website forms arriving again.

**Short answer:** A 550 "loops back to myself" bounce means the sending server looked up your domain's MX, found its own address, and had no local mailbox for the recipient. Fix the route, not DNS: set that domain to remote mail delivery in the hosting panel, or remove it from the mail server's own list of local destinations.

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 myself
```

Nothing 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.

1. **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.
2. **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.
3. **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](https://guanacostech.com/blog/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.

Free tool

Check your domain's SPF, DKIM and DMARC

Paste a domain and get the live authentication results in about 30 seconds. No signup.

[Run the free check](https://guanacostech.com/email-troubleshooter)

## 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_domains
```

If 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](https://guanacostech.com/blog/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](https://guanacostech.com/email-deliverability), 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)](https://docs.cpanel.net/cpanel/email/email-routing/)
- [Email Routing Configuration (WHM documentation)](https://docs.cpanel.net/whm/dns-functions/email-routing-configuration/)
- [Set up MX records for Google Workspace (Google Workspace Admin Help)](https://support.google.com/a/answer/61158)
- [Send email from an app, device or printer, including the SMTP relay service (Google Workspace Admin Help)](https://support.google.com/a/answer/2956491)
- [postconf(5) configuration parameters (Postfix documentation)](https://www.postfix.org/postconf.5.html)
- [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html)

## Frequently asked questions

### Is "mail loops back to myself" a DNS problem or a server problem?

Usually a server problem. Public DNS normally already points at the right provider, which is why external mail keeps arriving. Check the MX answer first anyway, because a leftover record pointing at your own hosting IP causes the same bounce and no server setting will fix that.

### Why does only mail between addresses on my own domain bounce?

Because those messages never leave the server that has the stale route. A message from an outside sender follows public DNS to your provider. A message sent from the hosting server itself, or from a website form on it, is handed to the local mail server, which believes it owns the domain.

### Will changing the routing setting delete any mail?

Changing the route does not delete mailboxes or stored mail. It only changes where new messages go. Do remove the obsolete local mailboxes and forwarders afterwards, but copy anything still sitting in them to the new provider first, because they stop receiving the moment the route changes.

---

Guanacos Tech is an independent consultancy with Google-certified engineers: email deliverability, Google Workspace and Google Cloud, in English and Spanish. Book a free 30-minute call: https://calendar.app.google/pq2seCCcch9U2GFV8