--- title: "Cómo mejorar la entregabilidad del correo de tu servidor" description: "Evita que tu correo llegue a spam: configura DNS inverso, SPF, DKIM y DMARC alineados, cumple los requisitos de Gmail, calienta la IP y vigila listas negras." category: "Email Avanzado" language: es source: https://cubepath.com/es/docs/email-avanzado/guia-de-optimizacion-de-entregabilidad-de-email updated: 2026-09-25 --- # Cómo mejorar la entregabilidad del correo de tu servidor 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: ```bash dig +short A mail.your_domain dig +short -x your_server_ip ``` ```output 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: ```bash postconf myhostname smtp_helo_name ``` ```output myhostname = mail.your_domain smtp_helo_name = $myhostname ``` Si `myhostname` no coincide, corrígelo y recarga Postfix: ```bash sudo postconf -e "myhostname = mail.your_domain" sudo systemctl reload postfix ``` > Importante: si el servidor tiene varias IPv4, Postfix puede salir por cualquiera de ellas. Fija la IP de salida con `sudo postconf -e "smtp_bind_address = your_server_ip"` para que siempre coincida con el PTR configurado. Si tienes IPv6 y no has configurado su PTR, desactiva la salida por IPv6 con `sudo postconf -e "inet_protocols = ipv4"`. ## 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: ```text 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: ```bash dig +short TXT your_domain | grep spf1 ``` ```output "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`): ```bash dig +short TXT mail._domainkey.your_domain ``` ```output "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: ```text _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: ```bash dig +short TXT _dmarc.your_domain ``` ```output "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: ```bash postconf smtp_tls_security_level ``` ```output smtp_tls_security_level = may ``` Si el valor está vacío o es `none`, actívalo: ```bash 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: ```bash openssl s_client -starttls smtp -connect mail.your_domain:25 -brief < /dev/null ``` ```output 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: | Requisito | Todos los remitentes | Más de 5.000 al día | |-----------|----------------------|----------------------| | SPF o DKIM válidos | Sí | SPF **y** DKIM | | DNS inverso coherente | Sí | Sí | | Conexión TLS | Sí | Sí | | Registro DMARC (al menos `p=none`) | Recomendado | Obligatorio, alineado con el `From` | | Baja con un clic (RFC 8058) en correo comercial | Recomendado | Obligatorio | | Tasa de spam denunciado | Por 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: ```text List-Unsubscribe: , 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: | Semana | Mensajes al día por proveedor (Gmail, Outlook...) | |--------|---------------------------------------------------| | 1 | 50 a 100 | | 2 | 200 a 500 | | 3 | 1.000 a 2.000 | | 4 | 5.000 | | 5 en adelante | Duplica 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: ```bash 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: ```bash 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 ``` ```output zen.spamhaus.org: b.barracudacentral.org: bl.spamcop.net: ``` > Nota: Spamhaus bloquea las consultas que llegan desde resolutores públicos como 8.8.8.8 o 1.1.1.1 y responde `127.255.255.254`. Esa respuesta no significa que estés listado. Haz la consulta desde un resolutor propio o usa el buscador de la web de Spamhaus. 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: ```bash sudo grep "status=bounced" /var/log/mail.log ``` ```output 2026-09-25T10:42:07.512345+00:00 mail postfix/smtp[5123]: 4XyZ1234: to=, 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 : 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: ```bash sudo grep -o "dsn=[0-9.]*, status=[a-z]*" /var/log/mail.log | sort | uniq -c | sort -rn ``` ```output 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: ```text 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.