GMX / WEB.DE "554 Transaction failed / Reject due to policy restrictions" e "invalid DNS PTR resource record": solución

Qué significa

GMX y WEB.DE son dos servicios de email muy populares en Alemania, ambos gestionados por United Internet (que también gestiona mail.com y el correo de 1&1 / IONOS). Sus servidores de recepción son estrictos. Cuando rechazan tu servidor, el rebote suele tener varias líneas que empiezan por 554-. Normalmente se parece a uno de estos:

554-Transaction failed
554-Reject due to policy restrictions.
554 For explanation visit https://...

554-No SMTP service
554-invalid DNS PTR resource record, IP=203.0.113.10
554 Reject due to policy restrictions.

Algunos rebotes, sobre todo de WEB.DE, dicen Requested action not taken: mailbox unavailable junto con una nota sobre el registro PTR. Ese texto parece decir «esta dirección no existe», pero cuando menciona la IP o el registro PTR, el problema está en tu servidor, no en el buzón.

El rebote suele incluir un enlace a las páginas para postmasters de GMX o WEB.DE, que explican cada caso. Abre el enlace que aparece en tu propio rebote.

Por qué ocurre

Problemas de DNS inverso (PTR)

Es la causa más frecuente. Un registro PTR es el nombre asociado a una dirección IP, como una guía telefónica al revés. GMX y WEB.DE esperan que:

• exista un registro PTR para tu IP de envío;
• ese nombre apunte de vuelta a la misma IP (DNS inverso confirmado en sentido directo);
• sea un nombre de servidor real, como mail.yourdomain.com, y no uno genérico como 203-0-113-10.dynamic.isp.example;
• el nombre que tu servidor anuncia en su saludo (HELO o EHLO) sea un nombre de host real y resoluble, idealmente el mismo que el PTR.

Reputación y política

"Reject due to policy restrictions" sin mención al PTR suele apuntar a la reputación: la IP está en una lista de bloqueo, envía desde una conexión doméstica, es completamente nueva, o el contenido y las quejas parecen spam. La falta de SPF, DKIM o DMARC también juega en tu contra.

Cómo comprobarlo

1. Haz una prueba con Delivmail. Desde el mismo servidor, envía un email a la dirección única de la página de inicio (/). El informe muestra tu IP de envío, su nombre PTR, si ese nombre apunta de vuelta a la IP y el nombre HELO que usó tu servidor. También comprueba las listas negras y la autenticación.
2. Comprueba las listas negras. Introduce la IP en /blacklists.
3. Comprueba tu dominio. Usa /domain-scanner para confirmar que SPF y DMARC están publicados y son válidos.
4. Abre el enlace del rebote a la página para postmasters de GMX o WEB.DE para ver tu caso concreto.

Cómo solucionarlo

1. Configura un registro PTR. El PTR lo controla el propietario de la IP, normalmente tu empresa de hosting o tu proveedor de VPS, no el DNS de tu dominio. Busca «reverse DNS» o «rDNS» en su panel de control, o pregunta a su soporte. Configúralo con un nombre como mail.yourdomain.com.
2. Crea el registro A correspondiente. En el DNS de tu dominio, haz que mail.yourdomain.com apunte a la misma IP.
3. Configura el nombre HELO. Configura tu servidor de correo para que salude con ese mismo nombre. En Postfix es myhostname. Muchos paneles de control y aplicaciones tienen un ajuste «hostname» o «HELO».
4. No envíes desde una conexión doméstica. Usa en su lugar el servidor de salida de tu proveedor o un servicio de envío.
5. Autentica con SPF, DKIM y DMARC.
6. Resuelve cualquier entrada en listas de bloqueo después de eliminar su causa.
7. Si todo está limpio y el rechazo continúa, usa el formulario de contacto de las páginas para postmasters de GMX o WEB.DE, con el rebote completo y tu IP.

Comprueba que está solucionado

Los cambios de PTR pueden tardar desde unos minutos hasta unas horas en ser visibles. Haz una nueva prueba con Delivmail: la sección de DNS inverso debería mostrar un nombre PTR que apunta de vuelta a tu IP, y el HELO debería ser un nombre de host real. Después vuelve a enviar a la dirección de GMX o WEB.DE que rebotó. Si la causa era la reputación, cuenta con unos días de envíos limpios antes de que se acepte todo.