Postfix "553 5.7.1 Sender address rejected: not owned by user": cómo solucionarlo

Qué significa

Tu servidor Postfix comprueba que la persona que ha iniciado sesión tiene permiso para enviar con la dirección de remitente que usa. Cuando no lo tiene, rechaza el mensaje:

553 5.7.1 <info@yourdomain.com>: Sender address rejected: not owned by user john@yourdomain.com

Aparece un mensaje relacionado cuando alguien usa una de tus direcciones sin haber iniciado sesión:

553 5.7.1 <info@yourdomain.com>: Sender address rejected: not logged in

Es una protección, no un fallo: impide que un usuario (o una contraseña robada) envíe haciéndose pasar por otra persona. La solución es indicar a Postfix quién puede usar cada dirección, o enviar con la cuenta correcta.

Por qué ocurre

La comprobación viene de la restricción reject_sender_login_mismatch (o de sus variantes reject_authenticated_sender_login_mismatch y reject_known_sender_login_mismatch). Compara dos cosas:

• el remitente del sobre (la dirección MAIL FROM que indica el programa de correo, no siempre la cabecera From visible), y
• el nombre de usuario usado para la autenticación SMTP.

Postfix busca el remitente en la tabla definida por smtpd_sender_login_maps. Si el usuario no figura como propietario, rechaza el mensaje. Situaciones típicas:

• Un usuario envía desde una dirección compartida o un alias (info@, sales@) que no está asociado a su usuario.
• Una web, una impresora o un script inicia sesión con una cuenta pero envía con otra dirección.
• El usuario es john, pero la tabla indica john@yourdomain.com (o al revés).
• Se editó la tabla pero no se ejecutó postmap, así que Postfix sigue leyendo la versión antigua.
• Una aplicación define un remitente del sobre (dirección de rebote) distinto de la dirección From.

Cómo comprobarlo

1. Lee el registro de correo para ver el remitente y el usuario exactos:

   grep "not owned by user" /var/log/mail.log | tail

2. Mira la configuración activa:

   postconf smtpd_sender_login_maps smtpd_sender_restrictions
   postconf -M submission/inet

   El segundo comando muestra las anulaciones -o del servicio submission (puerto 587) en master.cf, donde suele definirse esta restricción.
3. Consulta directamente la tabla:

   postmap -q info@yourdomain.com hash:/etc/postfix/sender_login

   Muestra los usuarios autorizados para esa dirección, o nada.
4. Reprodúcelo con swaks:

   swaks --server mail.yourdomain.com:587 --tls \
     --auth LOGIN --auth-user john@yourdomain.com \
     --from info@yourdomain.com --to you@example.com

Cómo solucionarlo

Autoriza al usuario a usar la dirección

Edita la tabla de remitentes, un remitente por línea seguido de los usuarios autorizados separados por comas:

# /etc/postfix/sender_login
john@yourdomain.com     john@yourdomain.com
info@yourdomain.com     john@yourdomain.com, mary@yourdomain.com
@yourdomain.com         admin@yourdomain.com

La última línea permite a admin@yourdomain.com enviar con cualquier dirección del dominio; úsala con cuidado. Después reconstruye la tabla y recarga:

postmap /etc/postfix/sender_login
systemctl reload postfix

Asegúrate de que main.cf apunta a ella:

smtpd_sender_login_maps = hash:/etc/postfix/sender_login

Si tus usuarios están en una base de datos (MySQL, PostgreSQL, LDAP), la tabla es una consulta; añade allí el permiso del alias. Los paneles de control y los paquetes de servidor de correo suelen ofrecerlo como permiso "send as" (enviar como) o de alias para cada buzón.

O inicia sesión con la cuenta correcta

Para una web o un dispositivo, la solución más sencilla suele ser iniciar sesión con la cuenta propietaria de la dirección, o crear un buzón para la dirección desde la que envía.

Corrige el remitente del sobre de las aplicaciones

Si el From visible es correcto pero el registro muestra otro remitente, la aplicación define un remitente del sobre distinto. Ponle una dirección que pertenezca al usuario (en PHPMailer, $mail->Sender; en nodemailer, la opción envelope). Consulta Return-Path, remitente del sobre y From.

No te limites a quitar la restricción

Quitar reject_sender_login_mismatch hace desaparecer el error, pero permite a cualquier usuario enviar como cualquier otro. Tampoco uses la dirección de los visitantes como remitente en los formularios de contacto (consulta emails de formulario de contacto enviados "From" el visitante). Si el error es "Relay access denied", consulta 554 5.7.1 Relay access denied.

Comprueba que está solucionado

Ejecuta el mismo comando swaks: debe terminar con 250 2.0.0 Ok: queued. Después envía desde la aplicación o el cliente de correo real a la dirección única de la página de inicio de Delivmail y comprueba en el informe que SPF, DKIM y DMARC pasan para la dirección de remitente. Por último, reenvía el mensaje que se rechazó.