Por qué mi correo cae en spam y cómo solucionarlo (SPF, DKIM, DMARC)

Por qué el correo cae en spam: las causas reales

Cuando un correo legítimo cae en spam, la causa está casi siempre en una de cinco categorías, y solo una de ellas tiene que ver con el contenido del mensaje. Un servidor que recibe un correo debe decidir en milisegundos si confía en él, y esa decisión se basa sobre todo en si puede verificar el origen.

• Falta de autenticación. El dominio no publica SPF ni DKIM, así que el receptor no puede comprobar nada y aplica el criterio más conservador.
• Autenticación rota. Hay registros, pero están mal: dos SPF en el mismo dominio, más de diez consultas DNS, un DKIM con la clave cortada o un DMARC publicado en el nombre equivocado. Un registro roto suele ser peor que ninguno, porque produce un fallo explícito.
• Reputación de la IP o del dominio. La dirección IP del servidor de salida está en listas negras, o el dominio es muy nuevo y no tiene historial de envío.
• Comportamiento de envío. Picos bruscos de volumen, listas con muchas direcciones inexistentes o una tasa alta de quejas por spam.
• Contenido. Enlaces acortados, adjuntos ejecutables, imágenes sin texto o palabras típicas de fraude. Es la categoría que todo el mundo revisa primero y la que menos suele explicar el problema.

Desde febrero de 2024, Google y Yahoo exigen a quien envía más de 5.000 mensajes diarios a sus usuarios que tenga SPF, DKIM y una política DMARC de al menos p=none, que ofrezca baja de suscripción en un clic y que mantenga la tasa de quejas de spam por debajo del 0,3%. Ese cambio convirtió la autenticación en un requisito de entrada, no en una buena práctica opcional.

SPF: qué es y cómo se escribe correctamente

SPF (Sender Policy Framework, definido en el RFC 7208) es un registro TXT en el DNS del dominio que declara qué servidores están autorizados a enviar correo en su nombre. Un registro TXT es simplemente una entrada de DNS que guarda texto libre; SPF, DKIM y DMARC usan los tres este mismo tipo de registro. Cuando llega un mensaje, el servidor receptor consulta el SPF del dominio del remitente y compara la IP que se lo está entregando contra la lista publicada.

Un registro SPF siempre empieza con v=spf1, sigue con uno o más mecanismos y termina con all. Los mecanismos más usados son:

• include:dominio — autoriza a los servidores que el registro SPF de ese otro dominio autorice. Es la forma normal de habilitar a un proveedor externo.
• ip4:1.2.3.4 o ip4:1.2.3.0/24 — autoriza una IP o un rango. No consume consultas DNS.
• a y mx — autorizan a las IPs del registro A del dominio o de sus servidores de correo.
• all — el cierre obligatorio, precedido de un calificador: -all rechaza todo lo no listado, ~all lo marca como sospechoso sin rechazarlo, ?all es neutro y +all autoriza a cualquiera, lo que equivale a no tener SPF.

Estos son registros reales para los escenarios más comunes. Reemplaza los valores de ejemplo por los de tu proveedor:

; Un solo proveedor de correo. Nombre del registro: @ (o tudominio.com)
; Google Workspace
tudominio.com.    3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; Microsoft 365
tudominio.com.    3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

; Correo en tu propio servidor, autorizando su IP fija
tudominio.com.    3600  IN  TXT  "v=spf1 ip4:198.51.100.25 -all"

; Un proveedor de correo MÁS un servicio de envío transaccional.
; Un solo registro con varios include, nunca dos registros separados.
tudominio.com.    3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

; Dominio que NO envía correo (por ejemplo uno usado solo para redirigir)
noenvia.com.      3600  IN  TXT  "v=spf1 -all"

Si tu panel de DNS solo pide "nombre" y "valor", el nombre es @ y el valor es el texto entre comillas, sin las comillas.

La regla que más se rompe: un dominio puede tener un solo registro que empiece con v=spf1. Si publicas dos, la evaluación devuelve un error permanente llamado PermError y todos los correos del dominio fallan la autenticación, incluidos los legítimos. Es un error habitual porque cada servicio nuevo pide "agregar este registro SPF" y el administrador lo agrega en vez de fusionarlo. Para usar dos servicios, se combinan sus mecanismos include dentro de un mismo registro.

Sobre -all frente a ~all: -all es más estricto y protege mejor contra suplantación, pero si olvidaste autorizar un sistema legítimo, sus correos se rechazan. La recomendación práctica es empezar con ~all durante las primeras semanas, revisar los informes DMARC y pasar a -all cuando estés seguro de que todos los remitentes legítimos están en la lista.

El límite de 10 consultas DNS: el error que rompe SPF en silencio

La evaluación de un registro SPF puede realizar como máximo diez consultas DNS, según la sección 4.6.4 del RFC 7208. Al superarlas, el resultado es PermError y el mensaje falla la autenticación aunque el remitente sea perfectamente legítimo. Es el error más silencioso de todos, porque el registro se ve bien a simple vista.

Cuentan para el límite los mecanismos include, a, mx, exists, redirect y ptr. No cuentan ip4 ni ip6, porque no requieren consultar el DNS. Lo traicionero es que cada include puede a su vez contener más include, y esos anidados también suman: en las mediciones habituales, el include de Google Workspace consume alrededor de cuatro consultas y el de Microsoft 365 alrededor de dos, aunque los proveedores cambian sus registros y conviene medirlo en lugar de asumirlo.

Un registro típico de una empresa que fue acumulando servicios sin limpiar termina así:

; Registro roto: supera las 10 consultas DNS y devuelve PermError
tudominio.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:mail.zendesk.com include:spf.mandrillapp.com ~all"

Tres formas de arreglarlo, en orden de preferencia:

1. 1 Eliminar lo que ya no se usa. Casi siempre hay dos o tres servicios contratados hace años que nadie recuerda. Es la solución más limpia y no cuesta nada.
2. 2 Reemplazar includes por ip4 cuando el proveedor publica direcciones fijas y documentadas. Los mecanismos ip4 no consumen consultas, pero si el proveedor cambia sus IPs y no te enteras, el correo deja de autenticar.
3. 3 Usar un servicio de aplanado de SPF (SPF flattening), que mantiene un registro dinámico con las IPs resueltas y lo actualiza automáticamente. Añade una dependencia externa, pero resuelve el problema de raíz en dominios con muchos servicios.

Nunca uses el mecanismo ptr: el propio RFC 7208 desaconseja publicarlo porque es lento y poco fiable, y algunos receptores grandes lo ignoran o descartan el registro completo.

DKIM: la firma criptográfica del mensaje

DKIM (DomainKeys Identified Mail, RFC 6376) añade una firma criptográfica a la cabecera de cada mensaje saliente. El servidor que recibe extrae de esa cabecera el nombre del selector, busca la clave pública en el DNS del dominio y verifica que el mensaje no fue alterado en tránsito y que salió de quien dice haber salido. Mientras SPF valida la IP que entrega, DKIM valida el mensaje en sí, y por eso sobrevive a los reenvíos que rompen SPF.

El registro se publica en un nombre con esta forma: selector._domainkey.tudominio.com. El selector es una etiqueta que elige el proveedor, por ejemplo google, s1, default o mail, y sirve para poder tener varias claves activas a la vez y rotarlas sin cortar el servicio.

; DKIM. Nombre del registro: <selector>._domainkey
; La parte p= es la clave pública que entrega tu proveedor. Va completa, en una línea.
google._domainkey.tudominio.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxvY2Rm8k...RESTO_DE_TU_CLAVE...IDAQAB"

Las etiquetas del registro son:

• v=DKIM1 — versión. Va siempre primero.
• k=rsa — algoritmo de la clave. Es el valor habitual; algunos proveedores usan ed25519.
• p= — la clave pública en Base64. Es el valor largo que entrega el proveedor.
• t=y — opcional, marca el dominio en modo de prueba. Se usa durante el despliegue y luego se quita.

El error de DKIM que más se repite es la clave partida. Una cadena de texto en DNS admite un máximo de 255 caracteres, y una clave RSA de 2048 bits supera ese límite. Muchos paneles la parten automáticamente en varias cadenas entre comillas, lo cual es correcto, porque el resolvedor las vuelve a unir. El problema aparece cuando alguien copia la clave desde un correo o un PDF y arrastra saltos de línea o espacios en medio del valor p=. La clave debe quedar sin espacios internos. Si al verificarla la firma no valida, revisa esto antes que cualquier otra cosa.

Genera claves de 2048 bits. Las de 1024 bits todavía funcionan y son el mínimo aceptado por Google y Yahoo, pero se consideran débiles y hay receptores que empiezan a penalizarlas.

DMARC: la política y, sobre todo, los informes

DMARC (Domain-based Message Authentication, Reporting and Conformance) es el registro que une los otros dos. Le dice al servidor receptor qué hacer con los mensajes que fallan SPF y DKIM, y a qué dirección enviar los informes diarios sobre quién está enviando correo en nombre del dominio. Sin DMARC, cada proveedor decide por su cuenta qué hacer con un fallo, y nadie te informa de nada.

DMARC se publica siempre en el nombre _dmarc.tudominio.com. Publicarlo en la raíz del dominio es un error frecuente y equivale a no tenerlo.

En mayo de 2026, el IETF publicó los RFC 9989, 9990 y 9991, que reemplazan al RFC 7489 original. El cambio principal para quien administra dominios es que se retiraron las etiquetas pct, rf y ri, y se añadieron np, psd y t. La etiqueta t=y sustituye a pct=0 para indicar modo de prueba, y t=n es el modo de aplicación normal. Los registros escritos con la sintaxis anterior siguen funcionando: los receptores ignoran las etiquetas que no reconocen en vez de rechazar el registro completo.

; PASO 1 — Solo observar. Empieza SIEMPRE aquí.
_dmarc.tudominio.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

; PASO 2 — Cuarentena tras revisar informes durante 2 a 4 semanas.
_dmarc.tudominio.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; rua=mailto:[email protected]"

; PASO 3 — Aplicación completa, cuando todo lo legítimo ya autentica.
_dmarc.tudominio.com.  3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; t=n; rua=mailto:[email protected]"

; Dominio que no envía correo: protégelo igual, es el que suplantan.
_dmarc.noenvia.com.    3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

Qué significa cada etiqueta:

• v=DMARC1 — versión. Obligatoria y siempre primero.
• p= — la política para el dominio principal: none (solo observar), quarantine (a la carpeta de spam) o reject (rechazar la entrega).
• sp= — la política para los subdominios. Si se omite, los subdominios heredan p=.
• np= — política para subdominios inexistentes, es decir los que devuelven NXDOMAIN en el DNS. Es nueva en RFC 9989 y cierra un hueco real de suplantación.
• adkim y aspf — el modo de alineación de DKIM y SPF: r relajado (permite subdominios) o s estricto (exige coincidencia exacta del dominio). El valor por defecto es r.
• t= — modo de prueba: t=y equivale al antiguo pct=0 y t=n al antiguo pct=100, que es el comportamiento por defecto.
• rua= — la dirección que recibe los informes agregados diarios en XML. Es la etiqueta más útil de todo el registro.
• ruf= — informes forenses por mensaje. Muchos proveedores ya no los envían por privacidad; se puede omitir.

El error de DMARC más extendido es dejar p=none para siempre. Con p=none el dominio queda visible en los informes pero completamente desprotegido: cualquiera puede seguir suplantándolo y ningún receptor actuará, porque la política dice explícitamente que no haga nada. p=none es un punto de partida de dos a cuatro semanas, no un destino. Si el registro lleva un año en p=none, la protección real que ofrece es cero.

Cómo verificar los tres registros con herramientas gratuitas

Publicar los registros no es suficiente: hay que comprobar que se resuelven y que efectivamente autentican los mensajes. Hay tres niveles de verificación y conviene hacer los tres, porque cada uno detecta cosas distintas.

Nivel 1 — Consultar el DNS directamente. Es la comprobación más honesta porque muestra lo que el mundo ve, sin intermediarios. En Linux o macOS:

# SPF (y cualquier otro TXT del dominio)
dig +short TXT tudominio.com

# DKIM: reemplaza "google" por tu selector real
dig +short TXT google._domainkey.tudominio.com

# DMARC
dig +short TXT _dmarc.tudominio.com

# Registros MX: a qué servidor llega tu correo
dig +short MX tudominio.com

# Consultar contra un DNS público, saltándose la caché de tu red
dig +short TXT tudominio.com @8.8.8.8

En Windows, con PowerShell:

Resolve-DnsName -Type TXT tudominio.com
Resolve-DnsName -Type TXT _dmarc.tudominio.com
Resolve-DnsName -Type TXT google._domainkey.tudominio.com

Lo primero que hay que mirar en el resultado del SPF es si aparece más de una línea que empiece con v=spf1. Si aparecen dos, ese es el problema y hay que fusionarlas antes de seguir investigando cualquier otra cosa.

Nivel 2 — Verificadores web gratuitos. Analizan la sintaxis, cuentan las consultas DNS del SPF y avisan de errores que a simple vista no se ven:

• MXToolbox — comprobaciones de SPF, DKIM, DMARC, MX y listas negras.
• dmarcian SPF Surveyor — muestra el árbol de includes y cuenta las consultas DNS, ideal para diagnosticar el límite de diez.
• Toolbox de administrador de Google (CheckMX) — revisa la configuración completa del dominio según los criterios de Gmail.
• learndmarc.com — permite enviar un correo de prueba y ver paso a paso cómo se evalúan SPF, DKIM, la alineación y DMARC.

Nivel 3 — Enviar un correo real y analizarlo. Es la única prueba que confirma que la firma DKIM se está aplicando de verdad:

• mail-tester.com entrega una dirección temporal; le envías un correo desde tu sistema y devuelve una puntuación sobre 10 con el resultado de SPF, DKIM, DMARC, listas negras y contenido.
• Desde Gmail, abre el mensaje recibido, usa "Mostrar original" y busca la cabecera Authentication-Results. Debe decir spf=pass, dkim=pass y dmarc=pass. Si dice dkim=none, la firma no se está aplicando; si dice dkim=fail, la clave publicada no coincide con la que firma.

Una advertencia importante: prueba enviando desde cada sistema que envía correo en nombre del dominio, no solo desde el webmail. El formulario de contacto del sitio, la facturación electrónica, el CRM y la plataforma de campañas suelen usar servidores distintos, y es habitual que el webmail autentique perfecto mientras la facturación falla desde hace meses sin que nadie lo note.

Los diez errores más frecuentes y cómo se corrigen

Un plan de trabajo de cuatro semanas

Arreglar la entregabilidad no es un cambio de una tarde: es un proceso con un orden que evita cortar el correo legítimo mientras se avanza.

1. 1 Día 1 — Inventario. Anota todos los sistemas que envían correo con tu dominio: el proveedor de correo, el sitio web, el sistema de facturación electrónica, el CRM, la plataforma de campañas y cualquier aplicación interna. Esta lista es la parte más importante del proceso y la que casi nadie hace completa.
2. 2 Día 1 — Diagnóstico. Consulta los tres registros con dig, cuenta las consultas DNS del SPF con un verificador web y confirma si ya hay más de un registro SPF publicado.
3. 3 Día 2 — SPF y DKIM. Publica un único registro SPF con todos los sistemas del inventario, cerrado con ~all. Activa DKIM con clave de 2048 bits en el proveedor de correo y publica la clave pública en el DNS.
4. 4 Día 3 — DMARC en observación. Publica p=none con una dirección rua que puedas leer. A partir del día siguiente empezarán a llegar informes XML.
5. 5 Semanas 1 y 2 — Leer los informes. Los XML son incómodos de leer a mano; hay servicios gratuitos que los procesan y los muestran en tabla. Busca remitentes legítimos que estén fallando: ahí suelen aparecer sistemas que nadie recordaba.
6. 6 Semana 3 — Corregir y endurecer. Autoriza en SPF y DKIM los sistemas legítimos que aparecieron en los informes, y sube la política a p=quarantine.
7. 7 Semana 4 — Aplicación completa. Cuando los informes muestren que todo lo legítimo autentica, sube a p=reject, cambia el SPF a -all y añade sp=reject y np=reject. Deja el rua activo de forma permanente: es tu sistema de alarma.

Qué hace Terranode con esto

En el correo corporativo de Terranode, SPF, DKIM y DMARC forman parte de la puesta en marcha y de la migración gratuita, no son un servicio aparte. Al mover un dominio desde Gmail, Outlook o cualquier otro proveedor, los registros se configuran y se verifican antes de cambiar el registro MX, de modo que el correo autentique correctamente desde el primer mensaje que salga por el servidor nuevo.

Los planes de TerraMail cuestan 50 dólares al año con 50 GB y 90 dólares al año con 100 GB, con buzones y alias ilimitados, filtrado premium de spam con SpamExperts, webmail, ActiveSync y un límite de envío de 600 correos por hora. Ese límite horario existe precisamente para proteger la reputación de las IP de salida: una cuenta comprometida que intente enviar miles de mensajes se frena antes de arrastrar a los demás dominios de la plataforma. Los detalles están en la página de correo corporativo TerraMail.

Si tu dominio ya está en otro proveedor y solo necesitas que alguien revise por qué el correo cae en spam, el soporte en español atiende 24/7 y el diagnóstico de los registros no requiere cambiar de proveedor: los tres registros son públicos y se pueden auditar desde afuera.