SMTP 550 5.7.1 — message rejected due to local policy

The receiving MTA rejected the message at the end-of-DATA stage because it violated a local policy covering sender reputation, authentication, or content.

Impact — High impact

A 550 5.7.1 is a hard, permanent rejection — the message will not be retried and the recipient never sees it. Repeated 5.7.1 responses from the same destination usually indicate the receiver has flagged the sending IP, domain, or From: identity as untrusted, which quickly spreads to other mailboxes at the same provider. Transactional traffic (password resets, receipts, 2FA) becomes undeliverable within minutes, and continued attempts accelerate reputation decay.

What causes it

SPF, DKIM, or DMARC authentication failed and the receiver's policy rejects unauthenticated mail from your domain (common at Google, Microsoft, and Yahoo after the 2024 bulk-sender rules).
Sending IP or domain is listed on an internal reputation blocklist at the recipient (Microsoft S3140/S3150, Google's internal reputation score, Proofpoint policy, etc.) even if public RBLs are clean.
Message content tripped the receiver's anti-abuse or anti-phishing filter — spoofed display name, lookalike domain, suspicious attachment, or a URL on a URIBL.
From: header domain does not align with the authenticated MAIL FROM or DKIM d= domain, so the receiver treats the message as a spoof under its DMARC enforcement.
Sender exceeded the recipient's per-connection, per-hour, or per-day rate limit, or hit a greylist/tarpit policy that converts to 5.7.1 after retries.

How to fix it

Read the full enhanced status text, not just the code

The 5.7.1 code is generic — the human-readable string after it tells you which policy triggered. Pull the exact bounce text from your MTA logs or MX reply. Google returns URLs like https://support.google.com/mail/?p=..., Microsoft returns an S3140/S3150/550 5.7.1 Unfortunately... identifier, and Proofpoint names its rule. Grep your logs for the recipient domain and the full 550 line before changing anything.

journalctl -u postfix --since "1 hour ago" | grep -E "status=bounced.*5\.7\.1"

Verify SPF, DKIM, and DMARC pass for the exact sending path

Send a test message to a mailbox you control at the complaining provider and inspect the Authentication-Results header. All three must read pass, and the DKIM d= and MAIL FROM domain must align with the From: header for DMARC. If SPF fails because of a forwarder or a relay, switch that path to a DKIM-signed send instead of adding more SPF includes.

dig +short TXT example.com | grep spf1
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Check your IP and domain reputation at the specific receiver

Public RBLs are not enough — each major provider runs its own reputation system. Enroll the sending domain in Google Postmaster Tools, Microsoft SNDS and JMRP, and Yahoo Sender Hub, then review the IP and domain reputation panels. If reputation is Low/Bad, pause bulk sends, split transactional from marketing traffic onto separate subdomains, and warm the IP back up with low-volume engaged recipients.

Submit a delisting request only after the underlying cause is fixed

Microsoft (sender.office.com), Google (postmaster support form), and Proofpoint (ipcheck.proofpoint.com) all accept delisting requests. Submit only after you have corrected authentication, pruned bad addresses, and confirmed clean sends to a seed list — a premature request burns the one chance you get and often results in a longer block.

Fixed it? Run a fresh test to confirm.

Test my inbox →