Volver al blog

Por qué tus correos acaban en spam: SPF, DKIM y DMARC explicados

3 de noviembre de 2026PIMETIC
Por qué tus correos acaban en spam: SPF, DKIM y DMARC explicados

Has enviado un presupuesto, una factura o la confirmación de una cita, y días después el cliente dice que no le llegó nada. No está en su bandeja de entrada, tampoco en la papelera: está en spam. Desde tu lado el correo salió bien, sin errores, y aun así no llegó. Esa distancia entre «lo he enviado» y «lo ha recibido» es la que conviene entender, porque en una pyme suele costar clientes y no siempre se nota a tiempo.

El problema casi nunca está en el texto del mensaje. Está en lo que el proveedor del destinatario puede comprobar sobre tu dominio antes de decidir si se fía. Gmail, Outlook y el resto de servicios grandes ya no valoran solo el contenido: miran si tu dominio dice quién puede enviar en su nombre, si el mensaje lleva una firma verificable y si has publicado una política para cuando algo no cuadra. Son tres mecanismos con nombres poco amables (SPF, DKIM y DMARC) y una lógica bastante sencilla cuando se explican en orden.

Qué comprueba un proveedor antes de dejar entrar un correo

Cuando un mensaje llega a un servidor de destino, este hace varias preguntas rápidas y automáticas antes de mostrarlo. Si las respuestas no le convencen, no lo borra: lo degrada. Lo pone en la carpeta de spam, lo marca como sospechoso o simplemente lo retrasa. En la práctica, estas son las comprobaciones que más peso tienen:

  • Si el servidor que envía está autorizado por el dominio que aparece en la dirección del remitente.
  • Si el mensaje lleva una firma que demuestre que salió de quien dice, y que nadie lo ha manipulado por el camino.
  • Si el dominio ha declarado qué hacer con los mensajes que fallan esas comprobaciones.
  • Si el comportamiento reciente es razonable: volumen, quejas de los destinatarios, direcciones que rebotan una y otra vez.

Las tres primeras son configuración pura y se resuelven una vez. La cuarta es reputación, se construye con el tiempo y se estropea rápido.

SPF: quién tiene permiso para enviar en tu nombre

El SPF (Sender Policy Framework) es un registro de texto que se publica en el DNS del dominio y contiene la lista de servidores autorizados a enviar correo en su nombre. Cuando alguien recibe un mensaje tuyo, consulta ese registro y comprueba si la máquina que lo envió está en la lista.

Su utilidad se ve mejor con un ejemplo. Si tu dominio no publica ningún registro SPF, cualquiera puede enviar mensajes con tu dirección como remitente y el receptor no tiene forma de distinguirlo de un envío legítimo. Con el registro bien puesto, ese envío falso hará fallar la comprobación. La especificación oficial, el RFC 7208 (los RFC son los documentos numerados en los que se publican los estándares de internet), define el formato y también un detalle que provoca muchos dolores de cabeza: durante la evaluación solo se permiten diez consultas DNS. Si el registro encadena demasiados «include», el resultado es un error y el correo puede acabar rechazado aunque esté todo bien puesto de intención.

Ahí está el primer fallo típico de pyme: se añade la herramienta de mailing, luego la plataforma de facturación, luego la web que envía formularios, y nadie revisa el conjunto. Cada proveedor nuevo necesita estar en el registro, y el registro tiene un límite. Cuando se supera, lo que falla es todo, no solo el último añadido.

DKIM: la firma que demuestra que el mensaje salió de ti

El DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada mensaje. El servidor que envía firma con una clave privada y el receptor verifica esa firma con la clave pública que tu dominio publica en el DNS. Si el mensaje se modifica por el camino, la firma deja de cuadrar. La base técnica está en el RFC 6376.

Esto resuelve un problema que el SPF no cubre. El SPF valida la máquina que envía, pero no el contenido ni la integridad del mensaje. El DKIM sí: confirma que lo que llegó es lo que salió. También sobrevive mejor a los reenvíos, un escenario habitual en muchas empresas donde una secretaría redirige el correo de un buzón genérico a dos o tres personas. En esos reenvíos el SPF suele romperse, porque el mensaje sale desde un servidor distinto del original, pero la firma DKIM viaja con el mensaje y sigue siendo válida.

Hay un detalle práctico que se pasa por alto: la longitud de la clave. Google exige un mínimo de 1024 bits para entregar correo a cuentas personales de Gmail y recomienda 2048 en sus directrices para remitentes. Si tu proveedor de correo firmó con una clave antigua y corta, el mensaje puede pasar la comprobación a medias y aun así perder credibilidad.

DMARC: qué hacer cuando algo no cuadra

El DMARC es la pieza que une las dos anteriores y les da una consecuencia. Su idea central es la alineación: no basta con que pase el SPF o el DKIM, el dominio que los supera tiene que coincidir con el dominio que el destinatario ve en la dirección del remitente. Si alguien envía con tu nombre usando un servidor autorizado por otro dominio, el SPF puede pasar y el DMARC fallar.

El dominio publica además una política, que puede ser de tres tipos: no hacer nada y solo observar, marcar como sospechoso, o rechazar. Y puede pedir informes a los receptores, que llegan como resúmenes periódicos y permiten ver quién está enviando en tu nombre, incluidos los que no deberían. La especificación vigente es el RFC 9989, publicado en mayo de 2026, que sustituye al antiguo RFC 7489. Entre otros cambios, retira la etiqueta que permitía aplicar la política solo a un porcentaje de los mensajes, una costumbre muy extendida para probar sin riesgo.

La forma sensata de implantarlo no es empezar por el rechazo. Se empieza observando unas semanas, se leen los informes, se corrigen los envíos legítimos que estaban fuera de la alineación y solo entonces se endurece la política. Lo contrario, activar el rechazo el primer día, es una forma muy eficaz de dejar de recibir el correo de tu propia web.

Estas son las tres piezas, resumidas para tenerlas a mano:

Mecanismo Qué demuestra Qué pasa si falta
SPF Que el servidor que envía está autorizado por tu dominio Cualquiera puede suplantar tu dirección sin obstáculos
DKIM Que el mensaje salió de ti y no se ha modificado Los reenvíos y las listas pierden credibilidad
DMARC Que la identidad visible coincide con la autenticada, y qué hacer si no No hay política ni informes: nadie sabe quién envía en tu nombre

Los fallos que más se repiten en una pyme

En la práctica, el correo de una empresa pequeña no suele fallar por un ataque, sino por acumulación de cambios sin revisar. Estos son los casos que aparecen una y otra vez cuando se audita una configuración:

  • Un proveedor nuevo que no está en el SPF: se contrata una plataforma de newsletter o un CRM y nadie añade sus servidores al registro. Los envíos salen, pero con la reputación dañada desde el primer día.
  • El registro SPF duplicado: al cambiar de proveedor se añade un segundo registro en lugar de editar el existente. Dos registros SPF en el mismo dominio es un error, no una suma.
  • El DKIM sin activar en el proveedor: muchas plataformas lo ofrecen y no viene activo por defecto. Hay que entrar, generarlo y publicar la clave.
  • El dominio de envío distinto del de la web: se envía desde un dominio parecido al corporativo y el destinatario ve una dirección que no reconoce. La alineación falla y la confianza también.
  • Listas antiguas y direcciones que rebotan: seguir escribiendo a direcciones que ya no existen es una de las formas más rápidas de perder reputación.

Cómo comprobarlo sin ser técnico

No hace falta ser administrador de sistemas para tener una idea clara del estado de tu correo. Con estas comprobaciones se detecta la mayor parte de los problemas:

  1. Pide a alguien de fuera de la empresa que te envíe un correo y revisa las cabeceras del mensaje recibido (la información técnica que viaja con cada correo y que no se ve a simple vista: en Gmail está en «Mostrar original» y en Outlook, con el mensaje abierto, en Archivo > Propiedades, apartado «Encabezados de Internet»): ahí aparecen los resultados de SPF, DKIM y DMARC.
  2. Envía un mensaje de prueba a una cuenta de Gmail y otra de Outlook, y mira en cuál de las dos acaba en spam.
  3. Comprueba los registros publicados de tu dominio con cualquiera de las herramientas públicas de consulta de DNS: deben existir, ser únicos y estar bien formados.
  4. Revisa la lista de servicios que envían correo en tu nombre. Si no la tienes escrita, ese es el primer problema a resolver.

Ese último punto es el que más veces se olvida. Cuando alguien pregunta «¿quién envía correo con nuestro dominio?» y la respuesta se improvisa, la configuración ya está desactualizada.

No todo es configuración: los hábitos también cuentan

Una configuración impecable no salva una mala práctica de envío. Si se escribe a personas que no han dado su consentimiento, si se compran listas o si se manda la misma comunicación a toda la base cada semana sin criterio, la reputación cae y el filtro actúa. Y hay un motivo legal además del técnico: la normativa de protección de datos exige una base para tratar la dirección de correo y ofrecer una forma sencilla de darse de baja.

Conviene también distinguir dos problemas que se confunden a menudo. Que un correo acabe en spam es un asunto de configuración y reputación. Que un mensaje llegue con un remitente falso suplantando a un proveedor o a un compañero es otra cosa: eso es phishing, y ahí lo que toca es reconocer el engaño antes de responder. La autenticación de dominio ayuda en los dos casos, porque reduce el margen de los suplantadores, pero no sustituye la formación de las personas ni unas contraseñas seguras, que siguen siendo la última barrera cuando el engaño llega igualmente.

Un repaso anual basta para no volver a empezar

La buena noticia es que esto no es un proyecto eterno. Una vez publicados los tres registros y alineados los servicios que envían correo, el mantenimiento se reduce a revisarlos cuando algo cambia: un proveedor nuevo, una migración de correo, un cambio de web. Ese momento, que suele coincidir con una urgencia, es justo el peor para descubrir que el registro SPF llevaba meses superando el límite de consultas.

Por eso merece la pena tratarlo como cualquier otra pieza de la infraestructura: con una lista escrita de servicios, una comprobación periódica y alguien que sepa qué mirar cuando un cliente dice que no le llega nada. Es un trabajo pequeño, casi nadie lo revisa, y explica por qué tantas empresas descubren el problema justo cuando más les importaba que ese correo llegara.

Si no sabes en qué estado está tu correo o quieres que lo revisemos contigo, puedes hablar con nosotros y miramos la configuración real de tu dominio.

¿Te ha sido útil este artículo?

¿Necesitas ayuda con tu informática?

Somos PIMETIC, tu partner tecnológico. Contáctanos y te ayudamos.

Contactar con PIMETIC

Consentimiento de cookies

Utilizamos cookies para mejorar tu experiencia de navegación. Consulta nuestra política de cookies para más información.