Troubleshooting SMTP Relay: “550 5.7.1 Relaying Denied”

When an internal server, multi-function printer (MFP), network scanner, or web application tries to send an automated outbound email, the process may immediately halt with an error like:

550 5.7.1 Relaying denied
550 5.7.1 Unable to relay
550 5.7.1 Client host [xxx.xxx.xxx.xxx] was not authenticated

Quick Answer

The error 550 5.7.1 Relaying Denied means the destination SMTP server refused to forward a message to an external recipient because the sending device failed to authenticate, or its public IP address is not included in the server’s authorized relay whitelist. Configure SMTP authentication or add the sending IP address to your mail system’s relay policy.

---

What the Signal Means

To prevent servers from being hijacked by spammers as “Open Relays,” all modern mail transfer agents (MTAs)—such as Google Workspace, Exchange Online, and Postfix—strictly regulate who can route mail through them to external domains.

• Local Delivery: An unauthenticated client can often deliver an email to user@yourcompany.com if the receiving server hosts yourcompany.com.
• Relaying: When a client sends a message through the server addressed to externaluser@gmail.com, the server is being asked to relay.

The 550 5.7.1 response code explicitly indicates that the server recognized the destination address as external and refused transmission because the client established no trusted identity.

---

Technical Causes

550 5.7.1 Relaying Denied
│
├── Are you using smtp.gmail.com or smtp.office365.com directly?
│   ├── YES ──► Device is missing SMTP credentials or using port 25 instead of 587.
│   └── NO  ──► Custom Relay / Workspace SMTP Relay Service.
│
├── Is the sending device behind a dynamic public IP?
│   ├── YES ──► IP mismatch in Admin Console whitelist.
│   └── NO  ──► Sender envelope address ("From") does not match authorized domain.

1. Missing or Incomplete SMTP Authentication: Many legacy devices have an “SMTP Auth” toggle that defaults to disabled. The device connects to port 25, sends HELO/EHLO, and immediately transmits RCPT TO:<external@domain.com> without issuing an AUTH LOGIN sequence.
2. Unlisted Public Outbound IP: When using IP-based relays (like Google Workspace’s smtp-relay.gmail.com or Microsoft 365’s direct connectors), the receiving endpoint checks the public IP of your network gateway. If your ISP changes your public IP or your traffic routes through an unlisted secondary WAN, the relay rejects the connection.
3. Envelope Sender (Return-Path) Mismatch: Enterprise relays often enforce policy checks: if the scanner authenticates as scanner@company.com, but the software sets the From header to accounting@clientvendor.com, the relay drops the connection to prevent spoofing.
4. Port and TLS Mismatches: Connecting via port 25 when an endpoint demands explicit TLS on port 587 prevents the authentication stage from completing.

---

Step-by-Step Diagnostic and Resolution Procedure

1. Verify Authentication Configuration on the Device

If your device is capable of storing credentials:

• Ensure the server name matches your provider’s authenticated endpoint (for example, smtp.gmail.com or smtp.office365.com).
• Change the port from 25 to 587 (STARTTLS) or 465 (SSL/TLS).
• Enter the full email address as the username (e.g., device@domain.com).
• Verify the password is valid. If 2-Step Verification is enabled on that account, you cannot use the normal password; you must supply a generated App Password. If your device returns credential errors here, see “535 5.7.8” (Authentication Failed).

---

2. Configure Google Workspace SMTP Relay (For IP Whitelisting)

If your sending hardware cannot store credentials or support modern TLS, use Google’s authorized SMTP relay service instead of standard user authentication:

1. Log in to the Google Admin Console.
2. Go to Apps > Google Workspace > Gmail > Routing.
3. Scroll down to SMTP relay service and click Configure (or Edit).
4. Check Only accept mail from the specified IP addresses.
5. Click Add and enter the public static IPv4 or IPv6 address of your office or datacenter network.
6. Under Allowed senders, decide your policy:
   • Only registered Workspace users: Requires the From address to exist as a live mailbox in your tenant.
   • Only addresses in my domains: Allows generic system aliases (like noreply@domain.com or scanner@domain.com) as long as the domain is verified in your account.
7. Check Require TLS encryption (if supported by your sending client).
8. Save the policy. (Note: Google routing policies can take anywhere from 15 minutes to an hour to distribute across all global nodes).

On the sending device:

• Server: smtp-relay.gmail.com
• Port: 25, 465, or 587
• Authentication: Disabled (Turn off username/password fields).

---

3. Test the Relay via Command Line (PowerShell)

To confirm whether the issue lies with the device’s internal settings or the mail server’s IP whitelist, run an active test from the same local network:

$SMTPServer = "smtp-relay.gmail.com"
$Port = 587
$From = "scanner@yourdomain.com"
$To = "yourpersonalemail@gmail.com"

Send-MailMessage -From $From -To $To -Subject "Relay Test" -Body "Testing relay permissions." -SmtpServer $SMTPServer -Port $Port -UseSsl

• If this command outputs 550 5.7.1, the public IP running this command is not authorized in your Google or Microsoft tenant. Check what your public IP is by querying curl ifconfig.me and compare it against your admin whitelist.
• If this succeeds, the mail routing rules are intact, and the problem is tied to local field settings on your network printer or custom script.

If your mail passes through an on-premises Exchange boundary before reaching the cloud, verify that the receive connector permissions are set up correctly. For guidance on hybrid relay paths, see Fix: “Recipient address rejected” (SMTP Relay).