What causes a 'relaying denied' error when sending emails, and how can I diagnose the issue?
Matthew Whittaker
Co-founder & CTO, Suped
Published 23 May 2025
Updated 26 May 2026
11 min read
Summarize with
A relaying denied error means the receiving mail server refused to accept the message because it does not think it should relay or deliver mail for that recipient domain. In practical terms, your sending server reached a mail host, issued the SMTP conversation, and the remote host said: this recipient is not local here, and you are not authorized to use me as a relay.
The most common cause is a bad destination-side setup: the domain's MX record points to a server that is not configured to accept mail for that domain. I see this during migrations, abandoned bounce domains, suspended mail services, wrong MX targets, and platforms that send mail from one domain but route replies or bounces to another domain that no longer has working mail handling.
The fastest diagnosis is simple: look up the recipient domain's MX records, connect to each MX host directly, run the SMTP conversation until the RCPT TO stage, and compare the rejection across hosts. If every MX says 550 5.7.1 relaying denied, the problem is usually at the recipient domain or its mail provider, not your sender.
What relaying denied means
SMTP servers handle two different jobs. They accept mail for domains they host, 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, 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 or reply 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 usually proves that the destination mail routing is incomplete or stale. Treat it as a routing and accepted-domain problem first, then check sender authentication if the same server accepts other recipients on the same domain.
Common causes
The exact SMTP code varies. You will see 550 5.7.1, 554 5.7.1, relay access denied, relay not permitted, and we do not relay. The diagnosis is the same: identify which server rejected the recipient, then decide whether that server should have accepted the message.
|
|
|
|---|---|---|
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. |
Policy block | Logs | The host rejected based on domain, IP reputation, or internal rules. |
Typical causes and what they prove
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.
A six-step flowchart for diagnosing a relaying denied error.
How to diagnose it
Start with the exact bounce. I want the full SMTP response, recipient address, rejecting server, time, and original envelope sender. Without those details, people guess between recipient DNS, sender relay, and reputation issues.
- Identify the recipient: Use the address in the SMTP rejection, not only the visible To header. Bounces often target hidden envelope addresses.
- Look up MX records: Query the exact recipient domain. Check every MX host and priority.
- Connect to each MX: Test the SMTP conversation only until the recipient stage, so you do not submit a real message.
- Compare responses: If all MX hosts reject the recipient as relay denied, the receiving domain's routing is the likely fault.
- Check sender path: If only your application gets the error, verify SMTP authentication, allowed sending IPs, envelope sender, SPF, DKIM, and DMARC.
MX lookupBASH
dig +short MX example.org # Or, with more detail: dig MX example.org
Then test each MX target. I stop after the recipient command because it gives the answer without sending message content.
SMTP recipient-stage test with swaksBASH
swaks --server mx1.example.org \ --from sender@yourdomain.com \ --to bounce-id@example.org \ --quit-after RCPT
A healthy recipient path accepts or gives a recipient-specific rejection such as user unknown. A broken relay path rejects before content and says something close to relaying denied. The plain explanation is: the domain told the internet to deliver mail to that server, but the server says it does not handle mail for that address.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
When I need to rule out the sender side, I send a real test message and inspect the headers and authentication result. Suped's email tester is useful here because it checks how a message actually arrives, including authentication, domain match, and visible issues that a DNS-only lookup does not catch.
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 whether the server accepts that recipient domain or address.
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 means the server accepted the idea of a sender, but rejected the recipient because it did not treat the recipient as local or permitted. For a deeper explanation of nearby SMTP bounce patterns, the related guide on 550 relaying denied covers resolution steps for permanent bounces.
DNS and authentication checks
Do not stop at MX records if you own either side of the domain. Relay errors often appear during mail setup drift across MX, SPF, DKIM, DMARC, bounce domains, and custom return paths.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Use a domain health check to catch the obvious DNS and authentication faults around the domain. For ongoing domains, Suped's DMARC monitoring keeps the same work from turning into a once-a-quarter cleanup job. It brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, alerts, and deliverability signals into one operating view.
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 domains used by platforms still have working DNS and mail handling.
- SPF and DKIM: Confirm the sending platform is authorized and signing with the expected domain.
- DMARC match: Confirm the visible sender, envelope sender, and DKIM domain match the policy you expect.
When it is not your problem
A relaying denied bounce that comes back from an autoresponder can be a sign that the original sender has a broken bounce domain. This is common with cold outreach, abandoned marketing platforms, old customer-success systems, and migrated domains 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 original message used a return path that the sender cannot receive. That does not mean your autoresponder broke delivery. It means the reply path for the original sender is unhealthy.
A concise vendor note works best. Include the recipient address, MX host, SMTP transcript, and test time. Ask them to verify inbound routing before debating generic deliverability.
Evidence to send to a provider
Recipient tested: bounce-id@example.org MX tested: mx1.example.org SMTP stage: RCPT TO Remote response: 550 5.7.1 relaying denied Conclusion: MX host is not accepting mail for the domain.
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 it is your problem
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 allowlist | Relay admin |
Bad sender | Use valid domain | DNS owner |
SPF fail | Authorize source | DNS owner |
Sender-side fixes
The clean fix is to use the provider's submission endpoint, authenticate with the right account or token, use a verified sender domain, and keep SPF and DKIM matched to the domain in the visible From header. If a server requires IP-based relay permission, make sure the application sends from the IP range that the relay expects.
On self-managed mail systems, the fix usually lives in accepted domain, relay recipient, transport map, or virtual mailbox settings. On hosted systems, the equivalent is often called verified domain, custom return path, inbound routing, or domain ownership.
How Suped fits into the workflow
Suped will not repair someone else's broken MX server, but it reduces the uncertainty around your own domain. That matters because relaying errors often get mixed up with SPF failures, DKIM signing gaps, DMARC policy changes, blocklist or blacklist issues, and reputation problems.
- Automated detection: Suped surfaces authentication and routing-related issues, then gives practical steps to fix them.
- Real-time alerts: Sudden DMARC failures, sender changes, or policy risks get flagged before they become long-running incidents.
- Hosted SPF: Sender changes can be managed without repeatedly editing fragile DNS records.
- Unified monitoring: DMARC, SPF, DKIM, blocklist monitoring, hosted MTA-STS, and deliverability signals sit in one place.
- MSP support: Agencies and managed service providers can track many domains without switching between isolated tools.
For most teams, Suped is the stronger practical choice because it turns email authentication into an operating process. A one-off SMTP transcript answers why one relay failed. Ongoing monitoring answers whether your mail domain is healthy after the next sender is added or a platform changes bounce handling.
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
SMTP transcript
Each MX was tested to RCPT and produced the same result.
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 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 from Email Geeks says a dead destination domain, broken DNS, or unfinished service migration can produce this error.
2024-06-20 - Email Geeks
The practical answer
A relaying denied error means the receiving server refused to relay or deliver the message for that recipient. The most common real-world cause is that the destination domain's MX points at a server that has not been configured to accept mail for the domain.
Diagnose it by checking the exact recipient, looking up every MX, testing each MX to the RCPT TO stage, and recording the SMTP response. If the rejecting host is an MX for the recipient domain and still says it does not relay, the receiving side needs to fix DNS or accepted-domain routing. If your own app is using the wrong SMTP relay, fix authentication, relay permissions, sender identity, and domain authentication before sending again.
