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

A 550 5.7.1 email error means the receiving server refused your message on purpose, for a policy or security reason. It is a permanent rejection, so resending the same message unchanged will not help. The cause is in the sentence after the code, not in the code.

What does 550 5.7.1 (status code 5.7.1) mean?#

It carries two codes. The 550 is the basic SMTP reply: the server rejected the request and did not accept the message. The 5.7.1 is the enhanced status code from RFC 3463, read as class, subject and detail.

Class 5 is a permanent failure, one "not likely to be resolved by resending the message in the current form." Subject 7 covers security or policy, including "per-recipient or per-host filtering." Detail 1 is named "Delivery not authorized, message refused", and RFC 3463 explains it as: "The sender is not authorized to send to the destination." That is why you may see the full phrase 5.7.1 permanent error (delivery not authorized, message refused).

Formats vary but the status is the same: smtp;550 5.7.1, 550-5.7.1, 550 #5.7.1 and Diagnostic-Code: smtp; 550 5.7.1. Admins may also meet it as a setting: an Exchange Online mail flow rule can reject a message with the enhanced status code 5.7.1, and the default text is that same "Delivery not authorized, message refused".

Match your exact bounce text#

Find the closest wording. Gmail and Exchange Online lines come from Google's and Microsoft's own error references as of November 2026, and the others are noted. Quoted wording can vary, so match on the key phrase.

The five causes of a 550 5.7.1 bounce#

Almost every rejection above falls into one of five groups. Which one is likeliest depends on who bounced you.

On Gmail, a bare 550 5.7.1 usually points to reputation, content or a domain policy, because Gmail gives authentication failures their own codes such as 5.7.26. On Exchange Online it leans toward permissions, relay and sign-in, and Microsoft says that typically you cannot fix it yourself: the recipient or their admin has to. On other servers and gateways, 5.7.1 can still be a catch-all that covers SPF or DMARC rejections, so read the text.

Fix 1: Authenticate your sending domain#

Authentication helps broadly, because authenticated mail is trusted more. If you see 550 5.7.26 on Gmail or 5.7.23 from Microsoft, an SPF or DMARC problem is confirmed.

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 at least a 1024-bit key and recommends 2048 bits where your provider supports it.

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 now defined by RFC 9989 (May 2026), which replaced RFC 7489.

4. 4

   Check alignment, not just presence

   SPF and DKIM can pass while DMARC fails, because DMARC alignment needs the authenticated domain to match the visible From domain.

5. 5

   Send a test and re-read the headers

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

"From header domain does not align with authenticated domain"#

The exact line 550 5.7.1 Rejected by policy: From header domain does not align with authenticated domain comes from OVHcloud, which has enforced it since 20 July 2026 on MX Plan, Zimbra and Web Hosting email. It means the domain in your From address differs from the domain of the mailbox you signed in with. Sending within one domain is not affected.

DNS changes will not clear this one, because the check happens when you submit the message. Sign in with a mailbox on the domain you are sending from, or make your app's From address match its SMTP login. If another provider shows similar wording, check its documentation, because the rule may be different.

Fix 2: Clear a reputation, content or format block#

If the bounce mentions unsolicited email, low reputation, or that the message was blocked, the receiver is judging your sending pattern or the message itself. Reputation clears slowly, because it is earned back over days of clean sending.

1. 1

   Separate the three signals

   An IP block (sending IP address), a domain block (sending domain) and a content flag (likely unsolicited email) each point at a different lever. If Gmail says the message is not RFC 5322 compliant, fix the From, Message-ID or duplicate headers in your sending app.

2. 2

   Slow down and warm up

   Sudden volume from a new IP or domain is a common trigger. Cut your rate, then ramp up gradually.

3. 3

   Remove the spam signals

   Clean dead addresses and drop people who never engage. Gmail requires bulk senders to offer one-click unsubscribe (RFC 8058) on marketing and subscribed mail.

4. 4

   Watch the numbers that matter

   Google requires a spam rate below 0.3% and advises staying under 0.1%. Use the Spam Rate and Compliance status dashboards in Postmaster Tools, because Google says the Domain and IP Reputation dashboards will be retired. For Outlook.com, Microsoft's SNDS shows IP-level data.

5. 5

   Request a review once you are clean

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

Fix 3: Fix your send path#

This group is about the route your mail takes and whether you signed in. Microsoft's NDR reference documents 'Unable to relay' and 'Client was not authenticated' as separate 5.7.1 cases. Our 550 5.7.1 Unable to relay guide covers relay in depth.

1. 1

   Authenticate before you send

   For 'Client was not authenticated', configure the sending system to sign in to the receiving server with valid credentials.

2. 2

   Send through a server allowed to relay

   For 'Unable to relay', the server does not accept mail for that domain. Use your provider's authenticated relay. If it is your domain, check that its MX record points to the system that accepts mail for it.

3. 3

   Use your provider's relay for direct-to-Gmail sends

   If Gmail says your IP is not authorized to send directly, follow its advice and send through your service provider's SMTP relay.

4. 4

   For apps and devices, use the right endpoint

   Printers and scripts that send through Microsoft 365 must be set up for the supported method. A misconfigured device commonly triggers the related 5.7.57, Client was not authenticated to send anonymous mail during MAIL FROM.

Fix 4: Get a recipient policy changed#

Here the block sits on the recipient's side, so changing your settings will not help. Contact the person by phone or another channel and ask them to pass the bounce to their email admin.

• Restricted group: the group may accept mail only from members or approved senders. Ask its owner to add you. The bounce usually names the group.
• Large group: Microsoft says groups with more than 5,000 members require moderator approval, so ask the owner or moderator.
• Mail flow rule: an Exchange admin may need to change a rule that matched your message.
• Gmail or Workspace policy: the wording covers domains you send to or from, so check with your own admin too.

"Your access to submit messages to this e-mail system has been rejected"#

This line, often shown as 550 #5.7.1, states no reason. We could not find a vendor document that ties it to a single product or cause, and the reports we found describe a refusal by the receiving server's own policy.

Treat it as Fix 4. Ask the recipient's admin to check their logs, because only they can see the rule. Meanwhile, rule out your side by checking that your IP is not on a blocklist and that SPF and DKIM pass.

Command rejected: Sophos and other email gateways#

A 550 5.7.1 Command rejected line often comes from a security gateway in front of the mailbox, not from the mailbox provider. Look for a vendor code in the text. According to Sophos Community articles, 550 5.7.1 XGEMAIL_0011 Command rejected on inbound mail means the recipient address is not configured in the customer's Sophos account, and XGEMAIL_0010 means the recipient's domain is not.

On outbound mail through Sophos in gateway mode, the same articles list these checks. Other gateways use their own reason codes, so start with that vendor's message log.

• Inbound: the recipient's admin adds the address as a mailbox or alias in Sophos Central.
• Outbound: the envelope-from and the From header must match.
• Outbound: the sender's domain must be listed in the account's domain settings, and the sender needs a mailbox there.
• Forwarded mail: Sophos identifies mail by the From address, so auto-forwarded messages from outside domains can be rejected.

Preventing 550 5.7.1 going forward#

• Re-check SPF, DKIM and DMARC alignment whenever you add a sending service or a new From domain.
• Watch Postmaster Tools and Microsoft SNDS so a spam-rate rise shows up before it becomes a block.
• If you send more than 5,000 messages a day to Gmail accounts, meet Google's bulk-sender requirements in full. SPF, DKIM, DMARC and, for marketing mail, one-click unsubscribe are required as of November 2026.

A 550 5.7.1 is the receiving server's verdict on who sent the message and how, and most of that is decided by DNS records and infrastructure a mail client does not own. No inbox app fixes a broken SPF record or a bulk-sender reputation problem. What a client can do is avoid adding a new hop: AI Emaily sends your day-to-day mail through the Gmail, Outlook or IMAP account you connect, so it inherits that account's SPF, DKIM and DMARC setup rather than using a separate relay. We build AI Emaily. It is a client, not a deliverability service, so the fixes above are what clear the bounce.