Tener un servidor de correo que envía no garantiza que los mensajes lleguen a la bandeja de entrada. Gmail, Outlook y Yahoo deciden qué hacer con cada mensaje según la identidad del servidor, la autenticación del dominio y la reputación acumulada de la IP y del dominio. En esta guía revisarás, en orden, cada uno de esos factores en un servidor Postfix con Ubuntu 24.04: nombre y DNS inverso, SPF, DKIM, DMARC, TLS, requisitos de los grandes proveedores, calentamiento de la IP, listas negras y gestión de rebotes.

Requisitos previos

Para seguir esta guía necesitas:

  • Un servidor de correo con Ubuntu 24.04 LTS y Postfix enviando correo para tu dominio your_domain, por ejemplo en un VPS de CubePath. Los principios valen igual para Mailcow, Mail-in-a-Box o Stalwart.
  • Un usuario no root con privilegios sudo.
  • Acceso a la zona DNS de your_domain.
  • Una cuenta de Gmail para comprobar los resultados.

En los ejemplos, el servidor se llama mail.your_domain y su IP pública es your_server_ip.

Paso 1: Comprobar la identidad del servidor

Lo primero que mira un servidor receptor es quién se conecta. Necesita tres datos coherentes entre sí:

  1. El registro A de mail.your_domain apunta a your_server_ip.
  2. El DNS inverso (PTR) de your_server_ip resuelve a mail.your_domain.
  3. Postfix se presenta con ese mismo nombre en el saludo EHLO.

Comprueba los dos primeros:

dig +short A mail.your_domain
dig +short -x your_server_ip

your_server_ip
mail.your_domain.

Si el PTR no existe o devuelve un nombre genérico del proveedor, configúralo. En CubePath se hace desde el panel: en la página Floating IPs o en la pestaña de red del VPS, edita el campo Reverse DNS de la IP. Gmail rechaza directamente el correo de IPs sin PTR.

Comprueba el nombre con el que se presenta Postfix:

postconf myhostname smtp_helo_name

myhostname = mail.your_domain
smtp_helo_name = $myhostname

Si myhostname no coincide, corrígelo y recarga Postfix:

sudo postconf -e "myhostname = mail.your_domain"
sudo systemctl reload postfix

Paso 2: Publicar un registro SPF correcto

SPF indica qué servidores pueden enviar correo con tu dominio en la dirección de remitente del sobre (MAIL FROM). Si solo envías desde tu servidor, basta con autorizar los servidores MX:

your_domain.   IN TXT   "v=spf1 mx -all"

Si también envías a través de otros servicios (un proveedor de newsletters, un CRM), añade el include: que te indique cada uno, por ejemplo v=spf1 mx include:_spf.example-esp.com -all. Ten en cuenta dos reglas:

  • Solo puede haber un registro SPF por dominio. Dos registros v=spf1 hacen que la comprobación falle.
  • SPF admite como máximo 10 consultas DNS (include, a, mx, redirect...). Si las superas, el resultado es un error permanente.

-all indica que cualquier otro origen debe rechazarse y ~all que debe tratarse con sospecha. Con DMARC publicado, la diferencia práctica es pequeña; -all es la opción más clara cuando conoces todos tus orígenes.

Comprueba el registro:

dig +short TXT your_domain | grep spf1

"v=spf1 mx -all"

Paso 3: Firmar con DKIM

DKIM añade a cada mensaje una firma criptográfica que el receptor valida con la clave pública publicada en tu DNS. A diferencia de SPF, la firma sobrevive a los reenvíos, por eso es la pieza más importante para DMARC.

La forma de generar la clave depende de tu software: Rspamd u OpenDKIM con Postfix, o el propio panel en Mailcow, Mail-in-a-Box y Stalwart. Usa claves RSA de 2048 bits. Sea cual sea la herramienta, comprueba que la clave está publicada con el selector que usa tu servidor (en el ejemplo, mail):

dig +short TXT mail._domainkey.your_domain

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Si la clave aparece partida en varias cadenas entre comillas, es normal: los registros TXT se dividen en bloques de 255 caracteres y el receptor los une.

Paso 4: Activar DMARC y alinear los dominios

DMARC une SPF y DKIM con el dominio que ve el usuario en el campo From. Un mensaje pasa DMARC si pasa SPF o DKIM y, además, el dominio validado está alineado con el del From:

  • SPF está alineado si el dominio del MAIL FROM coincide con el del From.
  • DKIM está alineado si el dominio de la firma (d=) coincide con el del From.

Por defecto la alineación es relajada, así que mail.your_domain y your_domain cuentan como el mismo dominio. El fallo más habitual aparece al enviar desde servicios externos que firman con su propio dominio: el mensaje pasa DKIM, pero no alinea. Configura en esos servicios la firma DKIM con tu dominio.

Empieza con una política de solo observación y un buzón para recibir los informes agregados:

_dmarc.your_domain.   IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc@your_domain"

Durante dos a cuatro semanas, revisa los informes que envían los grandes proveedores: son ficheros XML que indican qué IPs han enviado correo con tu dominio y si pasaron SPF y DKIM. Cuando confirmes que todo tu correo legítimo pasa, endurece la política a p=quarantine y después a p=reject, que además protege tu dominio frente a suplantaciones.

Comprueba el registro:

dig +short TXT _dmarc.your_domain

"v=DMARC1; p=none; rua=mailto:dmarc@your_domain"

Paso 5: Cifrar las conexiones con TLS

Gmail marca en rojo los mensajes recibidos sin cifrar, y algunos filtros los penalizan. Asegúrate de que Postfix usa TLS de forma oportunista al enviar:

postconf smtp_tls_security_level

smtp_tls_security_level = may

Si el valor está vacío o es none, actívalo:

sudo postconf -e "smtp_tls_security_level = may"
sudo systemctl reload postfix

Para la recepción, el servidor necesita un certificado válido para mail.your_domain en el puerto 25. Compruébalo desde otro equipo:

openssl s_client -starttls smtp -connect mail.your_domain:25 -brief < /dev/null

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mail.your_domain
...
Verification: OK

Paso 6: Cumplir los requisitos de Gmail, Yahoo y Outlook

Desde 2024 Gmail y Yahoo exigen unos mínimos a todos los remitentes, más estrictos para quienes envían más de 5.000 mensajes al día a sus usuarios. Desde 2025 Outlook aplica requisitos equivalentes a los remitentes de gran volumen:

RequisitoTodos los remitentesMás de 5.000 al día
SPF o DKIM válidosSíSPF y DKIM
DNS inverso coherenteSíSí
Conexión TLSSíSí
Registro DMARC (al menos p=none)RecomendadoObligatorio, alineado con el From
Baja con un clic (RFC 8058) en correo comercialRecomendadoObligatorio
Tasa de spam denunciadoPor debajo del 0,3 %Por debajo del 0,3 %

La baja con un clic se implementa con dos cabeceras en los mensajes de marketing y newsletters. Tu software de envío debe añadirlas, y la URL debe procesar la baja con una petición POST sin pedir nada más al usuario:

List-Unsubscribe: <https://your_domain/unsubscribe?id=abc123>, <mailto:unsubscribe@your_domain?subject=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

El correo transaccional (restablecer contraseñas, facturas) no necesita estas cabeceras. Envíalo, si puedes, desde un subdominio distinto, como notify.your_domain, para que su reputación no dependa de la de tus campañas.

Paso 7: Calentar una IP nueva

Una IP sin historial no tiene reputación, y los proveedores desconfían de una IP nueva que empieza enviando miles de mensajes. Calentar la IP consiste en aumentar el volumen de forma gradual, empezando por los destinatarios más activos, los que abren y responden, para acumular señales positivas.

Una progresión orientativa:

SemanaMensajes al día por proveedor (Gmail, Outlook...)
150 a 100
2200 a 500
31.000 a 2.000
45.000
5 en adelanteDuplica mientras las métricas se mantengan limpias

Si en algún momento aumentan los rebotes, los aplazamientos (status=deferred) o las quejas, vuelve al volumen anterior durante unos días. Si tu servidor solo envía correo de un equipo pequeño, no necesitas un plan formal: el uso normal calienta la IP solo.

Para seguir la reputación, date de alta en las herramientas de los propios proveedores:

  • Google Postmaster Tools (postmaster.google.com): verificas el dominio con un registro TXT y muestra la reputación del dominio y la IP, la tasa de spam y los errores de autenticación. Solo muestra datos cuando envías un volumen diario significativo a Gmail.
  • Microsoft SNDS (sendersupport.olc.protection.outlook.com/snds): muestra el filtrado y las quejas de tu IP en Outlook y Hotmail.

Paso 8: Vigilar las listas negras

Las listas negras DNS (DNSBL) se consultan invirtiendo los octetos de la IP y añadiendo el dominio de la lista. Por ejemplo, para comprobar 203.0.113.10 en Spamhaus:

dig +short 10.113.0.203.zen.spamhaus.org

Si la respuesta está vacía, la IP no está listada. Una respuesta 127.0.0.x indica que sí lo está; el último octeto dice en qué lista. Consulta las más relevantes de una vez sustituyendo la IP por la tuya:

ip=203.0.113.10
rev=$(echo "$ip" | awk -F. '{print $4"."$3"."$2"."$1}')
for bl in zen.spamhaus.org b.barracudacentral.org bl.spamcop.net; do
  echo "$bl: $(dig +short "$rev.$bl" | head -n1)"
done

zen.spamhaus.org:
b.barracudacentral.org:
bl.spamcop.net:

Si apareces en una lista, busca primero la causa (una cuenta comprometida, un formulario web abusado, un relay abierto) y corrígela. Después solicita la baja desde la web de la lista; la mayoría la conceden en horas si el problema está resuelto.

Paso 9: Gestionar los rebotes

Seguir enviando a direcciones que no existen es una de las señales más claras de lista de mala calidad. Postfix registra cada entrega en /var/log/mail.log. Localiza los rebotes definitivos:

sudo grep "status=bounced" /var/log/mail.log

2026-09-25T10:42:07.512345+00:00 mail postfix/smtp[5123]: 4XyZ1234: to=<[email protected]>, relay=mx.example.com[198.51.100.20]:25, delay=0.9, dsn=5.1.1, status=bounced (host mx.example.com[198.51.100.20] said: 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown)

Los códigos 5.x.x son permanentes: elimina esas direcciones de tus listas. Los 4.x.x son temporales y Postfix reintenta solo. Presta atención a los rechazos que mencionan reputación o políticas (por ejemplo, 5.7.1 con un enlace a la documentación del proveedor): te dicen exactamente qué requisito incumples.

Para ver de un vistazo la proporción de entregas, aplazamientos y rebotes, agrupa los resultados por código:

sudo grep -o "dsn=[0-9.]*, status=[a-z]*" /var/log/mail.log | sort | uniq -c | sort -rn

   1843 dsn=2.0.0, status=sent
     37 dsn=4.7.28, status=deferred
     12 dsn=5.1.1, status=bounced

Un porcentaje de rebotes por encima del 2 % o aplazamientos 4.7.x repetidos hacia un mismo proveedor indican que debes limpiar la lista o reducir el ritmo de envío.

Paso 10: Probar el resultado completo

Con todo configurado, envía un correo desde tu servidor a tu cuenta de Gmail, ábrelo y elige Mostrar original. La cabecera debe indicar:

SPF:   PASS con la IP your_server_ip
DKIM:  'PASS' con el dominio your_domain
DMARC: 'PASS'

Para un análisis más completo, servicios como mail-tester.com te dan una dirección de prueba, analizan el mensaje que envías (autenticación, listas negras, contenido, cabeceras) y devuelven una puntuación con los problemas detectados.

Solución de problemas

El correo llega a spam aunque SPF, DKIM y DMARC pasan. La autenticación demuestra quién eres, no que tu correo sea deseado. Revisa la reputación en Google Postmaster Tools, el contenido (enlaces acortados, solo imagen, asuntos engañosos) y si los destinatarios pidieron recibir tus mensajes.

Gmail rechaza con 550 5.7.26 o 550 5.7.1 citando la autenticación. El mensaje no pasó DMARC o no tiene SPF ni DKIM válidos. Comprueba la alineación del paso 4, sobre todo si envías a través de servicios externos.

Outlook rechaza con 550 5.7.1 ... Service unavailable, Client host blocked. La IP está bloqueada en los filtros de Microsoft. Consulta el estado en SNDS y solicita la revisión en el formulario de soporte para remitentes de Microsoft.

Los mensajes a un proveedor quedan aplazados con códigos 421 o 4.7.x. El proveedor está limitando el volumen por falta de reputación. Reduce el ritmo de envío hacia ese destino y sigue el calentamiento del paso 7.

Conclusión

La entregabilidad se apoya en tres capas: una identidad del servidor coherente (A, PTR y EHLO), un dominio autenticado y alineado (SPF, DKIM y DMARC) y una reputación que se construye con volumen gradual, listas limpias y pocos rebotes y quejas. Como siguientes pasos, endurece DMARC hasta p=reject cuando los informes lo permitan, publica MTA-STS y TLS-RPT para proteger la recepción, y revisa Postmaster Tools y tus registros de rebotes cada semana.