SMTP 550 5.7.1 Error Fix Explained

A 550 5.7.1 error fix starts in one place: the exact text of the bounce message. Not a guess, not a vendor support page, the raw NDR your sending server received. That string tells you whether the remote MTA rejected your message because of a relay policy, a DMARC alignment failure, a blocklist hit, or a missing SMTP AUTH credential. Each cause requires a different fix, and applying the wrong one wastes time without clearing the bounce.

This article gives you the protocol-level explanation Microsoft and Google support pages skip, plus a decision tree that works across every MTA vendor.

What a 550 5.7.1 Response Actually Means

The anatomy of an SMTP enhanced status code

An SMTP response has three layers. The three-digit reply code (550) tells the sending server the outcome: 5xx means permanent failure, do not retry. The enhanced status code (5.7.1) adds a structured sub-classification defined in RFC 3463. The free-text reason string after it is MTA-generated prose that names the specific cause.

Breaking down 5.7.1:

• 5, Permanent failure class
• 7, Security or policy subject (as defined by RFC 3463)
• 1, The specific policy that blocked the message

RFC 3463 defines the 5.7.x class as "security or policy status," meaning a 550 5.7.1 is always a deliberate policy decision by the receiving MTA, never a transient fault, never a network glitch. Retrying will not help. The server made a rule-based decision and will make the same decision again on every retry until the underlying condition changes.

Policy rejection vs. authentication failure vs. relay denial

All three map to 5.7.1, but they are distinct failure modes:

• Relay denial, the sending client is not authorized to submit outbound mail through this server. The server refuses to act as a relay.
• Authentication failure, the message's envelope or header authentication (SPF, DKIM, DMARC) does not satisfy the receiving domain's published policy.
• Recipient policy block, the receiving MTA's local rules reject the message based on the sender's IP reputation, domain reputation, blocklist status, or content policy.

The free-text reason string is what separates them. Read it before touching any configuration.

The Four Root Causes Behind a 550 5.7.1 Error

Relay denied: you are not authorized to send through this server

Diagnostic signature: The bounce text contains "relay access denied," "unable to relay," or "not permitted to relay."

This fires when a mail client or application server tries to send outbound mail through an SMTP server that has not authenticated the connection. The server is configured to relay only for authenticated users or known IP ranges, and this client satisfies neither condition.

A Postfix server configured without permit_sasl_authenticated in smtpd_relay_restrictions will return 550 5.7.1 Relay access denied to any unauthenticated client trying to send outbound, even if the client's credentials are otherwise correct. The fix is a single smtpd_relay_restrictions directive, not a firewall change.

Exchange Online shows this as 550 5.7.1 Client does not have permissions to send as this sender when a connector or service account is misconfigured.

Authentication failure: SPF, DKIM, or DMARC policy rejection

Diagnostic signature: The bounce text contains "DMARC," "p=reject," "SPF," "does not pass," or "policy violation."

Understanding how SPF, DKIM, and DMARC interact at the protocol level is the foundation here. SPF checks whether the sending IP is authorized in the envelope From domain's DNS record. DKIM checks whether the message body and headers are signed by a key the domain publishes. DMARC checks whether either SPF or DKIM passes and the authenticated domain aligns with the From: header domain.

When a message fails DMARC alignment, for example, because the envelope From domain has p=reject but the sending IP is not listed in its SPF record, the receiving server issues a 550 5.7.1 with a reason string that typically includes "DMARC" or "policy." Read that string before touching DNS.

Recipient policy blocks: blocklists, domain reputation, and content rules

Diagnostic signature: The bounce text contains "blacklisted," "blocked," "listed on," or names a specific blocklist (Spamhaus, Barracuda, SORBS).

Here the sending infrastructure, IP address or domain, appears on a reputation blocklist the receiving MTA queries, or the receiver's local content policy matched a rule in the message. The rejection is about who is sending, not how they authenticated.

Decision Tree: Diagnosing Your 550 5.7.1 Error Fix Path

Start from the full bounce message text. Work top to bottom; stop at the first match.

Step 1, Locate the SMTP response string. Find the line beginning with 550 5.7.1 in your bounce NDR or mail log. Copy the entire line including the free-text reason.

Step 2, Match the reason string:

Step 3, If the reason string is ambiguous, pull the Diagnostic-Code header from the NDR (covered below) and repeat Step 2 against its value. If you still cannot classify, treat it as Fix B first, DMARC and authentication issues are now the most common trigger.

Fix Procedures by Root Cause

Fixing SMTP relay denied (550 5.7.1 unable to relay)

The cause is always one of: missing SMTP AUTH, wrong credentials, or the server's relay policy excluding this client.

1. Verify SMTP AUTH is enabled on the client. Open your mail client, application config, or MAIL FROM script. Confirm AUTH LOGIN or AUTH PLAIN is configured with valid credentials. Test with telnet or openssl s_client to confirm the server advertises AUTH in its EHLO response.

2. For Postfix: Check smtpd_relay_restrictions in main.cf. It must include permit_sasl_authenticated before any reject or reject_unauth_destination directive:

   smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
   

   Reload Postfix after editing: postfix reload.

3. For Exchange Online / Microsoft 365: If a connector or application is hitting 550 5.7.1, verify the connector's authentication method (Basic Auth is deprecated, use OAuth or certificate auth), and confirm the send-as permission is granted on the mailbox being used as the MAIL FROM address.

4. For any MTA: If the sending IP is meant to be a trusted relay, add it to the server's permitted relay IP list rather than relying on SMTP AUTH. Do not open an unauthenticated open relay.

Fixing DMARC and authentication-based rejections (5.7.1 DMARC rejection)

A 5.7.1 DMARC rejection means the receiving MTA evaluated your message against the sender domain's DMARC policy and the message failed. Fix the alignment, not the DMARC policy itself.

1. Check SPF alignment. Look up the TXT record for your envelope From domain:

   dig TXT yourdomain.com
   

   Confirm the sending IP appears in the include: chain or ip4:/ip6: mechanism. Use ~all (softfail) during testing, then tighten to -all once aligned. If you send through a third party (SendGrid, Mailchimp, Postmark), add their SPF include: statement.

2. Check DKIM. Verify your selector is published:

   dig TXT selector._domainkey.yourdomain.com
   

   If the record is missing, generate a key pair and publish the public key. If the record exists but DKIM is failing, check that your MTA is signing with the correct private key and that the d= tag in the DKIM signature matches the From: header domain.

3. Check DMARC alignment. The SPF-authenticated domain or the DKIM d= domain must align (exact match for strict, organizational match for relaxed) with the From: header domain. If you are sending from subdomain.yourdomain.com and your DMARC policy is on yourdomain.com, relaxed alignment covers you, but only if SPF or DKIM passes for yourdomain.com.

4. For immediate relief while fixing alignment: If the domain policy is p=reject and you cannot fix alignment right now, and you control the sending domain, temporarily change p=reject to p=none to stop hard bounces. This is a stopgap. Complete alignment before re-enabling enforcement.

5. DMARC reporting: Ensure rua= is set in your DMARC record. Aggregate reports show exactly which IP and selector combinations are failing, removing the guesswork.

Fixing blocklist and recipient-policy rejections

1. Identify the blocklist. The bounce reason string typically names it, "listed on Spamhaus ZEN," "blocked by Barracuda," etc. If it does not, look up the sending IP on MXToolbox or the Spamhaus lookup tool.

2. Request delisting. Each blocklist has its own delisting process. Spamhaus requires confirming the source of abuse is resolved before submitting. Barracuda's delisting form is available at their reputation portal. Do not request delisting before resolving the underlying cause, repeated listing makes future removal harder.

3. For domain-reputation rejections without a named blocklist: Check Google Postmaster Tools and Microsoft's SNDS for domain and IP reputation signals. High spam complaint rates drive these rejections even when no formal blocklist entry exists.

4. Content policy rejections typically require reviewing the message body for spam trigger patterns or removing attachments that trigger policy rules. The bounce text usually states which rule matched.

How to Read the Bounce Message as Raw Evidence

The subject line of an NDR tells you almost nothing. The raw bounce body does.

Every delivery failure generates a DSN (Delivery Status Notification), a structured report that your MTA or mail client may partially hide. Get the full NDR by viewing message source or checking your MTA logs (/var/log/mail.log on Linux, the Exchange message trace portal, or the SendGrid activity feed).

Key fields to locate:

• Diagnostic-Code: smtp; 550 5.7.1 [reason string], the authoritative rejection text as received from the remote MTA. This is your primary diagnostic input.
• Action: failed, confirms this is a permanent rejection, not a temporary deferral.
• Status: 5.7.1, the enhanced status code pulled from the SMTP session.
• Final-Recipient: rfc822; recipient@domain.com, confirms which recipient address triggered the rejection.
• X-Failed-Recipients:, a non-standard but common header in Microsoft NDRs that names the failing address.

For reading email headers to diagnose delivery failures, the Diagnostic-Code header is your ground truth. Match its text against the decision tree above rather than guessing from the NDR subject.

For deeper forensics, full Received: chain analysis, tracing which hop issued the rejection, and interpreting compound header fields, full delivery path and header forensics covers the methodology in detail.

Preventing 550 5.7.1 Rejections Before They Happen

Authentication and relay hygiene are a pre-send checklist, not a one-time setup.

Authentication baseline, verify all three before any send:

• SPF: One TXT record per domain, covering every IP and service that sends on that domain's behalf. End with -all. Test with dig TXT and an SPF validator after every infrastructure change.
• DKIM: At minimum one active selector per sending domain, with a 2048-bit RSA or Ed25519 key. Rotate selectors when changing mail providers. Verify the d= tag aligns with the From: header domain.
• DMARC: Publish a _dmarc.TXT record with at minimum p=none and rua= pointing to a reporting inbox. Advance to p=quarantine and then p=reject only after reviewing aggregate reports and confirming near-zero alignment failures.

Relay hygiene checklist:

• All applications sending mail must use SMTP AUTH with credentials scoped to the sending identity.
• Never route application mail through a server that doesn't require authentication from that application.
• Separate transactional mail IPs from marketing mail IPs. A spam complaint on one should not poison the other.
• Monitor sending IP reputation monthly, don't wait for a bounce to discover a blocklist entry.

DMARC policy enforcement has grown sharply since major mailbox providers began requiring authentication alignment for bulk senders. Those requirements, introduced in 2024, were extended through 2025 and remain in effect in 2026. A large share of 550 5.7.1 bounces hitting business mail servers now carry a DMARC-related reason string, reflecting how widely p=reject and p=quarantine are deployed across receiving infrastructure.

The Email Decoded SMTP Error Codes Reference chapter documents every 5.7.x subcode with its canonical cause, the MTA behavior difference between reject and discard, and annotated NDR dissection examples, the reference to bookmark when a bounce reason string doesn't match a pattern you've seen before.