Skip to content
Postfix Insights

Diagnose submission authentication failures in Postfix logs

When a mail client cannot send a message through your Postfix server, the reason often lies in the submission service logs. Users submit mail on ports 587 (STARTTLS) or 465 (implicit TLS) and must authenticate using SASL. This guide walks you through reading SASL authentication failures in the mail log, identifying the root cause, and distinguishing auth failures from relay-policy rejections.

Submission service, SASL, and where auth happens

Section titled “Submission service, SASL, and where auth happens”

Postfix does not directly authenticate users. Instead, it delegates SASL authentication to a backend service, typically Dovecot SASL or Cyrus SASL. When a client connects to the submission port (587 or 465), the smtpd daemon processes the connection and defers authentication to the configured SASL backend via a socket (usually /run/dovecot/auth-postfix for Dovecot).

Port 25 is for server-to-server delivery (SMTP relay) and does not require authentication. Ports 587 and 465 are for clients and require SASL. This is a critical distinction: port 25 failures are delivery issues, not auth issues. Auth failures appear on the submission ports only.

Postfix delegates SASL via two configuration parameters:

  • smtpd_sasl_type: Usually dovecot or cyrus.
  • smtpd_sasl_path: The socket path, such as /run/dovecot/auth-postfix.

You can verify these in your main.cf:

smtpd_sasl_type = dovecot
smtpd_sasl_path = /run/dovecot/auth-postfix

What a SASL authentication failure looks like

Section titled “What a SASL authentication failure looks like”

SASL failures appear as warnings from the smtpd daemon in the mail log. Here is the typical shape:

Jun 17 10:25:14 mail postfix/smtpd[12345]: warning: client.example.net[203.0.113.9]: SASL LOGIN authentication failed: Invalid user name or authentication type

or

Jun 17 10:25:20 mail postfix/smtpd[12356]: warning: client.example.net[203.0.113.9]: SASL PLAIN authentication failed: Invalid user name or authentication type

The log line includes:

  • Client hostname and IP (e.g., client.example.net[203.0.113.9]): The machine attempting to authenticate.
  • Mechanism (e.g., SASL LOGIN or SASL PLAIN): The authentication method offered by the client.
  • Failure reason (e.g., Invalid user name or authentication type): The reason from the SASL backend.

Repeated failures from the same IP in a short time span suggest a brute-force attack. A single failure from a user’s workstation suggests a misconfigured client or bad credentials.

Common causes of SASL authentication failures

Section titled “Common causes of SASL authentication failures”

1. Wrong username or password

Section titled “1. Wrong username or password”

The most common cause. The user entered incorrect credentials in their mail client. The log will show Invalid user name or authentication type.

Triage: Confirm the user’s username and password match the account in your SASL backend (usually the Dovecot user database). Have the user change their password and reconfigure their mail client.

2. SASL backend is down or unreachable

Section titled “2. SASL backend is down or unreachable”

If the socket at smtpd_sasl_path does not exist or the Dovecot auth service is stopped, Postfix cannot reach the backend. You will see auth failures with a system error message, such as:

Jun 17 10:25:30 mail postfix/smtpd[12357]: warning: client.example.net[203.0.113.10]: SASL PLAIN authentication failed: No such file or directory

or

Jun 17 10:25:31 mail postfix/smtpd[12358]: warning: client.example.net[203.0.113.11]: SASL LOGIN authentication failed: Connection refused

Triage: Check whether the Dovecot auth service is running:

Terminal window
systemctl status dovecot

Verify the socket exists and Postfix has read/write permissions:

Terminal window
ls -la /run/dovecot/auth-postfix

If the socket is missing or permissions are wrong, restart Dovecot:

Terminal window
systemctl restart dovecot

Check Dovecot logs for errors:

Terminal window
journalctl -u dovecot -n 20

3. Authentication required before STARTTLS

Section titled “3. Authentication required before STARTTLS”

If smtpd_tls_auth_only = yes (which is common for security), the server advertises AUTH only after a successful STARTTLS upgrade. If a client tries to authenticate before issuing STARTTLS, the server will reject it.

The log may show:

Jun 17 10:25:40 mail postfix/smtpd[12359]: warning: client.example.net[203.0.113.12]: SASL LOGIN authentication failed: Authentication not available

or simply the AUTH mechanism will not be advertised in the EHLO response.

Triage: Confirm your main.cf has:

smtpd_tls_auth_only = yes

Advise the user to enable STARTTLS in their mail client before attempting authentication. Most modern clients do this automatically on port 587. On port 465 (implicit TLS), the connection is encrypted from the start, so STARTTLS is not needed.

4. Mechanism mismatch

Section titled “4. Mechanism mismatch”

The client offers a mechanism (e.g., CRAM-MD5, DIGEST-MD5) that the server does not support, or vice versa. The log will show the mechanism the client tried:

Jun 17 10:25:50 mail postfix/smtpd[12360]: warning: client.example.net[203.0.113.13]: SASL CRAM-MD5 authentication failed: Authentication mechanism not available

Triage: Check your main.cf for the allowed SASL mechanisms:

Terminal window
grep smtpd_sasl_mechanism_filter /etc/postfix/main.cf

If you have restricted mechanisms (e.g., to PLAIN and LOGIN only), but a client insists on CRAM-MD5, the client must use a supported mechanism. The usual suspects are PLAIN and LOGIN. Enable both:

smtpd_sasl_mechanism_filter = plain, login

Then reload Postfix:

Terminal window
postfix reload

5. Account is disabled or does not exist

Section titled “5. Account is disabled or does not exist”

If the username exists but the account is disabled in Dovecot (e.g., the user has a disabledlogin flag), or if the account was deleted, the SASL backend will reject it:

Jun 17 10:26:00 mail postfix/smtpd[12361]: warning: client.example.net[203.0.113.14]: SASL PLAIN authentication failed: Unknown user or password incorrect

Triage: Verify the account exists in your user backend. For Dovecot, use:

Terminal window
doveadm user <username>

If the account does not appear, create it or restore it from backup. Check for disabled flags:

Terminal window
doveadm user -f '*' <username>

Look for fields like disabledlogin or enable set to no.

Triage workflow: is this an auth failure or a relay rejection?

Section titled “Triage workflow: is this an auth failure or a relay rejection?”

Not all mail-client errors are auth failures. A client that connects but is not authenticated will be told “Relay access denied” (DSN 5.7.1) when it tries to send a message to an external domain. This is not an auth failure; it is a relay-policy refusal.

SASL authentication failure (from smtpd):

Jun 17 10:25:14 mail postfix/smtpd[12345]: warning: client.example.net[203.0.113.9]: SASL LOGIN authentication failed: Invalid user name or authentication type

Relay access denied (from smtpd, usually after a message attempt):

Jun 17 10:26:15 mail postfix/smtpd[12346]: NOQUEUE: reject: RCPT from client.example.net[203.0.113.9]: 550 5.7.1 <user@remote.org>: Relay access denied; from=<sender@example.com> to=<user@remote.org>

The key difference: a SASL failure is logged during AUTH negotiation (early in the SMTP session). A relay rejection is logged when an unauthenticated or unallowed sender tries to send a message (RCPT command).

If the client shows “550 5.7.1 Relay access denied” but the user swears they authenticated, check whether:

  1. The user is on a network or IP range that is explicitly allowed to relay without auth (check mynetworks and permit_mynetworks).
  2. The user is behind a misconfigured relay or proxy that strips the AUTH header.
  3. The authentication succeeded, but an ACL rule is blocking the recipient or domain.

Using Postfix Insights to find and analyze submission auth failures

Section titled “Using Postfix Insights to find and analyze submission auth failures”

The mail log grows quickly, especially on a busy server. Postfix Insights indexes the same mail.log file and lets you search for SASL failures by client IP, username, or time range without grepping manually.

To find authentication failures:

  1. Open Postfix Insights.
  2. Search for SASL or authentication failed to surface all auth attempts and failures in a time window.
  3. Filter by client IP to spot patterns: one user (credentials issue) or many IPs (brute-force attack).
  4. Export or summarize the results to decide whether you need additional controls (e.g., rate limiting, fail2ban rules).

Postfix Insights also helps you correlate auth failures with delivery attempts from the same client, so you can see whether a client that failed auth multiple times later succeeded and sent mail.

However, dedicated brute-force protection is a job for tools like fail2ban. Postfix Insights helps you find and analyze the log evidence; fail2ban blocks the offending IPs. A typical setup combines both:

  • Postfix Insights: Search, triage, and understand auth-failure patterns.
  • fail2ban: Monitor the same mail.log and automatically block IPs with repeated AUTH failures.

Get started with Postfix Insights. The source code is at https://github.com/Xodus-CO/postfix-insights.

Quick checklist: diagnosing a client’s auth failure

Section titled “Quick checklist: diagnosing a client’s auth failure”
  1. Find the failure in the log: Search for the client’s hostname or IP and SASL or authentication failed.
  2. Check the SASL backend: Verify Dovecot (or Cyrus) is running and the socket is reachable.
  3. Verify the user exists: Use doveadm user or your SASL backend’s query tool to confirm the account is active.
  4. Check TLS requirement: Confirm smtpd_tls_auth_only is set correctly and the client is using STARTTLS or port 465.
  5. Spot patterns: Is it one user or many IPs? One user suggests bad credentials; many IPs suggests an attack.
  6. Distinguish auth from relay: If the client says “Relay access denied,” it is not an auth failure; the client either did not authenticate or an ACL rule blocked the recipient.

References

Section titled “References”