cPanel 'Relay Access Denied': Why Your Server Won't Send Mail

Your contact form goes quiet, WooCommerce stops emailing order confirmations, or a cron script that used to work starts failing — and buried in the error log is one line: relay not permitted or 550 5.7.1 Relay access denied. This isn't the recipient rejecting you. It's your own cPanel server refusing to send the mail in the first place. Here's what's actually happening and how to clear it.

What "Relay Access Denied" Really Means

Every mail server (Exim, in cPanel's case) has to decide which outgoing mail it's willing to forward — "relay" — on to the rest of the internet. If it relayed anything from anyone, it would be an open relay within hours and every major provider would blacklist it. So Exim only relays mail that passes one of a few checks: it came from an authenticated account, the sending IP is explicitly trusted, or the envelope sender is a real mailbox that Exim owns.

"Relay access denied" means none of those checks passed. It's Exim's own ACL (access control list) saying "I don't recognize you as someone I'm allowed to send mail on behalf of" — before the message ever leaves the server.

Symptom: Where You'll See It

• A PHP contact form or WooCommerce checkout silently fails to send, or throws SMTP Error: Could not authenticate / Relay not permitted in PHPMailer's debug output.
• /usr/local/cpanel/3rdparty/mailman or a custom script logs 550 relaying denied when it tries to hand off mail.
• In WHM > Exim Configuration Manager or the raw mail log, you see a line like:

2026-07-28 11:42:07 H=(localhost) [127.0.0.1] F=<noreply@example.com> rejected RCPT <user@gmail.com>: relay not permitted

The key detail is the F= field — that's the envelope "From" address the script used. That's almost always where the mismatch is.

Cause 1: The Envelope Sender Doesn't Belong to the Account

This is the most common one. A script sends mail with a "From" address like noreply@example.com, but no mailbox, forwarder, or the domain example.com itself doesn't actually exist on that cPanel account — maybe it's a subdomain, an old parked domain, or a typo. Exim checks whether the sending domain is one it's authoritative for. If it isn't, and the connection isn't authenticated, it refuses to relay.

Fix: Make sure the "From" address in your script or SMTP plugin uses a domain that's actually hosted on the account (a real domain, addon domain, or subdomain listed under cPanel's Domains page), and that a mailbox or at least a forwarder exists for that address.

Cause 2: PHP's mail() Function Instead of Authenticated SMTP

PHP's built-in mail() hands the message to the local Exim binary directly — it doesn't authenticate, and on a lot of hardened cPanel servers it's restricted or the "From" header gets rewritten to match the account's default. If a plugin (WordPress's default wp_mail, an old contact form plugin) still uses mail() with a spoofed "From" like a Gmail address, Exim will refuse to relay it as that identity.

Fix: Switch to authenticated SMTP instead of PHP's mail(). In WordPress, install WP Mail SMTP (or similar) and configure it with real mailbox credentials:

SMTP Host: mail.example.com
SMTP Port: 587 (STARTTLS) or 465 (SSL)
Auth: Yes
Username: noreply@example.com
Password: (the mailbox password)

Authenticated connections skip the relay-source check entirely, because Exim now knows exactly who's sending.

Cause 3: Wrong Port or Failed SMTP Authentication

Sometimes the script is configured for SMTP but the login itself fails silently, and the fallback behaves like an unauthenticated connection. Test the credentials directly before touching anything else:

openssl s_client -connect mail.example.com:465 -quiet
# once connected:
EHLO example.com
AUTH LOGIN
# paste base64-encoded username, then base64-encoded password

If auth fails here, the problem is the credentials or the port — not a relay setting. Common trip-ups: using port 25 (many hosts and ISPs block outbound 25 for exactly this reason), a mailbox password that was changed but not updated in the plugin, or a firewall (CSF/UFW) blocking outbound 587/465 from the account's IP.

Cause 4: Server-Level Relay Restrictions (WHM/Root Access)

If you manage the VPS or WHM root yourself, Exim's relay ACL is configured in WHM > Service Configuration > Exim Configuration Manager > Access Lists. Two settings matter:

• Trusted relay hosts / IPs — IPs allowed to relay without authentication (rarely needed; leave empty unless you have a specific internal app server).
• SMTP Restrictions — should stay at the default "Standard" or stricter. Loosening this to fix one script's error opens the server to abuse and gets it blacklisted fast. Don't do it.

Instead of loosening server-wide relay rules, fix the sending script's authentication — that's the safe, correct path in every case above.

How to Actually Trace It

Don't guess — read the log. SSH in (or use cPanel Terminal) and tail the Exim main log while you trigger the failing action:

tail -f /var/log/exim_mainlog

Watch for the rejected line and note the F= (from) and H= (host) fields — they tell you exactly which address triggered the denial and where the connection came from. If you have WHM access, Track Delivery under cPanel's Email section does the same lookup with a friendlier interface, filterable by sender or recipient.

Quick Reference

Prevention

• Always send through authenticated SMTP (587/465), never bare mail(), for anything beyond a single test message.
• Keep the "From" address on a domain and mailbox that genuinely exists on the account — don't invent addresses like noreply@ unless you've created that mailbox or forwarder.
• Store SMTP credentials in a password manager and update every plugin the moment a mailbox password changes.
• If you're on a VPS, never widen "Trusted relay hosts" to silence one error — it's a shortcut to getting the server's IP blacklisted.