SPF, DKIM y DMARC: evita que el correo de tu servidor acabe en spam

Mueves tus sitios a tu propio servidor, todo carga rápido, y entonces llama un cliente: «No hemos recibido ni una sola consulta por el formulario de contacto en dos semanas». El formulario funciona. El correo se envía. Simplemente acaba en spam — o se descarta en silencio. Es la sorpresa más común del autoalojamiento, y no tiene nada que ver con tu contenido. Gmail, Outlook y Yahoo deciden adónde va tu correo según dos cosas: ¿puedes demostrar que tienes permiso para enviar en nombre de este dominio, y tiene buena reputación la IP que envía? Un servidor recién estrenado no tiene ninguna de las dos. Así se arregla lo primero y se protege lo segundo.

Por qué el correo de tu servidor acaba en spam

Cualquiera puede poner cualquier dirección en la línea From: de un correo; el protocolo nunca lo comprobó. Los spammers lo aprovecharon durante décadas, así que los receptores ahora exigen pruebas. Desde 2024, Google y Yahoo lo exigen formalmente: todo remitente necesita SPF o DKIM además de DNS directo e inverso válidos, y quien envía en volumen (unos 5.000 mensajes al día a Gmail) necesita SPF, DKIM y DMARC. En la práctica, un servidor sin los tres se trata como sospechoso desde el primer mensaje.

Hay cuatro piezas, y todas viven en el DNS:

• SPF — qué servidores pueden enviar correo en nombre de tu dominio.
• DKIM — una firma criptográfica que demuestra que el mensaje no fue falsificado ni alterado.
• DMARC — la política que vincula ambos a la dirección From: visible, con informes.
• DNS inverso (PTR) — el nombre propio de la IP, que debe coincidir con el nombre de host del servidor.

SPF: la lista de remitentes autorizados

SPF es un registro TXT en tu dominio que enumera las IP y servicios autorizados a enviar en su nombre:

example.com.  TXT  "v=spf1 a mx include:_spf.google.com ~all"

a y mx autorizan las IP a las que apuntan los registros A y MX de tu dominio; include: incorpora la lista de un remitente externo; ~all significa «todo lo demás es sospechoso» (softfail), mientras que -all significa «recházalo» (hardfail). Empieza con ~all hasta que estés seguro de que la lista está completa.

Tres reglas que se rompen constantemente:

• Un solo registro SPF por dominio. Dos registros TXT v=spf1 no se fusionan; hacen que SPF falle por completo. Añade los nuevos remitentes al registro existente.
• Máximo 10 consultas DNS. Cada include, a, mx y redirect cuenta, incluidos los anidados dentro de cada include. Si pasas de 10, SPF devuelve un error permanente. Elimina los remitentes que ya no uses.
• SPF comprueba el remitente del sobre, no la línea From:. Por eso no basta por sí solo, y por eso existe DMARC.

DKIM: una firma en cada mensaje

Con DKIM, tu servidor de correo firma cada mensaje saliente con una clave privada. La clave pública correspondiente se publica en el DNS bajo un selector:

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

El receptor obtiene la clave, verifica la firma y sabe dos cosas: el mensaje lo envió alguien que tiene tu clave, y las cabeceras y el cuerpo firmados no se modificaron por el camino. En Linux, OpenDKIM conectado a Postfix como milter es la configuración clásica.

• Usa claves de 2048 bits. 1024 bits es el mínimo absoluto y cada vez está peor visto.
• Las claves largas hay que dividirlas. Una clave de 2048 bits supera el límite de 255 caracteres de una sola cadena TXT, así que debe publicarse como varias cadenas entre comillas en un mismo registro. Muchas interfaces DNS lo hacen por ti; los archivos de zona escritos a mano, no.
• Los selectores permiten rotar. Publica una clave nueva bajo un selector nuevo, cambia la firma a ella y elimina la antigua más tarde — sin ningún hueco de cobertura.

DMARC: la política que lo une todo

DMARC comprueba que SPF o DKIM pasaron y que el dominio autenticado está alineado con el dominio de la dirección From: visible. Es lo que impide que alguien envíe como ceo@example.com desde su propio servidor con un SPF válido para su dominio.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

La política p= indica a los receptores qué hacer con el correo que falla: none (solo informar), quarantine (carpeta de spam) o reject. rua= es donde los receptores envían informes agregados diarios — resúmenes XML de quién envió correo haciéndose pasar por ti y si pasó las comprobaciones.

Despliégalo por etapas:

1. Empieza con p=none y lee los informes durante dos a cuatro semanas. Descubrirás remitentes que habías olvidado: la herramienta de newsletter, el sistema de facturación, el CRM.
2. Corrige cada remitente legítimo (añádelo a SPF, activa la firma DKIM en su configuración).
3. Pasa a p=quarantine y luego a p=reject cuando los informes estén limpios.

DNS inverso, HELO y la propia IP

El servidor receptor también examina la conexión. La IP de tu servidor debería tener un registro PTR (DNS inverso) que resuelva a un nombre de host — por ejemplo mail.example.com — que a su vez resuelva a la misma IP. El nombre que el servidor anuncia en su saludo SMTP (HELO) debería ser ese mismo nombre de host. Los registros PTR se configuran en tu proveedor de hosting, normalmente en la consola cloud junto a la IP, no en el DNS de tu dominio.

Dos comprobaciones más antes de culpar a tus registros:

• ¿Está abierto el puerto 25? Muchos proveedores cloud, Hetzner incluido, bloquean el puerto 25 saliente en las cuentas nuevas hasta que solicitas abrirlo. El correo se acumula entonces en la cola y nunca sale.
• ¿Está la IP en una lista negra? Las IP cloud recicladas a veces arrastran el historial de un inquilino anterior. Compruébala en Spamhaus y listas similares antes de ponerte en marcha.

Cómo probar como es debido

No adivines — comprueba lo que ve el mundo:

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Después envía un mensaje real a una dirección de Gmail y abre Mostrar original. Quieres ver tres líneas: SPF: PASS, DKIM: PASS y DMARC: PASS. La cabecera Authentication-Results da los detalles cuando algo falla. Un servicio de puntuación como mail-tester.com revisa contenido, listas negras y autenticación de una vez, y swaks te permite enviar mensajes de prueba desde la línea de comandos sin tocar tu aplicación.

Errores que rompen la entrega en silencio

• Dos registros SPF tras añadir un servicio nuevo. SPF falla para todo.
• La aplicación envía con el dominio equivocado. WordPress usa por defecto wordpress@tudominio, y muchos scripts envían como www-data@nombredehost. El From: debe ser un dominio que hayas autenticado.
• Olvidar los remitentes externos — los servicios de newsletter y de correo transaccional necesitan cada uno su propio include SPF y su configuración DKIM.
• Saltar directamente a p=reject sin leer los informes. Tus facturas desaparecen junto con el spam.
• DKIM sin alinear. Un servicio que firma con su dominio pasa DKIM pero falla DMARC. Configura la firma con tu propio dominio en su panel.
• El reenvío rompe SPF. Cuando se reenvía un correo, el servidor que reenvía no está en el SPF del remitente original. DKIM sobrevive al reenvío, otra razón más para no prescindir nunca de él.
• Enviar una ráfaga desde una IP fría. Una IP nueva que de repente envía miles de mensajes parece una máquina comprometida. Aumenta el volumen poco a poco.

Cómo automatiza ShadowPanel la parte DNS

ShadowPanel es un panel de control de hosting autoalojado con correo integrado (Postfix con un milter OpenDKIM), y configurar la entregabilidad es un botón en lugar de una tarde generando claves y copiando registros TXT.

• DKIM en un clic. La página de correo tiene una sección de entregabilidad por dominio. Un clic genera una clave DKIM de 2048 bits, la registra en las tablas de firma de OpenDKIM y empieza a firmar el correo saliente de ese dominio.
• Registros SPF y DMARC añadidos automáticamente. Si la zona DNS del dominio la gestiona el panel — en su propio servidor de nombres o a través de una cuenta conectada de Hetzner DNS o Cloudflare —, el panel inserta el registro DKIM, un registro SPF (v=spf1 a mx ~all) y una política DMARC inicial (p=none, informes a postmaster@ tu dominio). Los registros SPF y DMARC existentes se detectan y se dejan como están, así que nunca cae en la trampa del SPF duplicado. Las claves DKIM largas se dividen correctamente para el servidor de nombres local.
• ¿DNS externo? Copiar y pegar. Si la zona está en otro sitio, el panel muestra los registros exactos que debes añadir en tu proveedor DNS, y una comprobación de estado indica cuáles ya están presentes.
• Buzones y alias. Crea buzones y reenvíos/alias por dominio; el panel rechaza un alias que taparía en silencio un buzón existente.

Lo que sigue siendo cosa tuya: configurar el registro PTR en tu proveedor de hosting, pedir que abran el puerto 25 si hace falta y endurecer DMARC de p=none a quarantine o reject cuando los informes estén limpios. Si a la vez estás sacando el correo de un hosting compartido, migrar de cPanel a un VPS sin tiempo de inactividad cubre la parte de los buzones, e instalar un panel de hosting en un VPS de Hetzner cubre el servidor.

En resumen

El correo de un servidor nuevo acaba en spam porque los receptores no pueden verificarlo, no porque sea correo malo. Publica un único registro SPF limpio, firma todo con una clave DKIM de 2048 bits, empieza DMARC con p=none y endurécelo cuando los informes estén limpios, configura un PTR coherente y prueba con cabeceras reales en lugar de con esperanza. ShadowPanel convierte la parte de DKIM, SPF y DMARC en un solo clic para los dominios que gestiona, y te da registros listos para copiar para los demás.

curl -fsSL https://shadowpanel.de/install.sh | bash

Ver precios y descargar →