## TL;DR
Fix the trust between the new gateway and the receiving system first: list the new gateway egress IPs, add exactly those IPs to the inbound connector or relay allow list on the receiver, remove the requirement for the old gateway path, and test delivery from outside. After a migration the mail itself is fine; the receiver simply does not yet trust the host now handing it over, so it refuses the relay attempt.

```text
"554 5.7.1" relay access denied on inbound connector after gateway migration
```

## Use this when
- Inbound mail from external senders bounces or defers with 554 5.7.1 relay access denied after a gateway migration.
- Internal mail and mail that bypasses the gateway still deliver.
- The migration changed the egress IPs or hostnames that present mail to your server or tenant.

## Not for this skill when
- Outbound mail to one provider is refused. That is that provider policy, not your inbound connector.
- All mail including internal fails. Look at the receiving service itself first.

## Steps
1. Capture a bounce or a sending server log line and note the exact IP that was refused and the host that refused it. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the refused IP and the refusing host are both identified
2. List the new gateway real egress range from the vendor documentation, not from a single observed connection. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the full egress range is documented for the change
3. Update the inbound connector, receive connector, or relay allow list to trust the new range and keep authentication requirements unchanged. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the saved connector shows the new range and no broad open relay setting
4. Remove or disable the old gateway trust entries only after the new path is proven, to keep a rollback option during the test. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: old entries are marked for removal but a rollback path still exists
5. Send external tests from two unrelated outside services and check delivery and headers. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: both tests deliver and the headers show the new gateway hop accepted

## Why it happens
Relay access denied is the receiver saying the presenting host has no right to hand over mail for those recipients. Migrations break it because trust is configured by IP or certificate in the connector, and the new gateway presents from different addresses than the old one. Nothing about the senders or the content changed, which is why the fault starts at cutover minute and affects otherwise healthy mail.

## Variants and edge cases
### 554 5.7.1 relay access denied inbound connector gateway migration
The migration timing phrasing admins search at cutover.
### relay access denied new gateway ip not trusted receive connector
The connector trust variant naming the fix location.
### inbound mail rejected after mx change gateway egress ip allow list
The MX change variant for the same cutover fault.

Compatibility: Exchange Server receive connectors, Exchange Online inbound connectors, common cloud email gateways.

Edge cases to check:
- Keep the connector scoped to the gateway IPs plus enhanced filtering settings where offered; an open relay fix is a security incident, not a repair.
- Certificate based trust needs the new gateway certificate name added before the IP entries will even be reached.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rss6rlDpw2n9_J1qPHtYmw