Fix: “550 5.7.1” Authentication Required

October 17, 2026 5 min read

When an SMTP mail client, network scanner, web application, or automated script attempts to send email through Google’s outbound mail infrastructure and receives 550 5.7.1 Authentication Required (or 550 5.7.1 Relaying Denied), the mail server rejected the outbound connection. This error indicates that the client attempted to transmit a message without providing valid user credentials, connected to an encryption port requiring mandatory authentication, or sent mail from an IP address not authorized in your Google Workspace SMTP Relay configuration.

Quick Answer

The 550 5.7.1 Authentication Required error means your mail client attempted to send an email without authenticating. To resolve it, configure your client to connect via port 587 with TLS enabled, and provide a full Google email address and an App Password. If using Google’s SMTP Relay service, add your public IP address to the relay allowlist in the Google Admin Console.

Understanding the 550 5.7.1 Code

The 550 prefix indicates a permanent failure (the command was rejected and will not succeed upon immediate automatic retry), while the enhanced status code 5.7.1 denotes a security or policy denial—specifically, unauthorized delivery.

In Google’s mail ecosystem, this error occurs across two distinct pathways:

  1. Submission via smtp.gmail.com: Used by personal devices, email clients (Outlook, Thunderbird), web contact forms, and multi-function printers. The connection was made, but the sender issued the MAIL FROM command before completing a successful AUTH LOGIN handshake.
  2. Submission via smtp-relay.gmail.com: Used by organizations for high-volume automated delivery. The sending server reached the relay, but Google found no matching IP address rule or valid Workspace authentication token, rejecting the message to prevent open relay abuse.

Diagnostic Step 1: Troubleshoot Standard SMTP (smtp.gmail.com)

If your device or application sends mail through smtp.gmail.com, Google requires modern authentication or account-specific application passwords. Standard account passwords will fail.

A. Verify Port and Encryption Parameters

Ensure your application uses one of Google’s supported outbound configurations:

  • Port 587 (Recommended): Requires STARTTLS encryption. The client begins unencrypted, issues the STARTTLS command, negotiates encryption, and then authenticates.
  • Port 465: Requires implicit SSL/TLS. The connection is encrypted before any SMTP commands are exchanged.
  • Note: Avoid Port 25. Most internet service providers block outbound Port 25, and Google will reject unauthenticated connections on this port.

B. Replace Standard Passwords with an App Password

Google discontinued “Less Secure Apps” (plain username and account password authentication). If your application does not support OAuth2:

  1. Log in to the Google Account at myaccount.google.com.
  2. Go to Security > 2-Step Verification and confirm 2-Step Verification is active.
  3. Scroll to the bottom of the 2-Step Verification page and select App passwords.
  4. Enter an application name (e.g., WordPress SMTP or Office Copier) and click Create.
  5. Copy the generated 16-character alphanumeric key.
  6. Paste this key—without spaces—into your device’s SMTP password field.

If your client continues to report authentication credentials failed after generating an App Password, review “535 5.7.8” (Authentication Failed).

Diagnostic Step 2: Troubleshoot Google Workspace SMTP Relay (smtp-relay.gmail.com)

If your enterprise application routes outbound notifications through Google’s dedicated relay endpoint, the error indicates a policy mismatch in the Google Admin Console.

  1. Sign in to the Google Admin Console as an administrator.
  2. Navigate to Apps > Google Workspace > Gmail > Routing.
  3. Scroll down to the SMTP relay service setting and click Configure (or Edit).
  4. Review the three security controls:

1. Allowed Senders

  • Only registered Workspace users in my domains: The From: header must match an active account in your Google Workspace directory. If an application attempts to send from noreply@externaldomain.com, Google rejects it with 550 5.7.1.
  • Only addresses in my domains: The address must belong to one of your verified domain aliases or primary domains, but does not need an assigned user inbox.
  • Any addresses: Allows the relay to send on behalf of outside addresses (use with caution to prevent reputation loss).

2. Authentication Rules

  • Only accept mail from the specified IP addresses: If checked, ensure your external gateway or office public IP is listed. If your internet service provider changes your public WAN IP, the relay will immediately begin throwing 550 5.7.1 until updated.
  • Require SMTP Authentication: If checked, connecting clients must issue AUTH LOGIN with valid Google Workspace credentials, even if their IP address is whitelisted.
  • Require TLS encryption: If checked, unencrypted connections are rejected immediately.

For deeper troubleshooting of relay authorization rules, consult Troubleshooting SMTP Relay: “550 5.7.1 Relaying Denied”.

Diagnostic Step 3: Inbound 550 5.7.1 Rejections

If you are a regular Gmail user sending an email to an outside recipient (such as a corporate partner or educational institution) and you receive a bounce message stating 550 5.7.1 Authentication Required or 550 5.7.1 Access Denied, the rejection is happening on the recipient’s mail gateway, not Google’s servers.

This condition occurs when the recipient’s firewall enforces strict DMARC, SPF, or reverse DNS policies:

Fix: “Inbound Gateway” SPF Overrides

October 21, 2026

How to Read Gmail “Original Message” Headers

October 21, 2026

Troubleshooting “Neutral” SPF Results

October 21, 2026