DIAGNOSTIC PLAYBOOK
Relay access denied: inspect the submission route
A relay-denied response often means the contacted server will not forward the requested message under the current session or destination policy. It is not automatically a public DNS authentication failure.
HealthCheck Email editorial team · · Examples are illustrative
How to investigate
- Identify whether the application contacted a submission server or a destination MX.
- Check the supported port, TLS mode, account authentication and authorized sender settings.
- Correct the application route or credentials using the mail provider's instructions and send a controlled test.
What this looks like
ILLUSTRATIVE EXAMPLE
An application tries to submit outbound mail directly through a server intended only to receive inbound mail. The server refuses relay access.
A mistake to avoid
Do not weaken relay restrictions globally. Configure the intended authenticated submission path.
Keep the result in context
A successful handoff, a delivered event and an inbox placement are different observations. Record the receiving provider, send time, SMTP response and affected stream before comparing results. DNS fixes address authentication or routing; they cannot establish consent or guarantee placement.
Take the next step
Use the related check to gather evidence, then compare it with the affected message or service. Keep the result and time with your notes so a later change can be distinguished from the original problem.
Sources and further reading
The protocol references below explain the underlying behavior. Your sending or DNS provider supplies the account-specific settings for its service.