550 5.7.1 Email Error: What It Means and How to Fix It

If your email bounced back with 550 5.7.1, the receiving server did not just fail to deliver it — it refused it on purpose. The 550 5.7.1 email error is a permanent rejection, so resending the same message unchanged will not help. It is not a full mailbox, a typo, or a passing glitch; those have their own codes.

The good news is that the code is precise about why. Once you read the full bounce string — the sentence the server adds after the number — you can usually fix it in one focused change. This guide splits the code into its parts, maps the five real causes, and gives a step-by-step fix for each, using the exact wording Gmail and Microsoft publish.

What does 550 5.7.1 actually mean?#

A 550 5.7.1 bounce carries two codes that answer two questions. The 550 is the basic SMTP reply: the server rejected the command and did not accept the message. The 5.7.1 is the enhanced status code from RFC 3463, read in three parts — class, subject, detail.

The class 5 is a permanent failure, which RFC 3463 defines as one that "is not likely to be resolved by resending the message in the current form." The subject 7 is the security-or-policy class, used for "failures involving policies such as per-recipient or per-host filtering." The detail 1 is named "delivery not authorized, message refused" — the sender is not authorized to send to that destination.

In short, 550 5.7.1 means the server made a deliberate decision to refuse you — and the sentence it appends after the code names which policy.

The five causes of a 550 5.7.1 bounce#

Almost every 550 5.7.1 rejection falls into one of five buckets. The wording below is quoted from Google's and Microsoft's own error references, current as of August 2026 — read yours against these rather than guessing.

Fix 1: Authenticate your sending domain#

Authentication is the highest-leverage fix, because authenticated mail is trusted more and clears many reputation and policy blocks as a side effect. Note the platform nuance: modern Gmail returns a DMARC failure as 550 5.7.26, and Microsoft returns an SPF violation as 5.7.23. Seeing one of those confirms an authentication problem outright.

1. 1

   Publish an SPF record

   Add one TXT record at your sending domain listing every server allowed to send for it. Keep it under the 10 DNS-lookup limit, or SPF itself fails.

2. 2

   Turn on DKIM signing

   Enable DKIM in your provider and publish the public key it gives you. Google requires a key of at least 1024 bits. DKIM proves the message was not altered and came from your domain.

3. 3

   Publish a DMARC record

   Add a DMARC TXT record at _dmarc.yourdomain. Start at p=none to monitor, then move to quarantine or reject once legitimate mail passes. DMARC is defined by RFC 9989 (2026), which replaced RFC 7489.

4. 4

   Check alignment, not just presence

   SPF and DKIM can pass while DMARC fails, because DMARC needs the authenticated domain to align with the visible From domain. Confirm alignment for the exact address you send from.

5. 5

   Send a test and re-read the bounce

   Once DNS has propagated, send to Gmail and Outlook and check the headers show spf=pass, dkim=pass, and dmarc=pass. If the 5.7.1 persists with reputation wording, go to Fix 2.

Fix 2: Clear a reputation or 'unsolicited mail' block#

If the bounce mentions unsolicited mail, a low reputation, or that the message was blocked, the receiver is judging your sending pattern, not your DNS. Gmail's wording here includes 'this message is likely unsolicited mail' and 'the very low reputation of the sending IP address'. These clear slowly — reputation is earned back over days of clean sending.

1. 1

   Read the exact reputation wording

   Separate an IP block ('sending IP address') from a domain block ('sending domain') from a content flag ('likely unsolicited mail'). Each points at a different lever.

2. 2

   Slow down and warm up

   Sudden volume from a cold IP or domain triggers this fastest. Cut your rate, then ramp gradually so the receiver sees a consistent pattern instead of a spike.

3. 3

   Remove the spam signals

   Clean dead addresses, drop non-engagers, and make unsubscribing easy — one-click unsubscribe (RFC 8058) is required by Gmail and Yahoo for bulk marketing mail.

4. 4

   Watch the numbers that matter

   Google asks senders to keep the spam-complaint rate below 0.3%, and ideally under 0.1%, measured in Postmaster Tools. Microsoft's SNDS gives the same view for Outlook.com.

5. 5

   Request a review once you are clean

   After a stretch of low-complaint, authenticated sending, use the provider's sender-support form. A review while the pattern is still bad will not help — the clean history is the fix.

Fix 3: Fix your send path or permissions#

This cluster is about the route your mail takes and whether you were allowed to take it. Microsoft's NDR guide documents three 5.7.1 variants: 'Delivery not authorized' (not permitted to send to that recipient), 'Unable to relay' (sending through a server that is not the final destination), and 'Client was not authenticated' (no authentication before submission).

1. 1

   Authenticate before you send

   For 'Client was not authenticated', configure SMTP AUTH with valid credentials. A server that requires authentication refuses anonymous submission with a 5.7.1 every time.

2. 2

   Send through a server allowed to relay

   For 'Unable to relay', you are asking a server to forward mail for a domain it does not handle. Use your provider's authenticated relay, or confirm the recipient's MX record points where you expect. Our 550 5.7.1 'Unable to relay' guide covers this in depth.

3. 3

   Check the recipient's policy

   For 'Delivery not authorized', the recipient side is refusing you — often a distribution group limited to members, or a transport rule that matched. Their admin has to allowlist you; you cannot fix it from the sending end.

4. 4

   For apps and devices, use the right endpoint

   Printers and scripts that relay through Microsoft 365 must use the supported endpoint and method. A misconfigured device commonly triggers the related 5.7.57, 'Client was not authenticated to send anonymous mail'.

How to tell which cause you have#

The number 550 5.7.1 is identical across all five causes, so the diagnosis lives in the text after it and in which provider bounced you. Match the wording to the branch below.

• Text says 'unsolicited', 'reputation', or 'blocked' → content or reputation. Go to Fix 2.
• Text says 'a policy that prohibited' or 'Delivery not authorized' → a policy or permission block. Go to Fix 3, or contact the admin.
• Text says 'Unable to relay' → a routing or relay problem. Go to Fix 3 and the relay guide.
• Text says 'not authenticated' → your send-path authentication. Go to Fix 3.
• Text mentions DMARC or SPF, or you see 5.7.26 or 5.7.23 → an authentication-record problem. Go to Fix 1.

Platform shapes the odds. On Gmail today, a bare 550 5.7.1 is almost always reputation, content, or a recipient policy, because Gmail gave authentication rejections their own codes. On Microsoft and Exchange Online, it leans toward permissions, relay, and send-path authentication. On other servers — Postfix, a third-party gateway — a bare 550 5.7.1 is still the catch-all for a DMARC or SPF rejection. Read the text, not just the number.

Preventing 550 5.7.1 going forward#

Most 550 5.7.1 bounces are preventable with steady habits. Authentication and reputation compound: a domain that has sent cleanly for months is trusted, and trusted mail rarely trips a policy filter.

• Keep SPF, DKIM, and DMARC published and aligned for every From domain, and re-check whenever you add a sending service.
• Send from a consistent, warmed IP and domain instead of switching around, which resets the reputation you built.
• Watch Google Postmaster Tools and Microsoft SNDS so a reputation dip shows up before it becomes a block.
• Keep lists clean, honor unsubscribes fast, and offer one-click unsubscribe on any bulk mail.
• Authenticate every send path, and never relay through a server you are not authorized to use.
• If you send more than 5,000 messages a day to personal Gmail accounts, meet Google's bulk-sender requirements in full — SPF, DKIM, DMARC, and one-click unsubscribe are mandatory at that volume as of August 2026.

A 550 5.7.1 is the receiving server's verdict on who sent the message and how — its authentication, its reputation, its policy. Most of that verdict is decided by DNS records and sending infrastructure a mail client does not own, so be clear-eyed about the limit: no inbox app fixes a broken SPF record or a bulk-sender reputation problem for you, and the steps above are the real work. What an AI email client can do is send your day-to-day mail through your existing authenticated Gmail, Outlook, or IMAP account rather than a separate relay, so it inherits the SPF, DKIM, and DMARC that account already passes instead of adding an unauthenticated hop that trips 5.7.1. We build AI Emaily; it is a client, not a deliverability service, so for DNS and bulk-sending problems the fixes above are what clear the bounce.