Email errors

550 5.7.1: what the bounce means and how to fix it

What a 550 5.7.1 bounce means, how to read the text after the code from Gmail or Microsoft 365, and whether you or the recipient's admin must fix it.

By Updated Last verified

On this page
  1. What 550 and 5.7.1 mean
  2. Read the text after the code
  3. When the recipient's side must change
  4. When your sending setup must change
  5. Authentication
  6. Sending IP and reputation
  7. How you connect
  8. Message format
  9. Before you send again
  10. Need hands-on help?
  11. Check your domain's records
  12. Sources

550 5.7.1 means the receiving mail server refused your message, and sending it again unchanged is not likely to work: 550 is the reply for a requested action not taken, including a command rejected for policy reasons (RFC 5321 (opens in a new tab)), and 5.7.1 is a permanent failure where the sender is not authorized to send to the destination (RFC 3463 (opens in a new tab)). The codes are not meant to carry the specific reason, so read the text that comes with them. Use it to work out whether your sending setup or the recipient's settings must change, and change that before you send again.

What 550 and 5.7.1 mean

Mail moves between servers over the Simple Mail Transfer Protocol (SMTP) (opens in a new tab). A bounce like this one carries two codes.

The first, 550, is an SMTP reply meaning the requested action was not taken because the mailbox is unavailable, for example because it was not found, there was no access, or the command was rejected for policy reasons (RFC 5321 section 4.2.3 (opens in a new tab)). Replies that start with 5 are permanent negative replies: the command was not accepted, the requested action did not occur, and the sending side should not repeat the exact request (section 4.2.1 (opens in a new tab)).

The second, 5.7.1, is a status code in three parts (RFC 3463 section 2 (opens in a new tab)):

  • 5 says whether the delivery attempt was successful. A 5 is a permanent failure: resending the message in its current form is not likely to fix it, and something about the message or the destination has to change.
  • 7 gives the probable source of the problem. A 7 is security or policy: failures involving policies such as per-recipient or per-host filtering, under the control of the sender, the recipient or both.
  • 1 names the precise condition. Together they read "Delivery not authorized, message refused": the sender is not authorized to send to the destination, which can be the result of per-host or per-recipient filtering (section 3.8 (opens in a new tab)).

So the code tells you the refusal was about authorization or policy, not which rule refused the message. Status codes are not intended for system-specific diagnostics.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

Read the text after the code

Gmail and Microsoft 365 both use this code for several different refusals. Microsoft (opens in a new tab) notes there can be several causes for 5.7.1, and Gmail's SMTP error reference (opens in a new tab) lists different texts that come with 550 5.7.1, from a recipient's policy to missing headers.

Gmail adds gsmtp to all its errors. It also adds gcdp (Google Custom Domain Policies) when the error results from a custom rule created by a Google Workspace administrator, so a gcdp bounce points to a rule an administrator created.

In Microsoft 365, the bounce is a non-delivery report (NDR), also called a bounce message, delivery status notification or DSN. Some causes put their details in the NDR's Diagnostics for administrators section.

Match the text to the cases below. If none fits, or the steps don't solve it, contact the recipient's email administrator.

When the recipient's side must change

In Exchange Online and Microsoft 365, 5.7.1 typically means a security setting in your organization or the recipient's organization is preventing your message from reaching the recipient (Microsoft (opens in a new tab)). Microsoft lists these cases:

  • You don't have permission to send to the recipient.
  • The recipient is a group, and you don't have permission to send to the group or one of its subgroups.
  • You don't have permission to send through an email server between you and the recipient.
  • Your message was routed to the wrong email server.

Typically you can't fix these yourself: the recipient or their email admin has to change the configuration on their end. Contact the recipient another way, such as by phone, and ask them to tell their email admin about the problem.

If the recipient is an internal group, you might not have permission to send to it or one of its subgroups, and the NDR names the restricted groups; ask the group's owner to grant you permission. Groups with more than 5,000 members require a moderator to approve messages, so join the group or ask its owner or moderator to approve yours.

On their side, the admin can add you to the group's allowed senders list, set the group to accept messages from external senders, or change a mail flow rule (also called a transport rule) that restricts you.

At Gmail, this text means the user or domain you are sending to, or from, has a policy that prohibits your message (Gmail's SMTP error reference (opens in a new tab)):

550 5.7.1 The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent. Contact your domain administrator for assistance.

Gmail's advice is to contact your domain administrator.

When your sending setup must change

Authentication

Microsoft 365 rejects messages that fail DMARC (opens in a new tab) (Domain-based Message Authentication, Reporting, and Conformance) during SMTP with 550 5.7.1 when the sender's domain publishes p=reject; that is its general behavior for inbound mail when Honor DMARC record policy is on (Microsoft (opens in a new tab)).

Sender Policy Framework (SPF) (opens in a new tab) lets a domain publish, in the Domain Name System (DNS) (opens in a new tab), which hosts may use its name, and receivers test the sending server against that list. DomainKeys Identified Mail (DKIM) (opens in a new tab) signs a message so the receiver can confirm the signed content has not changed.

Since February 1, 2024, Gmail (opens in a new tab) has required all senders to Gmail accounts to set up SPF or DKIM for their sending domains. Microsoft (opens in a new tab) lists an incomplete SPF record as a cause too: your domain's SPF record might not include all the email sources for your domain.

The DMARC fail guide covers reading the Authentication-Results header and fixing SPF and DKIM alignment. The SPF record generator builds an SPF record from the services that send email for your domain, with an estimate against the 10 DNS lookup limit.

Sending IP and reputation

Gmail rejects with 550 5.7.1 when the sending server's IP address is on an IP suspended list, which can happen when you send from a shared IP address with a poor reputation. The activity of every sender on a shared IP address affects the reputation of all of them.

Gmail's SMTP error reference (opens in a new tab) has more texts about reputation and spam:

550 5.7.1 This message is likely suspicious due to the very low reputation of the sending IP address.
550 5.7.1 This message is likely suspicious due to the very low reputation of the sending domain.
550 5.7.1 This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.

At Microsoft 365, when an external sender's source IP address is on Microsoft's blocklist, the NDR's Diagnostics for administrators section includes information similar to a client host blocked using Blocklist 1. To remove the restriction, forward the NDR to [email protected].

How you connect

Gmail refuses mail from an IP address that is not authorized to send directly to its servers, and tells you to use the SMTP relay at your service provider instead:

550 5.7.1 The IP you're using to send email is not authorized to send email directly to our servers. Use the SMTP relay at your service provider instead.

Gmail also requires valid forward and reverse DNS for sending domains or IPs: the sending server's public IP address needs a PTR record that resolves to a hostname (the reverse lookup), and that hostname needs an A or AAAA record that resolves back to the same IP address (the forward lookup). For mail over IPv6, the error below can mean the sending server's PTR record isn't using IPv6; if you send through an email service provider, confirm they use an IPv6 PTR record.

550-5.7.1: Message does not meet IPv6 sending guidelines regarding PTR records and authentication.

Message format

Gmail requires messages formatted to the Internet Message Format standard, RFC 5322, and refuses messages with header problems such as these:

550 5.7.1 Messages missing a valid address in the From: header, or having no From: header, are not accepted.
550 5.7.1 Messages missing a valid Message-ID: header are not accepted.
550 5.7.1 Messages with multiple addresses in the From: header are not accepted.

Before you send again

Don't resend the same message unchanged. A permanent failure is not likely to be resolved by resending the message in its current form (RFC 3463 section 2 (opens in a new tab)), and after a 5xx reply the sending side should not repeat the exact request (RFC 5321 section 4.2.1 (opens in a new tab)). Even some permanent errors can be corrected, so once the cause is fixed, on your side or the recipient's, you can send again.

Need hands-on help?

DemiEmail (opens in a new tab) is the hands-on side: DemiSignal provides ongoing email authentication monitoring, and DemiEmail handles scoped technical work. It investigates reported delivery problems using the available rejection messages, headers, reports and sending configuration, and gives prioritized, evidence-based next steps; it also configures or troubleshoots SPF, DKIM and DMARC across the services sending email for a business. The work, required access, deliverables and price are agreed as the scope, so you know what it costs before the work begins.

Check your domain's records

When the text points to authentication, DemiSignal's check shows what your domain publishes, with no account needed. It reports SPF (the servers allowed to send email for your domain), flagging a missing record, a soft fail (~all) and a record close to or over the 10 DNS lookup limit; DKIM keys under commonly used selectors; DMARC; and MX, which shows where your domain receives email.

It only reads the public DNS records of the domain you enter. A DNS finding shows how your domain is set up; it does not show where a particular message landed.

Sources

Tools for this

Frequently asked questions

What does 550 5.7.1 mean?

The receiving server refused the message because the sender is not authorized to send to that destination, and resending it unchanged is not likely to work. Status codes are not meant for system-specific diagnostics, so read the text that comes with the code.

Can I fix a 550 5.7.1 error myself?

It depends on the text. For permission and group restrictions at a Microsoft 365 recipient, typically not: the recipient or their email admin has to change their configuration. Gmail's sender requirements, such as SPF or DKIM, valid PTR records and RFC 5322 formatting, are yours to meet.

Should I resend the message?

Not unchanged. After a permanent 5xx reply the sender should not repeat the exact request. Fix the cause the text points to first, then send again.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account