What causes a 'relaying denied' error when sending emails, and how can I diagnose the issue?
Published 23 May 2025
Updated 25 Oct 2026
18 min read
Summarize with
Updated on 25 Oct 2026: We clarified sender verification callouts and corrected the SMTP tests for diagnosing relay denials.
A relaying denied error means a mail server refused to accept the message because it did not consider the sender authorized to relay, or it did not recognize the recipient domain as one it accepts or routes. In practical terms, your sender reached a mail host, issued the SMTP conversation, and the host said: this recipient is not local here, and you are not allowed to use me as the relay.
The likely cause depends on which server issued the rejection. If an app or mail client is submitting through its outbound server, the usual causes are missing SMTP authentication, the wrong server or port, an untrusted source IP, or a sender identity the relay does not permit. If an outside sender reaches a domain's published MX and that MX rejects the domain as non-local, the receiving side has an MX, accepted-domain, or routing fault.
Destination-side faults often appear during migrations, abandoned bounce domains, suspended mail services, wrong MX targets, and platforms that route replies or bounces to a domain that no longer has working mail handling. Sender-side faults often follow credential changes, connector changes, or an application moving to a new source IP.
Start by identifying which server rejected the message. For an application submitting through its outgoing mail server, check that relay's authentication and permissions first. For direct delivery to the recipient domain, look up its MX records, test each host through RCPT TO, and compare the exact replies with the original bounce.
What relaying denied means
SMTP servers handle two different jobs. They accept mail for domains they host or route, and they relay mail for authenticated or trusted senders. A relaying denied response appears when the server thinks neither condition is true.
That distinction matters because the wording can mislead people. It can mean your application used the wrong outbound SMTP server without authentication. But when the recipient domain publishes an MX record pointing at the rejecting host, the host itself is often not ready to receive mail for the domain.
- Recipient setup: The MX target exists, but the receiving server does not have the domain in its accepted-domain, virtual-host, or local-recipient configuration.
- Sender setup: The sender used a relay host that requires SMTP authentication, a trusted IP, TLS, or a specific envelope sender domain.
- DNS setup: MX records point at the wrong host, old provider, parked domain, stale migration target, or a host with split internal and external routing.
- Platform setup: A marketing, CRM, billing, or ticketing system uses a bounce, reply, or inbound route domain that has been removed, suspended, or only partly provisioned.
The direct test
If the sender is a normal outside sender and the recipient domain's MX points at the rejecting server, a relay denial is evidence of a destination routing or recipient-policy problem. Check accepted-domain routing first, then compare recipient and source-IP policies in the receiving logs; the reply alone does not prove a domain-wide routing fault.
Common causes of relay access denied
The exact SMTP reply varies. You will see 550 5.7.1, 553, 554 5.7.1, 454 4.7.1, relay access denied, relay not permitted, and we do not relay. RFC 3463 defines 5.7.1 as delivery not authorized, message refused. Servers use it for relay policy and other host or recipient filtering, so the words after the code and the SMTP stage matter more than the number alone.
A 4xx reply is temporary, so a sending mail server normally queues the message and retries; a mail client or application needs its own retry handling. A 5xx reply is permanent for the rejected command or recipient and normally produces a non-delivery report after queued delivery, although a new attempt can succeed after the configuration changes. Identify which server rejected the recipient before deciding whether to wait or fix a permanent policy fault.
The same 5.7.1 code also covers restricted groups and incorrect routing, as described in Microsoft's 5.7.1 troubleshooting guidance. Read the complete response rather than treating every 5.7.1 bounce as an SMTP authentication failure.
|
|
|
|---|---|---|
Wrong MX | DNS | The domain points to a host that does not receive for it. |
Migration drift | Old MX | DNS changed before the new tenant or mailbox routing was complete. |
Dead bounce domain | Return path | Automated replies or bounces go to a domain the sender no longer handles. |
Relay auth missing | SMTP auth | The sender used a submission or relay server without permission. |
TLS missing | Relay policy | The relay requires STARTTLS or implicit TLS before it accepts mail. |
Recipient restriction | Mailbox or group | The address, alias, list, or route does not accept that sender. |
Policy block | Logs | The host rejected based on domain, IP reputation, connector policy, or internal rules. |
Typical causes and where to investigate
If the same domain accepts normal mailbox addresses but rejects one alias, distribution list, or inbound route, check recipient permissions and address validity before changing sender authentication.
Autoresponders make this look stranger than it is. An out-of-office reply can target the Return-Path or bounce address on the original message. If that address belongs to a platform's bounce subdomain and that subdomain is broken, your autoresponder exposes a problem that normal one-way campaign traffic hides.
SMTP relay access denied diagnosis flowchart with MX and recipient checks.
How to diagnose a relaying denied error
Start with the exact bounce. Capture the full SMTP response, envelope recipient, rejecting hostname and IP, timestamp with time zone, original envelope sender, source public IP, and queue ID or message trace ID when available. Without those details, people guess between recipient DNS, sender relay, and reputation issues.
- Identify the issuer and recipient: Decide whether the response came from your submission relay, an inbound route, or the recipient host. Use the envelope recipient in the SMTP rejection, not only the visible To header. For forwarded mail, follow the remote response to the configured next hop; the server generating the NDR can be reporting a downstream refusal.
- Look up MX records: Query the exact recipient domain. Check every MX host and priority, including hosts with equal priority. After a migration, compare authoritative DNS with the resolver used by the sending server and check cached MX TTLs before removing the old route.
- Connect to each MX: Test port 25 only through the recipient stage, using the original sending server or the same public source IP where practical. A test on a different network can encounter different policies. Record the target IP and compare IPv4 and IPv6 if the hostname has both.
- Compare responses: If all MX hosts reject the same valid recipient under comparable conditions, investigate accepted-domain routing and shared recipient or source-IP policy. If only one host rejects it, suspect stale or inconsistent MX configuration.
- Check sender submission: If only your application gets the error, verify the relay endpoint, port, SMTP authentication, TLS mode, allowed source IP, and permitted sender identity. Check SPF, DKIM, or DMARC only when the response or logs identify an authentication-policy failure.
MX lookupBASH
dig +short MX example.org # Or, with more detail: dig MX example.org
Then test each MX target with an address you are authorized to test. Replace the example addresses with the actual envelope addresses. Stop after the recipient command to inspect the refusal without submitting message content.
SMTP recipient-stage test with swaksBASH
swaks --server mx1.example.org \ --port 25 \ --from sender@yourdomain.com \ --to bounce-id@example.org \ --quit-after RCPT
A 250 response to RCPT TO means the server accepted that recipient at this stage; it does not prove final delivery or mailbox existence. A relaying denied response points to relay authorization or domain and recipient policy. RFC 5321 allows some recipient checks to occur later, so confirm the cause in the server logs.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After relay access works, send a real test message and inspect the headers and authentication result. Suped's email tester checks how a message actually arrives, including authentication and domain match. A successful delivery through another SMTP route does not validate the failing relay.
What the SMTP transcript tells you
The position of the rejection in the SMTP conversation is more important than the wording alone. A rejection at connection time points to IP, network, or reputation controls. A rejection after MAIL FROM points toward the sender identity. A rejection after RCPT TO points toward relay authorization or whether the server accepts that recipient domain and address. Some servers defer sender or IP checks until this stage, so confirm the policy in the logs. DKIM and DMARC require message headers and cannot be evaluated by an RCPT-only test.
If the log never reaches a 220 greeting and instead says connection refused, do not treat it as relaying denied. That is a TCP connection failure. Check the target IP and port, whether an SMTP service is listening, firewall rules, and hosting-provider port 25 restrictions. Check reputation or blocklist (blacklist) status when a server response or firewall log identifies that policy.
PTR and reverse DNS checks belong in the diagnosis only when the SMTP response mentions PTR, IP name lookup, forged host, or a HELO/EHLO identity problem. If a PTR lookup is explicitly cited, ask the IP owner to configure reverse DNS and ensure the returned hostname resolves back to that IP. Otherwise, fix the relay authorization or recipient routing evidence first.
Recipient-side failure
- MX matches rejection: The rejecting host is published as an MX for the recipient domain.
- RCPT fails: The server refuses the recipient before content is sent.
- Likely owner: The recipient domain owner, mail provider, or sending platform that owns the bounce domain.
Sender-side failure
- Relay host mismatch: The sender connected to a submission server that requires authentication.
- Only one app fails: Normal mailbox sending works, but one system uses the wrong SMTP route.
- Likely owner: The application, SMTP relay administrator, or the DNS owner for the sender domain.
Typical recipient-side rejection
220 mx1.example.org ESMTP EHLO tester.yourdomain.com 250 mx1.example.org MAIL FROM:<sender@yourdomain.com> 250 2.1.0 Ok RCPT TO:<bounce-id@example.org> 550 5.7.1 relaying denied
That transcript shows the server accepted the MAIL command and then rejected the recipient. It does not establish whether accepted-domain routing, relay authorization, or a deferred sender policy caused the refusal. If the reply instead mentions authentication required, No TLS, sender domain mismatch, or invalid sender domain, follow the sender-side evidence before changing the recipient MX.
When sender verification causes a relay denial
Some receiving servers use sender verification callouts before accepting mail. They contact the envelope sender domain's MX to check whether a bounce can reach that address. A failed callback can produce a Sender verify failed response containing a remote relay access denied error.
- Find the tested address: The callback tests the original MAIL FROM address, rather than the original recipient. Read the remote response and identify which domain and MX rejected that callback.
- Match the callback conditions: Check the source IP and whether the callback uses an empty MAIL FROM address. Different sender or source-IP policies can explain why a manual test gives a different result.
If the callback fails, ask the return-path domain owner to check accepted-domain routing and address restrictions. If the callback succeeds but incoming mail still fails, inspect the receiving server's verification policy, timeouts, and cached results. The sender verification documentation explains these callback checks.
DNS and authentication checks
Run DNS and authentication checks after locating the rejecting host and SMTP stage. MX and accepted-domain settings control inbound routing. SMTP AUTH and connector rules control relay permission; TLS encrypts the session and is often required before authentication. SPF, DKIM, and DMARC verify sending identity, but they do not grant an application permission to use an outbound relay.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Use a domain health check to find obvious DNS and authentication faults around a domain you control. For ongoing domains, Suped's DMARC monitoring helps map sending sources and spot authentication changes near the time of a relay incident. Use the SMTP transcript for the relay decision and the monitoring data for your domain's surrounding evidence. Messages rejected before DATA have no visible From header available for DMARC evaluation; investigate those refusals in SMTP logs.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The important point is ownership. If the failing address is a bounce address on a third-party domain, document the transcript and ask that provider to correct the routing. If the failing address is on your domain, check the following in order.
- MX records: Confirm each host is still the intended inbound provider and has the domain enabled.
- Accepted domains: Confirm the mail system treats the domain as local, hosted, or otherwise valid for inbound delivery.
- Bounce domains: Confirm Return-Path and custom return-path domains used by platforms still have working DNS and mail handling.
- SPF and DKIM: Confirm the sending platform is authorized in SPF and signs with the expected DKIM domain.
- DMARC domain match: Confirm the visible From domain matches, under DMARC rules, either the SPF-authenticated envelope sender domain or a passing DKIM signature domain.
- TLS and connectors: Confirm any outbound relay connector trusts the public sending IP, including changes caused by NAT, VPNs, or hosting moves, and accepts the encryption mode your application uses.
When the recipient side owns the fix
A relaying denied bounce that comes back from an autoresponder can be a sign that the original sender has a broken bounce domain. Check abandoned platform bounce domains and migration changes where the visible sender still works but the envelope sender path does not.
Autoresponders expose broken return paths
If a vacation responder sends to a bounce-style address and that address fails with relaying denied, the return path failed for that delivery attempt. Ask the return-path domain owner to distinguish broken inbound routing from a source-IP or recipient-policy restriction. An autoresponder rejection alone does not prove the domain rejects all incoming mail.
A concise provider note works best. Include the envelope addresses, source public IP, rejecting hostname and IP, SMTP transcript, timestamp with time zone, and queue or trace ID when available. Ask the provider to verify inbound routing before debating generic deliverability.
Evidence to send to a provider
Envelope sender: sender@yourdomain.com Recipient tested: bounce-id@example.org Source public IP: <actual sending IP> MX tested: mx1.example.org Rejecting IP: <actual destination IP> Test time: <timestamp with time zone> Queue or trace ID: <ID if available> SMTP stage: RCPT TO Remote response: 550 5.7.1 relaying denied Please check accepted-domain routing and recipient/source-IP policy.
If the provider says the domain is correct, ask them to confirm the domain is listed as an accepted inbound domain on every published MX host. A published MX record alone does not prove the receiving server has been configured to accept the domain.
When the sender side owns the fix
The error is yours to fix when your application uses an SMTP server as a relay without meeting that server's rules. This happens with website forms, CRM plugins, e-commerce systems, scanners, ticketing tools, and self-hosted apps.
|
|
|
|---|---|---|
No SMTP auth | Enable auth | App admin |
Wrong relay | Use submission | Mail admin |
IP not trusted | Add scoped allowlist | Relay admin |
Bad sender | Use an approved sender address | App or mail admin |
No TLS | Match STARTTLS or implicit TLS to the port | App admin |
Sender policy fail | Match relay policy | Mail admin |
Sender-side fixes
The clean fix is to use the provider's submission endpoint, authenticate with the right account or token, use a permitted sender domain, and configure SPF and DKIM for the domain used in mail. SPF, DKIM, and DMARC support receiver trust but do not replace SMTP AUTH. For app submission, use port 587 with STARTTLS or port 465 with implicit TLS, according to the relay's settings. Port 25 is for server-to-server delivery and is often blocked by hosting providers.
If the relay returns 550 Mismatching sender domains in PrestaShop or another custom SMTP setup, compare the SMTP username, approved sender domain, MAIL FROM, and visible From header. That is a sender-domain authorization problem, not proof that the recipient MX is broken.
If a server requires IP-based relay permission, make sure the application sends from the public IP the relay expects. Check SMTP AUTH or connector permissions for an application relay denial. Check accepted-domain, transport, or virtual-mailbox settings when the server rejects a domain it should receive or route; inbound domain settings do not grant an application outbound relay access.
Submission relay checks
When the rejecting server is your outbound relay, test submission as a separate path from MX delivery. Submission normally uses SMTP AUTH on port 587 with STARTTLS, or port 465 with implicit TLS. A private relay can also trust a fixed sending IP, but that rule must match the source IP the application actually uses.
- Authentication: Confirm SMTP AUTH is enabled for the account and that the client uses the provider-supported mechanism, including OAuth 2.0 where required. After STARTTLS, send EHLO again to inspect the available AUTH mechanisms.
- Encryption: Confirm STARTTLS or implicit TLS is enabled when the relay requires encrypted submission.
- Connector rules: Confirm the sending IP, tenant, domain, or connector rule authorizes relay to external recipients.
- Sender identity: Confirm the envelope sender, visible From header, and approved sender domain match the relay's policy.
- Greeting: Confirm HELO or EHLO uses a sensible fully qualified host name when the server enforces greeting checks.
This example applies where password-based SMTP AUTH is supported. Enter the password at the protected prompt rather than placing it in shell history. If the provider requires OAuth 2.0, test with a client configured for that flow. For port 465, use --tls-on-connect instead of --tls.
Recipient-stage submission test for password-enabled SMTP AUTHBASH
swaks --server smtp.example.com \ --port 587 \ --tls \ --auth \ --auth-user app@example.com \ --protect-prompt \ --auth-hide-password \ --from app@example.com \ --to external-recipient@example.net \ --quit-after RCPT
An AUTH success reply is 235 2.7.0; 535 5.7.8 indicates invalid authentication credentials. RFC 4954 defines these replies. If AUTH succeeds but RCPT TO fails, inspect relay scope and sender permissions. If the test reaches RCPT successfully but the application fails, compare its credentials, AUTH mechanism, envelope sender, TLS mode, and source IP. The test stops before DATA, so it does not test the visible From header or final delivery. If the log mentions No TLS or tenant attribution, inspect the relay connector and encryption policy before changing SPF or DMARC.
Legacy POP before SMTP setups are fragile because the authorized IP can change between receiving and sending mail. Use authenticated SMTP submission when the relay supports it.
Do not create an open relay
A relay denial is a security control. Do not fix it by allowing unauthenticated internet clients to send to arbitrary external recipients. That creates an open relay, which can be abused for spam and can put the server's IP or domain on a blocklist (blacklist).
- Client submission: Require SMTP AUTH on port 587 with STARTTLS or port 465 with implicit TLS.
- Device relays: If a device cannot authenticate, use a dedicated connector limited to explicit source IP addresses and the necessary recipient scope.
- Server transfer: Keep port 25 for mail transfer and accept non-local recipients only when a specific connector or routing rule permits them.
- External verification: Test from an untrusted external IP and confirm the server still rejects mail when neither the sender nor recipient is authorized.
What a safe fix looks like
The intended client succeeds after authentication or through a narrowly scoped connector, while the same unauthenticated relay test remains denied. Keep logs and rate limits enabled so later misuse is visible.
How Suped supports the workflow
Suped's DMARC reporting and email authentication platform helps teams check their own domain's DNS and authentication evidence around a relay incident. Use that evidence alongside the rejecting server's SMTP logs to distinguish an authentication change from a routing or relay-permission failure.
- Establish the baseline: Review the domain's MX and authentication state before changing relay settings.
- Check incident timing: Compare the failure time with authentication changes and newly observed sending sources.
- Confirm sender identity: Use DMARC data to see which systems send for the domain and whether SPF or DKIM passes with a matching domain.
- Prepare the handoff: Combine domain evidence with the SMTP transcript when a mail administrator or provider owns the fix.
For teams using Suped, the repeatable workflow is straightforward: use the transcript to explain one refusal, then use monitoring to confirm that your domain's authentication remains stable after sender or bounce-routing changes.
Diagnosis confidence
Use the available evidence to decide how certain you can be before escalating.
Low
Bounce text only
Only a user-facing bounce is available.
Medium
DNS plus host
MX records and the rejecting host match.
High
Reproduced refusal plus logs
The refusal is reproduced under comparable sending conditions and receiving logs identify the rejecting rule.
Views from the trenches
Best practices
Check each MX host directly before blaming the sender or changing authentication records.
Capture the RCPT-stage SMTP reply so the receiving provider can reproduce the fault.
Separate visible From, envelope sender, and bounce domain before assigning ownership.
Common pitfalls
Assuming an MX record proves the receiving server accepts mail for that domain externally.
Treating autoresponder bounces as proof that the autoresponder caused the problem.
Changing SPF or DKIM before confirming whether the rejection happened at RCPT stage.
Expert tips
Use recipient-stage testing to get a clear answer without sending a full message.
Compare all published MX hosts because split or stale routing can affect only one host.
Keep a short transcript with time, MX host, sender, recipient, and exact SMTP reply.
Marketer view
Marketer from Email Geeks says a published MX record is not enough if the server does not believe it receives mail for the domain.
2024-06-20 - Email Geeks
Marketer view
Marketer from Email Geeks says a dead destination domain, broken DNS, or unfinished service migration can produce this error.
2024-06-20 - Email Geeks
