// cómo solucionarlo
"450 4.1.8 Sender address rejected: Domain not found" / "553 5.1.8 Domain of sender address does not exist": solución
El receptor no ha encontrado tu dominio de remitente en el DNS. Suele ser una errata, un dominio local como .local o un dominio sin registro A ni MX.
Qué significa
El servidor receptor ha buscado el dominio de tu dirección de remitente y no lo ha encontrado en el DNS. Rechaza el correo de un dominio que parece no existir, porque nunca podría enviarle una respuesta ni un rebote. El mensaje suele parecerse a uno de estos:
450 4.1.8 <user@yourdomain.com>: Sender address rejected: Domain not found 553 5.1.8 <user@yourdomain.com>... Domain of sender address user@yourdomain.com does not exist
El primero viene de Postfix. La versión 450 es temporal, así que tu servidor lo reintentará, pero seguirá fallando hasta que se pueda encontrar el dominio. La versión 553 es definitiva.
La dirección de remitente que se comprueba aquí es el remitente del sobre, también llamado Return-Path o MAIL FROM. No siempre es la dirección «From» que ve la gente. Las apps y los servidores suelen definirla automáticamente, por ejemplo www-data@server1.local.
Por qué ocurre
- Un nombre local o interno. El remitente del sobre usa un dominio que solo existe dentro de tu red, como
.local,.lan,.internalo el nombre del servidor a secas (root@localhost). - Una errata en la dirección de remitente, como
yourdomian.com. - El dominio no tiene registro A ni registro MX. Algunos receptores exigen al menos uno de los dos para el dominio del remitente.
- El dominio ha caducado o se ha eliminado su alojamiento DNS.
- Un subdominio sin registros, como
bounce.yourdomain.comusado por una herramienta, que nadie ha creado en el DNS. - Problemas de DNS: los servidores de nombres de tu dominio no responden, o responden mal. En ese caso es habitual el código temporal
450.
Cómo comprobarlo
- Lee el rebote. La dirección exacta entre los signos < > es la que se ha comprobado. Fíjate bien en su dominio.
- Haz una prueba con Delivmail. Envía un email desde la misma app o servidor a la dirección única de la página de inicio (
/). El informe muestra el remitente del sobre (Return-Path) y la dirección From, para que veas qué dominio usa realmente tu app. - Escanea el dominio en
/domain-scannerpara ver sus registros MX y si responde. - Comprueba el registro del dominio en
/whoispara asegurarte de que no ha caducado.
Cómo solucionarlo
Si el dominio es local o incorrecto
- Define una dirección de remitente real en un dominio que te pertenezca, por ejemplo
noreply@yourdomain.com. - En Postfix, configura
myoriginymyhostnamecon nombres reales (por ejemployourdomain.comymail.yourdomain.com), o reescribe las direcciones locales consender_canonical_maps. - En PHP o en una web, define explícitamente el remitente del sobre (la opción
-fdemail(), o el campo «Return-Path» o «Sender» de tu librería o plugin de correo). - En las apps y dispositivos, busca un ajuste de «dirección de remitente» o «dirección From» y usa una dirección real.
Si el dominio es real
- Asegúrate de que tiene un registro MX (adonde van las respuestas) y, si es posible, un registro A.
- Si una herramienta usa un subdominio de rebote personalizado, crea los registros que te pide (a menudo un CNAME).
- Renueva el dominio si ha caducado y comprueba que sus servidores de nombres responden.
Usar un dominio real también te permite configurar SPF, DKIM y DMARC para él, algo que de todos modos necesitarás para una buena entregabilidad.
Comprueba que está solucionado
Después de cualquier cambio DNS, espera un poco a que se propague (normalmente menos de una hora). Haz una nueva prueba con Delivmail desde la misma app: el Return-Path debería mostrar ahora tu dominio real, y SPF debería comprobarse con él. Después vuelve a enviar el email que rebotó, o deja que tu servidor reintente los mensajes en cola.
Comprueba que está solucionado
Un cambio de DNS puede tardar de unos minutos a unas horas. Después, envía un nuevo email de prueba o vuelve a escanear tu dominio.
Guías relacionadas
- Tu dominio no tiene registro SPFTu dominio no indica qué servidores pueden enviar emails en su nombre. Añade un registro TXT y los receptores podrán distinguir tus emails reales de los falsos.
- Error SPF: demasiadas consultas DNS (permerror)SPF permite como máximo 10 consultas DNS. Por encima, todo el registro se rompe y los receptores lo consideran no válido. Así puedes aligerarlo.
- Varios registros SPF en un mismo dominioUn dominio solo debe tener un registro SPF. Con dos o más, SPF falla en todos los emails. Únelos en una sola línea.
- SPF falla: el servidor de envío no está autorizadoTu dominio tiene un registro SPF, pero el servidor que envió tu email no está en él. Averigua qué servicio envió el email y añádelo.
- Tus emails no tienen firma DKIMDKIM añade una firma digital que demuestra que un email viene de verdad de tu dominio. Actívala en tu proveedor de correo y publica su clave en el DNS.