Mailybox
check dmarcdiagnose a bounce
Home / Email errors / generic
generic error

554 5.7.1 Relay Access Denied — Postfix and Other MTAs

The receiving server refused to accept mail for a domain it is not responsible for and the client was not authenticated, so it would have had to relay the message onward.

Diagnose your exact bounce Email Dependency Discovery

What the bounce says

Exact wording as it appears in the rejection or NDR. Placeholders such as x.x.x.x and example.com stand for your own address and domain.

554 5.7.1 <user@example.com>: Relay access denied

554 5.7.1 <example.com>: Relay access denied

550 5.7.1 Relaying denied

Relay access denied is the receiving server saying: this recipient is not mine, you are not authenticated, and I will not forward mail for you. It is the correct behaviour of a properly configured server; the problem is on the client’s side of the conversation.

Reviewed 2026-09-08. Provider wording and requirements change; the provider reference below is authoritative.

Most common causes

  • The recipient domain is not hosted on this server and the client did not authenticate
  • The client is using the wrong outgoing server
  • SMTP authentication failed or was not attempted
  • The server’s relay restrictions do not include the client network

What to verify next

  1. Confirm the client uses its own provider’s submission server with authentication
  2. If you run the server, check relay_domains, mynetworks and SASL settings
  3. Verify the recipient domain’s MX actually points here if mail is expected
  4. Capture the SMTP session to see whether AUTH happened

Two situations

A user’s mail client is pointed at the wrong outgoing server, or at the right one without authentication, and tries to send to an external address. Or an application relays through a server that does not recognize its network.

If you are the recipient and see this in your own logs from external senders, someone is trying to use your server as a relay and it is correctly refusing.

  • Client: wrong server or no authentication.
  • Application: relay restrictions do not include it.
  • Seen inbound: your server is refusing abuse correctly.

For users

Configure the client with the provider’s submission server on port 587 with authentication and STARTTLS. The username is normally the full address.

For administrators

In Postfix, relay is permitted for mynetworks and for authenticated SASL clients; check both. Do not add wide ranges to mynetworks to make an application work — give it credentials instead.

Best diagnostic path

Live analysis

Mail Failure Doctor

Classify the complete rejection and preserve provider-specific diagnostic context.

Open analysis → Live analysis

Email Dependency Discovery

Map applications and devices that depend on a relay or submission path before changing it.

Open analysis → Live analysis

Email Infrastructure Digital Twin

Map the domain’s public mail infrastructure and provider relationships before remediation.

Open analysis →

Known limits

  • Wording differs between MTAs; Postfix and Exim phrase it slightly differently.
  • The rejection does not say which restriction rule matched; server logs do.

Common questions

Why does it work on the office network?

The office range is in mynetworks. Outside it, the client must authenticate.

The recipient domain is hosted here.

Then the server does not know it. Check relay_domains, virtual domains and the MX record.

Is this a spam block?

No. It is relay control. Authentication or correct server settings resolve it.

Why the exact message matters

The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.

Provider reference

For the provider-defined meaning and current requirements, review Postfix SMTP relay and access control.