Introduction

Postfix often starts returning Relay access denied right after a server migration because the new host no longer sees the domain, client, or submission path the same way the old server did. The website may be up, DNS may already point to the new box, and users may still fail to send mail because Postfix is now treating the message as unauthorized relay traffic. In most cases, the fix is not one setting. You need to confirm whether the server should deliver mail locally, relay it onward, or require authenticated submission, then line up the migrated Postfix policy with that role.

Symptoms

  • Mail clients or applications suddenly get 554 5.7.1 Relay access denied after the migration
  • Messages that worked on the old server now fail from web apps, cron jobs, or SMTP clients
  • Port 25 or 587 connections succeed, but recipients are rejected during the SMTP transaction
  • One domain fails while others still send normally
  • The issue started immediately after moving to a new VPS, VM, hosting provider, or IP range

Common Causes

  • The migrated server no longer treats the domain as local because mydestination, virtual domain maps, or mailbox tables were not carried over correctly
  • mynetworks still trusts the old private subnet or old public IPs instead of the new network
  • SMTP submission on port 587 now requires SASL authentication, but the client or app still sends like it did on the old server
  • smtpd_relay_restrictions or smtpd_recipient_restrictions became stricter after package upgrades or a partial config restore
  • Postfix maps, lookup files, or dependent services were copied but not rebuilt, enabled, or reloaded on the destination server

Step-by-Step Fix

  1. Determine what this Postfix server is supposed to do for the affected mail flow: accept mail for a local domain, relay outbound mail for authenticated users, or relay mail for trusted applications on the same network. You cannot fix Relay access denied until that role is clear, because the correct setting for a mailbox server is different from the correct setting for an application relay.
  2. Read the exact SMTP rejection and check the live mail log on the new server for the same transaction. Confirm which client IP, sender, recipient, and receiving service triggered the denial. This tells you whether Postfix is rejecting local delivery, refusing relay for a remote recipient, or blocking a client that is no longer considered trusted after the migration.
  3. Verify that Postfix still recognizes your hosted domain correctly. If the server should receive mail for the domain, make sure the domain exists in the right place for your setup, such as mydestination, virtual_alias_domains, or virtual_mailbox_domains. A common migration mistake is moving mailbox data but not the domain lookup tables, which makes Postfix treat valid recipients as external relay targets.
  4. Review relay policy on the new host, especially smtpd_relay_restrictions and any older smtpd_recipient_restrictions logic still in use. Make sure the policy allows relay only for authenticated users or explicitly trusted networks, while still permitting mail to local domains. After migrations, admins often restore fragments of old configs and end up with missing permit_mynetworks, missing permit_sasl_authenticated, or an incorrect restriction order that blocks legitimate traffic.
  5. Check mynetworks carefully if applications, scanners, or internal systems send mail through Postfix without SMTP auth. Server migration often changes private ranges, NAT behavior, container bridges, or load balancer addresses. If the app server used to be in a trusted subnet and the new environment assigns a different source IP, Postfix will deny relay until you trust the correct network or move the sender to authenticated submission.
  6. Test the submission path on port 587 separately from server-to-server SMTP on port 25. If users or applications should authenticate, confirm SASL is enabled and working on the submission service, and verify the client is actually using authentication after the migration. Many relay denials come from apps that were copied to the new host with the old SMTP hostname, wrong port, or missing auth settings, so they connect successfully but attempt to send as anonymous relays.
  7. Rebuild and verify any Postfix lookup files that came from the old server, including transport maps, virtual alias maps, access tables, canonical maps, and sender-dependent relay settings. A migration can copy the source files without regenerating the compiled database files that Postfix actually reads. If the live map is stale or missing, Postfix may route or classify mail incorrectly and reject mail that should pass.
  8. Confirm the rest of the migrated mail stack matches the new environment. Check hostname and DNS identity, make sure the server resolves its own mail domain correctly, and verify there is no leftover config pointing to the old relay host, old interface bindings, or old TLS certificate paths. Partial restores frequently leave Postfix running with a mix of old and new assumptions, which shows up as relay denials even though the daemon itself starts cleanly.
  9. After each correction, run controlled tests from every affected path: a local shell mail test, an authenticated SMTP client on port 587, and the real application or device that was failing. Watch the log while testing and confirm the message is now accepted for the right reason, not just queued somewhere else. Once it works, document the new trusted networks, submission settings, local domains, and map rebuild steps so the next migration does not recreate the same relay failure.