Resolving “5.7.0” Permanent Failure: Access Denied

When an outbound email bounces with 550 5.7.0 Permanent Failure: Access Denied (or an equivalent SMTP status like 554 5.7.0), the receiving mail system or outbound relay has permanently rejected the message due to an explicit security policy block. This error indicates that the sending server’s IP address is untrusted, the connection lacks mandatory authentication, or the sending client is attempting to route through an unauthorized mail relay.

Quick Answer

To resolve a 5.7.0 Access Denied error, verify the sending context first. If using an outbound SMTP relay, ensure the device or application IP is whitelisted in your Google Workspace or Microsoft 365 relay settings. If sending to an external recipient, verify your public sending IP has valid reverse DNS (PTR) and is not blocklisted.

---

What the 5.7.0 Signal Means

In the SMTP status code hierarchy, the prefix 5.X.X denotes a permanent failure. The sub-code X.7.0 indicates a generic security, authentication, or access control violation:

• Class 5: Permanent failure. The sending server will not retry delivery automatically.
• Subject 7: Security or policy issue (covering encryption, authentication, relay authorization, and sender reputation).
• Detail 0: Other or unspecified security status.

Because 5.7.0 is a catch-all security code, determining the root cause requires checking whether the rejection happened at your outbound relay gateway (before the email left your organization) or at the recipient’s inbound gateway.

[Sending Device / App]
           │
  (Attempts to connect)
           │
           ▼
[Outbound Relay: smtp-relay.gmail.com] ──(Rejected: 550 5.7.0?)──► IP not authorized or missing auth
           │
  (Relay accepts & forwards)
           │
           ▼
[Inbound Gateway: Recipient Server]   ──(Rejected: 550 5.7.0?)──► IP blocklisted or missing PTR/TLS

---

Common Root Causes

Scenario A: Outbound Relay Rejections (Internal)

If network printers, scanners, ERP systems, or local web servers encounter 5.7.0 Access Denied when attempting to send through smtp-relay.gmail.com or Microsoft 365 Exchange Online:

• Unregistered Public IP: The outbound public IP address of the local network is not registered in the Workspace SMTP relay service configuration.
• Missing or Incompatible TLS: The sending appliance does not support TLS encryption, but the relay policy enforces strict TLS handshakes.
• Unauthenticated Envelope Senders: The sending script uses an arbitrary From address that does not match the authenticated account or authorized domain.

Scenario B: Inbound Gateway Rejections (External)

If external mail transfer agents reject messages from your corporate mail servers with 5.7.0:

• Missing Reverse DNS (PTR Record): The receiving server checks the connecting IP address against the DNS pointer record. If no valid PTR record matches the sending hostname, the connection is denied.
• IP Reputation Blocks: The public sending IP was flagged on an anti-spam blocklist (such as Spamhaus or Microsoft’s internal IP block list).
• Mandatory TLS Enforcement: The receiving domain requires all inbound connections to negotiate TLS, but your sending server attempted a plain-text transmission.

---

Diagnostic Steps

Step 1: Inspect the SMTP Transcript or Non-Delivery Report

Review the complete diagnostic text in the bounce message. The server typically provides an explanatory string following the code:

• 550 5.7.0 IP [198.51.100.2] is not authorized to send from domain... indicates an outbound relay IP whitelist failure.
• 550 5.7.0 Access Denied, banned sending IP indicates an external reputation block.
• 530 5.7.0 Must issue a STARTTLS command first indicates an encryption negotiation failure. For specific steps on this error, see SMTP Error “530 5.7.0 Must issue STARTTLS”.

Step 2: Test Reverse DNS and Hostname Resolution

If external recipients are blocking your mail, verify that your sending IP has an active PTR record matching your hostname:

# Query the PTR record of your sending IP
dig -x 198.51.100.25 +short

# Verify the forward lookup of that hostname matches the IP
dig mail.example.com +short

If the IP has no PTR record, or the forward and reverse records do not match (Forward-Confirmed reverse DNS), receiving servers will drop the connection. Follow the remediation steps in Resolving “PTR Record Missing” for SMTP Relay and “550 5.7.25” IP Address Reverse DNS (rDNS) Failure.

---

Technical Fixes

Fix 1: Authorize Sending IPs in Google Workspace SMTP Relay

If network scanners or applications fail when sending through smtp-relay.gmail.com:

1. Sign in to the Google Admin Console.
2. Navigate to Apps > Google Workspace > Gmail > Routing.
3. Scroll to SMTP relay service and click Configure (or Edit).
4. Under Allowed senders, choose whether only registered domain users or any sender can submit mail.
5. Under Authentication, check Only accept mail from the specified IP addresses.
6. Enter the static public WAN IP address of your office or hosting server.
7. Under Encryption, require TLS if your devices support modern ciphers; otherwise, uncheck the requirement only on secured local networks.
8. Save changes and wait 10 to 15 minutes for the policy to propagate. If issues persist with authorization, review Troubleshooting SMTP Relay: “550 5.7.1 Relaying Denied”.

Fix 2: Delist Banned IPs from External Receivers

If Microsoft 365 or another major host rejects your emails with 550 5.7.0 Access Denied, banned sending IP:

1. Identify the exact public IP listed in the bounce message.
2. If sending to Microsoft 365, submit the IP to the Microsoft Delist Portal (https://sender.office.com/).
3. Verify your domain’s SPF and DKIM records are completely valid to ensure the sending IP is cryptographically tied to your identity, preventing automated reputation filters from re-flagging it.