[ Headers & delivery errors ]

SMTP relay denied: find the rejected route or permission

Use the full SMTP response, stage and intended provider route to distinguish submission authentication, sender permission, connector attribution and recipient-scope failures.

By the EmailAuth research team · 6 min read

[ Key points ]

  • Preserve the basic reply, enhanced code, full text, responding host and transaction stage.
  • A 4xx response is not necessarily authentication-related, and a 5xx response is not an invitation to blind retries.
  • Correct only the evidenced permission through an approved owner and retest a bounded transaction.
On this page
  1. Key points
  2. Read relay denial as a permission question
  3. Separate retry class from diagnosis
  4. Match the endpoint to its intended role
  5. Use provider diagnostics narrowly
  6. Trace the rejected authority with a fictional incident
  7. Keep authorization and deliverability separate
  8. Retest one bounded transaction
  9. Role perspectives
  10. Glossary
  11. Primary sources and evidence scope

Read relay denial as a permission question

A relay-denied response means the receiving service did not permit the attempted operation under the observed conditions. It does not, by itself, identify a bad password, an SPF defect or a missing mailbox. Before changing anything, determine which service rejected which SMTP step for which recipient. The exact endpoint and response are more useful than an application’s shortened “mail failed” notification.

Preserve the complete basic SMTP reply, enhanced status code if present, diagnostic text, responding host, timestamp and command stage. Record whether the rejection occurred during authentication, MAIL FROM, RCPT TO or after message data. Keep provider request identifiers that can support an authorized investigation, but remove secrets and unnecessary message content from shared tickets.

Separate retry class from diagnosis

The first SMTP reply digit supplies broad action semantics. A 4xx reply is a transient negative completion; a 5xx reply is a permanent negative completion for the attempted request. Neither class identifies the rejected permission. Enhanced codes add class, subject and detail, but their meaning still needs the full diagnostic and provider context. RFC 5321, section 4.2.1 and RFC 3463, section 2.

Do not repeatedly resubmit an unchanged permanently rejected transaction. A transient response also does not justify immediate repeated attempts; use the responsible mail system’s bounded retry strategy while investigating. A 4xx condition can concern routing, resources or another temporary problem rather than authentication. Keeping the stage and complete reply avoids turning every failure into a password-reset request.

Match the endpoint to its intended role

An application using a mailbox submission service must meet that service’s submission requirements. A connector-based relay must match the organization’s authorized connector conditions. A direct inbound route may accept local recipients without granting permission to relay elsewhere. Microsoft’s current application-mail guide distinguishes these routes; its Direct Send option does not provide delivery to external recipients through the tenant. Microsoft application-mail setup.

Construct a short route record before editing a setting: configured host, actual responding host, port, source network, authentication mode, sender identities and recipient category. Compare it with the intended design. Do not try arbitrary public SMTP servers to see which one accepts the message. A reachable server is not an authorized relay, and successful acceptance would not legitimize using it.

Use provider diagnostics narrowly

Microsoft’s troubleshooting page identifies enhanced code 5.7.64 with TenantAttribution and Relay Access Denied, and also discusses 4.4.62 for mail sent to the wrong region. In that documented context, a changed public IP or certificate can prevent tenant attribution. The same page associates 5.7.60 with Send As permission. These examples help select an investigation branch; they do not mean every 5.7.x response has the same cause. Microsoft device and application troubleshooting.

That troubleshooting page is dated June 2025 and contains older authentication workarounds. Do not follow suggestions to disable MFA or security defaults as a general repair. Reconcile configuration with the newer setup guidance and the organization’s security policy. This draft does not prescribe a Basic-authentication retirement date, assume a feature is enabled, or claim that a current tenant accepts a legacy method.

Trace the rejected authority with a fictional incident

Imagine a fictional application whose external notifications stop after a network cutover. Its intended design uses an IP-based connector. The investigation packet contains a relay-attribution diagnostic, but no new public-source observation. A useful next step is to have the network owner and mail administrator compare the actual egress identity with the authorized connector, using approved read-only evidence. The example does not establish that any address changed or that modifying a connector is permitted.

Now change the fictional facts: internal recipients work, the application has never had a connector, and only external recipients fail. That points toward a route-scope question rather than the same network-change diagnosis. A third case could have successful submission authentication but a sender-permission error for a different From identity. The diagnostic branches must remain separate so a convenient fix in one case does not widen permissions in another.

Keep authorization and deliverability separate

SPF publication describes permitted sending infrastructure for an SPF identity; it does not instruct an arbitrary SMTP service to relay. Similarly, DKIM signing and DMARC alignment do not grant mailbox Send As permission. Fixing the wrong layer can leave the original rejection unchanged while creating new exposure. Use the route-to-requirement map to identify the owner of the rejected permission before proposing a narrowly scoped correction. RFC 7208, sections 2.4 and 4.1.

The correction might involve an approved endpoint, an authorized sender identity or an administrator-reviewed connector match. It should never be “allow everyone,” publish credentials, disable protective policy without review, or resend through an unrelated public relay. Record the old state, intended permission and expected recipient scope before any authorized change.

Retest one bounded transaction

Use an approved test recipient and a recognizable non-sensitive message after the relevant change has been authorized. Retain the full replies and downstream disposition. If the server gives a positive completion reply after message data, it accepts transport responsibility; that is different from proof of inbox delivery. If the connection closes before a conclusive final reply, establish the outcome before generating another application message, because delivery may be uncertain. RFC 5321, sections 4.2.5 and 6.1.

A route-to-requirement map with current provider evidence and a controlled test message. This exact catalogue requirement remains open. No permission, connector or credential has been inspected or changed, and no relay probe or test message was sent. The diagnostic branches are proposed checks, not an account-specific result.

[ Takeaway ]

Find the rejected authority first; changing SPF or repeatedly resending cannot grant relay permission.

[ By role ]

What this means for you

Choose your role for practical next steps.

Support analyst

Keep the complete diagnostic

An abbreviated application error often hides the distinction that selects the investigation.

Next steps

  1. Capture host, time, queue ID, full reply and SMTP stage.
  2. Separate provider documentation from an actual observed account result.

Mail administrator

Own the specific permission

The safest correction is the smallest authorized change to the demonstrated cause.

Next steps

  1. Compare the intended route with actual sender and connector eligibility.
  2. Avoid broad relay allowances or changes to unrelated authentication policy.

Application engineer

Prevent duplicate recovery attempts

The application must not compete with a transport queue that still owns the message.

Next steps

  1. Check queue status before creating replacements.
  2. Use a unique harmless test message and retain the final outcome.

[ FAQs ]

Frequently asked questions

Does relay denied always mean the password is wrong?

No. The rejected condition may concern endpoint role, connector attribution, sender permission or recipient reach. Preserve the command stage and full response before selecting a branch.

Is every 4xx failure safe to retry immediately?

No. Temporary classification does not remove the need for delayed, bounded retry behavior. The cause may be routing, capacity or another condition rather than authentication.

What does 5.7.64 establish in the Microsoft example?

The cited troubleshooting guidance associates it with tenant attribution and relay access denial. It selects an investigation area, not proof that a particular connector or IP is wrong.

How does Send As differ from successful login?

Successful authentication establishes a submitting identity; sender authorization determines whether it may use the requested sender identity. Preserve both facts in the incident record.

Will an SPF update grant SMTP relay access?

No. SPF expresses authorization for its checked identity; it does not grant an unrelated SMTP service permission to relay a transaction.

Should I try another public relay to bypass the rejection?

No. Use only an authorized sending route. Reachability or unexpected acceptance does not establish permission to use a third party’s service.

What if the connection drops after message data?

The final outcome may be uncertain if no conclusive response was received. Investigate the queue and server evidence before creating a new application message that could duplicate delivery.

What proves the issue is resolved?

An approved route/permission correction, full replies from a bounded controlled transaction, and the resulting delivery evidence. No such actual route or message test accompanies this draft.

[ Sources ]

Sources

  1. Microsoft: Set up application mail using Microsoft 365 or Office 365
  2. Microsoft: Fix application and device email issues
  3. RFC 3463: Enhanced Mail System Status Codes
  4. RFC 5321: Simple Mail Transfer Protocol
  5. RFC 7208: Sender Policy Framework

[ Glossary ]

Glossary

Relay permission
Authorization for a server to accept and forward a message beyond its local delivery responsibility.
Enhanced status code
A dotted class.subject.detail status representation that supplements, rather than replaces, the full diagnostic.
Tenant attribution
The provider’s association of a connection or message with the intended tenant, relevant to the cited Microsoft relay errors.
Send As permission
Authorization for a submitting identity to send using another sender identity within the provider’s rules.
Uncertain completion
A delivery attempt whose final acceptance outcome is not established, for example after a connection loss before the concluding reply.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base