¿Sus correos llegan a spam? Lista de comprobación DNS

Cuando el correo legítimo acaba en spam, la causa es una de dos: la autenticación (el receptor no puede confirmar que el mensaje procede realmente de su dominio) o la reputación (sí puede, y no le gusta lo que ve). El DNS arregla la primera. No arregla la segunda, pero mientras la primera no esté bien, nada de lo demás contará.

Esta lista recorre la parte de DNS en el orden que antes encuentra los problemas. Los conceptos de fondo están en MX, SPF, DKIM y DMARC explicados; aquí nos quedamos en lo práctico.

Paso 0: lea las cabeceras de un mensaje que fue a spam

No adivine. Envíe un mensaje a un buzón que usted controle en el proveedor donde ocurre el problema, ábralo y elija "mostrar original" o "ver código fuente". Busque la cabecera Authentication-Results que añadió el receptor:

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=bounces.mailer.example;
   dkim=pass header.d=mailer.example header.s=s1;
   dmarc=fail (p=NONE) header.from=example.com

Esa sola cabecera dice casi todo lo necesario:

Campo	Pregunta a la que responde
`spf=` y `smtp.mailfrom=`	¿Coincidía la IP de envío con el registro SPF del dominio del sobre, y qué dominio era ese?
`dkim=` y `header.d=`	¿Había una firma válida, y de qué dominio?
`dmarc=` y `header.from=`	¿Pasó SPF o DKIM para el dominio que ve el destinatario?

En el ejemplo todo "pasa" y aun así DMARC falla: SPF y DKIM pasaron para los dominios del servicio de envío, no para example.com. Es, con diferencia, el hallazgo más frecuente, y de él se ocupa el paso 4.

Anote también la IP de envío que figura en la línea Received: situada más arriba de las que añadió el receptor; hará falta en el paso 5.

Paso 1: enumere todo lo que envía correo en nombre de su dominio

La autenticación falla casi siempre por un remitente del que nadie se acordaba: el proveedor de buzones, la herramienta de boletines, el CRM, el sistema de facturación, el soporte, el formulario de contacto de la web, el escáner de la oficina, las alertas de monitorización. Apúntelos todos. Cada uno debe estar cubierto por SPF o por DKIM, y preferiblemente por ambos.

Paso 2: SPF

$ dig +short example.com TXT | grep spf1
"v=spf1 include:_spf.mailprovider.example include:spf.mailer.example -all"

Compruebe:

Exactamente un registro que empiece por v=spf1. Dos registros son un error permanente (permerror), y el resultado es como no tener ninguno.
Cada remitente del paso 1 está cubierto por un include:, un ip4: o un ip6:.
No hay más de 10 consultas DNS en total. include, a, mx, exists y redirect cuentan cada uno, y los include se anidan. Superar el límite también es un permerror. Elimine los servicios que ya no usa antes de recurrir al "SPF flattening".
Termina en ~all o -all. +all autoriza a todo Internet; ?all no dice nada.
Sin mecanismo ptr. Es lento, poco fiable y está desaconsejado por la propia especificación de SPF.
Los subdominios que envían correo (news.example.com) tienen su propio registro SPF. SPF no se hereda.

Recuerde qué comprueba SPF: el remitente del sobre (Return-Path), no la cabecera From. Si un servicio usa su propio dominio de rebotes, SPF pasa para el dominio de ese servicio y no ayuda al resultado DMARC de usted, salvo que configure un return-path personalizado.

Paso 3: DKIM

Tome el selector (s=) y el dominio (d=) de la cabecera DKIM-Signature de un mensaje real y consulte la clave:

$ dig +short s1._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

El registro existe y contiene un valor p=. Un p= vacío significa que la clave fue revocada.
Las claves largas están divididas en varias cadenas entrecomilladas, sin espacios sueltos ni saltos de línea pegados por el panel de control.
La longitud de la clave es de 2048 bits donde el proveedor lo permita; 1024 es el mínimo que aceptan los receptores.
Si el proveedor pidió registros CNAME en lugar de TXT, están presentes y su proveedor DNS no los "aplana" ni los pasa por proxy.
d= es su dominio, no el del proveedor. La mayoría de los servicios firma con su propio dominio hasta que usted completa su proceso de "autenticar el dominio". Esto es lo que hace que DKIM cuente para DMARC.
Cada servicio de envío tiene su propio selector.

No hay forma de enumerar desde fuera los selectores DKIM de un dominio. Se encuentran en las cabeceras de los mensajes o en la configuración del proveedor.

Paso 4: DMARC y alineación

$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Un solo registro en _dmarc.example.com, que empiece por v=DMARC1 y tenga un p= válido.
Una dirección rua= que alguien, o alguna herramienta, lea de verdad. Si está en otro dominio, ese dominio debe publicar un registro de autorización.
Para cada remitente, al menos uno de los dos, SPF o DKIM, pasa con un dominio que coincide con el dominio del From (en el modo relajado por defecto basta con el mismo dominio organizativo).

Desde febrero de 2024, Gmail y Yahoo exigen SPF, DKIM y un registro DMARC (como mínimo p=none) con alineación a quien envíe en torno a 5000 mensajes diarios o más a sus usuarios, además de la baja con un solo clic en el correo comercial y una tasa de quejas baja. Otros grandes proveedores han anunciado reglas similares. Los remitentes pequeños necesitan como mínimo SPF o DKIM, y en la práctica se les mide con la misma vara.

p=none proporciona informes y cumple el mínimo. No protege al dominio de la suplantación. Pase a quarantine y a reject cuando los informes muestren que todas las fuentes legítimas están alineadas.

Paso 5: el servidor de envío, DNS inverso y HELO

Solo es relevante si usted mismo administra el servidor de correo. Con la IP del paso 0:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com
192.0.2.25

Existe un registro PTR y no es el genérico por defecto del proveedor.
El nombre resuelve de vuelta a la misma IP.
El servidor se presenta con ese mismo nombre en EHLO.
Si el servidor tiene IPv6, se cumple lo mismo para esa dirección, o bien el correo saliente se limita a IPv4.

El glosario lo amplía en DNS inverso.

Paso 6: los MX y el propio dominio

El dominio tiene registros MX operativos que apuntan a nombres de host (no a IP ni a CNAME) que aceptan correo. Los receptores desconfían de los remitentes que no pueden recibir rebotes ni respuestas.
postmaster@ y abuse@ llegan a una persona.
Los dominios que nunca envían correo lo declaran: v=spf1 -all, un MX nulo (0 .) y v=DMARC1; p=reject. Los dominios aparcados son los favoritos para la suplantación.

Paso 7: TLS

El correo saliente usa STARTTLS. Gmail marca el correo sin cifrar con un candado rojo, y las reglas para remitentes masivos exigen TLS.
Su propio MX ofrece STARTTLS con un certificado que no está caducado:

$ openssl s_client -connect mail.example.com:25 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

Si el certificado resulta estar vencido, el procedimiento está en certificado SSL caducado: qué hacer.

Paso 8: listas de bloqueo y reputación

Busque la IP de envío y el dominio en las páginas de consulta de los principales operadores de listas de bloqueo. Figurar en una lista desconocida rara vez importa; figurar en una muy utilizada, sí. Corrija la causa (cuenta comprometida, formulario abierto, lista comprada) antes de pedir la retirada.
Registre el dominio en las herramientas para postmasters que ofrecen los grandes proveedores de buzones. Muestran cómo ven esos proveedores su dominio: tasa de quejas por spam, resultados de autenticación, reputación.

Cuando el DNS está bien y el correo sigue yendo a spam

Entonces es la reputación o el contenido, y ningún registro va a ayudar:

un dominio nuevo o una IP nueva que envía volumen desde el primer día, sin calentamiento previo
destinatarios que nunca pidieron el correo, y se quejan
listas antiguas con muchas direcciones muertas
acortadores de enlaces, enlaces a dominios mal considerados, mensajes que son solo una imagen
un dominio en el From distinto del dominio de los enlaces y del dominio de la firma
en IP compartidas: el comportamiento de otros clientes

El DNS consigue que se le juzgue como usted mismo. Lo que ocurra después depende de lo que envíe.

Errores frecuentes

Añadir un segundo registro SPF para un servicio nuevo en lugar de ampliar el existente.
Ver spf=pass y dkim=pass y quedarse ahí, sin comprobar qué dominio pasó.
Saltar a p=reject sin leer los informes y perder las facturas que enviaba un sistema olvidado.
Probar solo desde el buzón propio al buzón propio dentro del mismo proveedor.
Esperar que los cambios se vean al instante; los registros SPF y DMARC permanecen en caché durante su TTL.

Compruébelo con OrbitProbe

La consulta MX de OrbitProbe muestra los hosts MX de un dominio y sus prioridades, el proveedor de correo probable y los registros SPF y DMARC, con observaciones sobre los errores de configuración habituales. No puede enumerar los selectores DKIM, porque nadie puede hacerlo desde fuera; compruébelos a partir de la cabecera de un mensaje, como se describe en el paso 3. Ejecútela para el dominio exacto de su dirección From y de nuevo para cada subdominio que envíe correo.