Tutoriales de VPS
Correo autogestionado en VPS que cae en spam (2026): solución de problemas de SPF, DKIM, DMARC, PTR y registros de rebotes
Que tu servidor de correo autogestionado en VPS pueda enviar correo no significa que llegue a la bandeja de entrada. Gmail, Outlook y Yahoo revisan a la vez SPF, DKIM, DMARC, PTR/rDNS, HELO, reputación de IP, tasa de rebotes y cadencia de envío. Este artículo sigue un orden real de diagnóstico: primero revisa los registros de rebotes, luego la autenticación DNS, después confirma PTR y el puerto 25, y por último decide si es un problema de configuración, de reputación de IP o si conviene cambiar a un SMTP relay.
Lo más frustrante del correo autogestionado no es "no poder enviar", sino cuando SMTP indica que el mensaje se envió, pero el destinatario no lo recibe o va directo a spam.
Muchas personas ya han montado Docker Mailserver, Postfix/Dovecot, Mailcow o Poste.io siguiendo tutoriales, y han configurado SPF, DKIM y DMARC, pero la entrega a Gmail y Outlook sigue siendo inestable. El problema es que la entrega de correo no termina con "poder conectarse al puerto 25": el receptor también revisa tu identidad, reputación de IP, DNS inverso, comportamiento de envío e historial de quejas.
Este artículo no trata de cómo instalar un servidor de correo. Para la instalación, consulta:
Este artículo aborda solo una pregunta: por qué los correos enviados desde un buzón autogestionado caen en spam o rebotan, y en qué orden hay que diagnosticarlo.
No empieces cambiando el SPF. Primero confirma en cuál de estos casos estás:
- Rebote directo: recibes un bounce con cadenas como
550,5.7.1,policy,SPF fail,PTR required; - El destinatario lo aceptó, pero cayó en spam: los registros SMTP parecen exitosos, Gmail/Outlook lo recibieron, pero no llega a la bandeja de entrada;
- Entrega retrasada: en los registros aparecen
deferred,temporarily rejected,rate limited, y puede tener éxito más tarde.
Estos tres casos tienen causas distintas.
Los rebotes suelen ser errores duros: prioriza la autenticación DNS, el PTR y las listas negras; caer en spam suele ser un problema de reputación y contenido; la entrega retrasada suele deberse a límites de frecuencia, reputación, greylisting o políticas temporales.
Empieza revisando los registros de correo. Rutas habituales en Debian/Ubuntu:
sudo tail -n 200 /var/log/mail.log
Si usas Docker Mailserver:
docker logs mailserver --tail=200
Cola de Postfix:
postqueue -p
Ver los detalles de la cola de un mensaje concreto:
postcat -vq QUEUE_ID
Actúa solo después de ver el código de error específico; no corrijas a ciegas.
El SPF le dice al receptor qué servidores pueden enviar correo en nombre de tu dominio.
Primero revisa el DNS:
dig TXT example.com +short
Un SPF mínimo para correo autogestionado podría verse así:
v=spf1 mx -all
O indicar explícitamente la IP:
v=spf1 ip4:203.0.113.10 -all
Errores comunes:
- Existen dos registros
v=spf1para el mismo dominio; - Olvidar añadir la IP del VPS;
- Añadir muchos
include, superando el límite de 10 consultas DNS del SPF; - Usar siempre
~ally no endurecerlo nunca; - La aplicación envía en realidad a través de un servicio de terceros, pero el SPF no incluye ese servicio.
Nota: el SPF mira el envelope sender / Return-Path, no necesariamente el From que ve el usuario. Muchos fallos de DMARC son en realidad casos en los que el SPF pasó pero no se alineó con el dominio del From.
El DKIM añade una firma al correo. El receptor usa la clave pública en DNS para verificar que el mensaje no ha sido alterado.
Busca DKIM-Signature en el correo original y verás algo como:
s=mail; d=example.com;
Aquí s=mail es el selector. Consulta el DNS:
dig TXT mail._domainkey.example.com +short
Errores comunes:
- El selector en el correo es
mail, pero el DNS lo publica endefault._domainkey; - La clave pública DKIM se copió de forma incompleta;
- El proveedor de DNS trunca los registros TXT largos;
- Se cambió la clave DKIM del servidor, pero el DNS sigue con la clave pública antigua;
- No se habilitó DKIM para todos los servicios de envío.
Después de enviar a Gmail, haz clic en "Mostrar original" y comprueba si Authentication-Results contiene:
dkim=pass
spf=pass
dmarc=pass
Si el DKIM falla, no te preocupes todavía por el texto del contenido: la identidad no está verificada y la probabilidad de llegar a la bandeja de entrada es muy baja.
El DMARC se construye sobre SPF y DKIM. Le importa si el dominio del From que ve el usuario está alineado con un dominio que pasó la verificación SPF o DKIM.
Consulta el DMARC:
dig TXT _dmarc.example.com +short
Al empezar el diagnóstico, se recomienda usar:
v=DMARC1; p=none; rua=mailto:[email protected]
Cuando hayas confirmado que todas las fuentes de envío funcionan correctamente, sube gradualmente a:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Solo entonces considera:
v=DMARC1; p=reject; rua=mailto:[email protected]
No pases directamente a p=reject. Si todavía tienes formularios web, sistemas de monitorización, servicios de correo de terceros o notificaciones de servicios Git enviando correo, rechazar sin haberlos mapeado antes puede tumbar también tu propio correo legítimo.
El DNS inverso PTR es uno de los requisitos duros del correo autogestionado.
Consulta la IP de tu VPS:
dig -x 203.0.113.10 +short
El resultado ideal debería devolver tu nombre de host de correo, por ejemplo:
mail.example.com.
Luego revisa la resolución directa:
dig A mail.example.com +short
Debería resolver a la misma IP.
Esto se llama DNS inverso confirmado por reenvío (forward-confirmed reverse DNS). Muchos receptores revisan esta señal.
El PTR no se configura en Cloudflare DNS ni en el panel DNS de tu dominio. Debe configurarse en la consola del proveedor del VPS, o abriendo un ticket para que el proveedor lo cambie.
Errores comunes:
- El PTR está vacío;
- El PTR apunta al nombre de host predeterminado del proveedor;
- El PTR apunta a
mail.example.com, peromail.example.comno tiene registro A; - El nombre de host HELO/EHLO no coincide con el PTR;
- Varios dominios comparten un servidor de correo, pero las identidades no están unificadas.
Consulta el nombre de host en Postfix:
postconf myhostname
postconf myorigin
Si tu servidor se anuncia como vps123.provider.com pero el From del correo es example.com, tu reputación se verá muy afectada.
Muchos proveedores de nube bloquean el puerto 25 saliente por defecto. Poder iniciar sesión en tu cliente de correo localmente no significa que el servidor pueda entregar hacia fuera.
Prueba contra el MX de Gmail:
nc -vz gmail-smtp-in.l.google.com 25
Si da timeout o se rechaza, puede que el proveedor haya bloqueado el puerto 25.
También puedes usar telnet:
telnet gmail-smtp-in.l.google.com 25
Si el puerto 25 está bloqueado, normalmente solo hay tres opciones:
- Abrir un ticket para solicitar el desbloqueo;
- Cambiar a un proveedor de VPS que permita correo saliente;
- Usar un SMTP relay, como Amazon SES, Mailgun, SendGrid o Postmark.
No uses 587/465 como sustituto de la entrega entre servidores por el puerto 25. 587/465 son para el envío de clientes, no un reemplazo de la entrega normal MTA a MTA.
Si el DNS es correcto y el PTR también, pero el correo sigue siendo rechazado, el siguiente paso es revisar la reputación de la IP.
Primero revisa las RBL/DNSBL habituales. Puedes usar herramientas en línea o consultar algunas listas directamente:
dig 10.113.0.203.zen.spamhaus.org A
Aquí la IP debe escribirse al revés. Por ejemplo, 203.0.113.10 se convierte en 10.113.0.203.
Opciones más prácticas:
- MxToolbox blacklist check;
- Spamhaus;
- Google Postmaster Tools;
- Microsoft SNDS / JMRP.
Revisa la IP en cuanto compres un VPS nuevo. Ya hemos escrito sobre esto antes:
Si la IP ya está en una lista negra principal, no pierdas el tiempo trasteando con Postfix. Primero mira si puedes cambiar la IP, obtener un reembolso o cambiar de proveedor. Algunos ASN de VPS baratos se abusan a largo plazo, y aunque tu configuración sea perfecta, llegar a la bandeja de entrada de Gmail puede ser muy difícil.
Si el destinatario ya aceptó el correo pero cae en spam, significa que la autenticación técnica puede ser solo "suficiente" y que la reputación aún no está establecida.
Revisa en este orden:
- Si
spf/dkim/dmarcen el original de Gmail pasa todo; - Si el dominio del From está alineado con el
d=del DKIM; - Si PTR, HELO y el registro A son coherentes;
- Si una IP nueva está enviando mucho correo de inmediato;
- Si se envía demasiado correo a direcciones inexistentes, provocando muchos rebotes;
- Si el contenido es todo imágenes, tiene demasiados enlaces cortos o dominios de enlace incoherentes;
- Si se mezcla correo de marketing con correo transaccional;
- Si Google Postmaster Tools muestra baja reputación.
No hagas envíos masivos desde una IP nueva de inmediato. Empieza con volumen bajo y correo con interacción real, y aumenta el volumen gradualmente. El correo autogestionado es más adecuado para:
- Correo personal;
- Notificaciones del sitio;
- Una pequeña cantidad de correo transaccional;
- Alertas de sistemas internos.
No es adecuado para enviar correo de marketing de inmediato. Eso es destrozar activamente la reputación de tu IP.
Las pistas habituales son más o menos así:
| Síntoma / Error | En qué fijarse |
|---|---|
550 5.7.1 | Rechazo por política, reputación, fallo de autenticación |
SPF fail | Registro SPF, Return-Path, IP de envío |
DKIM fail | Selector, clave pública, configuración de firma |
DMARC fail | Alineación SPF/DKIM, dominio del From |
PTR required | DNS inverso, nombre de host HELO |
blocked using Spamhaus | Lista negra de IP |
temporarily deferred | Frecuencia, greylisting, observación de reputación |
| Aceptado pero cae en spam | Reputación, contenido, cadencia de envío |
Un 4xx suele ser un rechazo temporal; un 5xx es casi siempre un rechazo duro. No te quedes solo con "falló": lee el texto que viene después.
No es vergonzoso, es la realidad.
Si te encuentras en las siguientes situaciones, considera seriamente un SMTP relay:
- El proveedor no abre el puerto 25;
- El rango de IP tiene mala reputación y cambiar de IP tampoco es estable;
- Necesitas enviar notificaciones de negocio, códigos de verificación o correos de pedidos y no puedes apostar la entregabilidad;
- No tienes energía para mantener RBL, informes DMARC y gestión de rebotes;
- Gmail/Outlook siguen mandando a spam aunque la autenticación pase.
Un enfoque intermedio es:
- Tu propio VPS se encarga de la recepción, IMAP y almacenamiento del buzón;
- El correo saliente pasa por un relay como Amazon SES, Mailgun, SendGrid o Postmark;
- From, DKIM y Return-Path se alinean según los requisitos del relay;
- El correo transaccional importante y el correo personal usan dominios o subdominios separados.
Así sigues controlando los datos de tu buzón, pero no pones toda la presión de entrega sobre una IP de VPS barata.
Si el correo está cayendo en spam ahora mismo, haz esto en orden:
- Revisa
/var/log/mail.logo los registros de Docker para confirmar si es rebote, retraso o caída en spam; - Envía a Gmail y revisa
spf/dkim/dmarcen el mensaje original; - Usa
dig TXT example.com +shortpara revisar SPF; - Usa
dig TXT selector._domainkey.example.com +shortpara revisar DKIM; - Usa
dig TXT _dmarc.example.com +shortpara revisar DMARC; - Usa
dig -x VPS_IP +shortpara revisar PTR; - Usa
postconf myhostnamepara revisar la identidad HELO/EHLO; - Usa
nc -vz gmail-smtp-in.l.google.com 25para revisar el puerto 25; - Revisa Spamhaus / MxToolbox;
- Regístrate en Google Postmaster Tools;
- Envía a bajo volumen desde una IP nueva primero; no hagas envíos masivos;
- Si sigue inestable, considera un SMTP relay.
Porque la autenticación es solo un billete de entrada, no una garantía de bandeja de entrada. Los receptores también revisan reputación de IP, reputación de dominio, frecuencia de envío, historial de quejas, calidad del contenido, dominios de enlace e interacción del usuario. Una IP de VPS nueva puede necesitar tiempo para construir reputación incluso con configuración correcta.
No. Cloudflare gestiona el DNS directo de tu dominio. El PTR/rDNS es la resolución inversa de una IP y debe configurarse en tu proveedor de VPS, o gestionarse mediante un ticket de soporte.
Al empezar el diagnóstico puedes usar ~all para reducir daños colaterales. Una vez confirmadas todas las fuentes de envío legítimas, se recomienda endurecer gradualmente a -all. Pero solo si realmente conoces todas las fuentes de envío, incluidos formularios web, sistemas de monitorización y servicios de correo de terceros.
No se recomienda. Empieza con p=none para recopilar informes, confirma que SPF/DKIM y todas las fuentes de envío están alineados, y luego pasa gradualmente a quarantine, reject. De lo contrario, puedes rechazar tu propio correo legítimo.
Sí, pero no subestimes el coste de mantenimiento. Recibir correo y enviar una pequeña cantidad de correo personal no es problema; para códigos de verificación, notificaciones de pedidos y correo de clientes, es mejor tener al menos un plan con SMTP relay.
Cuando el correo autogestionado en VPS cae en spam, la causa más común no es "el servidor de correo está roto", sino que la identidad y la reputación no pasaron la prueba.
El orden de diagnóstico es simple: revisa primero los registros de rebotes, luego SPF, DKIM, DMARC, después PTR/rDNS, HELO, puerto 25, listas negras de IP y datos de Postmaster. Si la autenticación falla, corrige primero la autenticación; una vez que pase, mira la reputación y el comportamiento de envío.
Si usas un VPS barato cuyo rango de IP se abusa a largo plazo, no gastes todo tu tiempo en la configuración. Cambia la IP cuando debas, y usa un SMTP relay cuando debas. Que el correo autogestionado entregue de forma fiable es solo la mitad de la configuración técnica; la otra mitad es la reputación.