Email Security8 min read

"550 5.7.1 Relaying denied" — Causes & Fix

An SMTP server refused your message with a relaying-denied error because it will not accept mail it is not responsible for. Here is why it happens on the sending and receiving side, and how to fix each.

"550 5.7.1 Relaying denied" (also worded "not permitted to relay" or "relay access denied") means an SMTP server refused to forward your message because it is not responsible for the recipient's domain and you are not authorized to relay through it. A mail server only accepts mail it either hosts (the recipient is a local mailbox) or is explicitly allowed to relay for (an authenticated client). The error has two distinct causes — a sending-side one (you connected to the wrong server or did not authenticate) and a receiving-side one (your domain's MX or accepted-domains config is wrong) — and the fix depends on which you have.

What It Looks Like

The response comes back at the RCPT TO stage of the SMTP conversation. Wording varies by mail server, but the meaning is identical:

text
# Postfix 550 5.7.1 <user@example.com>: Relay access denied # Exchange / Microsoft 550 5.7.1 Unable to relay for user@example.com # Sendmail / generic 550 5.7.1 Relaying denied. Proper authentication required. 554 5.7.1 <user@example.com>: Recipient address rejected: Relay access denied

The key word is relay: the server is telling you it is neither the destination for this recipient nor willing to carry the message on to it.

Look up the recipient domain's MX records

Which Side Is the Problem?

Before fixing anything, work out whether you are sending mail that got refused, or whether your domain is rejecting inbound mail:

  • You are the sender and your outbound mail bounces — you are connecting to a server that will not relay for you. Almost always an authentication or wrong-server problem. See Fixes A–B.
  • People sending to your domain get this bounce — the server your MX points at is not configured to accept mail for your domain. A routing/config problem. See Fixes C–D.

Why It Happens

1. Sending without authentication

You are submitting mail to an SMTP server (often on port 25 or 587) without logging in. Modern servers only relay for authenticated clients; an unauthenticated connection may deliver to local mailboxes but is denied when the recipient is external.

2. Connecting to the wrong SMTP server

Your mail client or app points at a server that does not host your account — for example, using another provider's outbound host, or hitting a recipient's inbound MX and trying to send throughit to a third party. That server has no reason to relay for you.

3. Using port 25 for submission

Port 25 is for server-to-server delivery, not client submission, and is frequently blocked or relay-restricted. Client submission should use the authenticated submission port 587 (STARTTLS) or 465 (implicit TLS).

4. Your MX points at a server that does not accept your domain

On the receiving side, your MX record resolves to a host that has not been configured to treat your domain as local (no "accepted domain" / "relay recipient" entry). Legitimate senders reach it, but it refuses to accept mail it does not recognize as its own.

5. MX changed but the mail server config did not

You migrated mail hosts and updated the MX record, but the old or new server is not set to accept the domain — so inbound mail is relayed-denied even though DNS looks correct.

Relaying denied is not a spam or blacklist blockThis is a policy/config refusal, not a reputation block like "blocked using Spamhaus". The server is not saying you look like spam — it is saying it will not carry this message at all. No amount of SPF, DKIM, or reputation work changes that; you must authenticate or fix routing.

How to Diagnose It

Confirm where the recipient's mail is supposed to go, then check whether you are talking to that server and authenticating:

bash
# Where should mail for the recipient domain actually go? dig MX example.com +short # e.g. "10 mail.example.com." <- this is the server that should accept it # Are you connecting to that host, or something else? # Test the SMTP conversation (note the port — 587 for submission): openssl s_client -starttls smtp -connect smtp.yourprovider.com:587 -quiet # EHLO, then AUTH LOGIN — if AUTH is offered, you must authenticate to relay
Confirm the domain's real mail serverThe MX Lookup shows every mail exchanger and its priority so you know which host should accept the mail.
Check MX now

How to Fix It — Sending Side

Fix A — Authenticate on the submission port

Configure your mail client or application to log in and use the submission port. This is the fix for the overwhelming majority of relaying-denied bounces from your own outbound mail:

text
Outgoing (SMTP) server: smtp.yourprovider.com Port: 587 (STARTTLS) — or 465 (implicit TLS) Authentication: required (your full email + password / app password) # Do NOT use port 25 for client submission.

Fix B — Point at the correct outbound server

Make sure the SMTP host is the one that actually hosts your mailbox (your provider's outbound server), not a recipient's inbound MX or an unrelated host. If you relay through a smarthost, ensure your server's IP is on its permitted-relay list and that it authenticates.

How to Fix It — Receiving Side

Fix C — Add your domain as an accepted domain

If inbound mail to your domain is being relayed-denied, the mail server your MX points at must be told it is responsible for the domain. The exact setting depends on the platform:

  • Postfix — add the domain to mydestination or virtual_mailbox_domains.
  • Exchange / Microsoft 365 — add it as an Accepted Domain.
  • cPanel / Plesk — ensure the domain is set to use local (or the correct remote) mail exchanger.

Fix D — Align MX with the server that accepts the domain

Confirm your MX record points at the host actually configured to receive the domain's mail, and that no stale MX from a previous provider remains. After a mail migration, the MX and the server's accepted-domains list must agree:

text
; MX should point at the host that accepts mail for the domain example.com. 3600 IN MX 10 mail.example.com. ; and mail.example.com must resolve and be configured to accept example.com
Never open your server as an unauthenticated relayThe wrong "fix" is to allow relaying without authentication to make the error go away — that turns your server into an open relay, which spammers abuse within hours and which gets your IP blacklisted. Always require authentication for relaying; only accept unauthenticated mail for domains you actually host.

Verify the Fix

Confirm routing and send a testRe-check MX, then send a test to the affected recipient and confirm a clean 250 acceptance.
Verify MX now

For sending-side fixes, send a test to an external address and confirm it is accepted rather than relay-denied. For receiving-side fixes, allow for any MX/DNS TTL to expire, then have someone send to the domain and watch for a 250 acceptance:

bash
# Confirm MX resolves to the intended host dig MX example.com +short # From an external sender, a successful delivery ends with: # 250 2.0.0 Ok: queued as ... # instead of 550 5.7.1 Relay access denied

Frequently Asked Questions

My email password is correct but I still get relaying denied — why?

Either your client is not actually authenticating (SMTP auth disabled, or set to "none"), or you are on port 25 where relaying is refused regardless. Switch to port 587/465 with authentication required and confirm the SMTP username is your full email address.

Inbound mail to my domain is relay-denied — is my DNS wrong?

Possibly, but more often the DNS is fine and the mail server your MX points at simply is not configured to accept your domain. Verify MX with a lookup, then add the domain to the server's accepted/local domains. Both must agree.

Is relaying denied the same as user unknown?

No. 550 5.1.1 User unknown means the server accepts mail for the domain but the specific mailbox does not exist. Relaying denied means the server will not accept the domain at all. Different causes, different fixes.

Will authenticating fix it if I am relaying through a smarthost?

Usually yes — smarthosts relay only for permitted, authenticated clients. Ensure your server both authenticates to the smarthost and (if required) has its IP on the smarthost's allowed list.

Could this be caused by an SPF or DMARC problem?

No. Relaying denied happens before content and authentication checks matter — it is purely about whether the server will carry the message. Fix authentication or routing; SPF/DKIM/DMARC are unrelated to this particular error.

Related