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

Cuando un correo tuyo llega a la carpeta de spam, el texto casi nunca tiene la culpa. Lo habitual es que el servidor que lo recibe no pueda comprobar que lo has enviado tú. Esa comprobación depende de tres registros DNS de tu dominio, SPF, DKIM y DMARC, y en las 230 webs de pymes de Madrid que auditamos en septiembre de 2026, solo el 17 % lo tenía bien configurado.

Qué comprueba Gmail cuando recibe un correo tuyo

Piensa en el correo como una carta con tu nombre en el remite. Cualquiera puede escribir tu nombre en un sobre. El servidor que la recibe, Gmail o Outlook, tiene que decidir en milisegundos si el sobre viene de verdad de tu empresa o de alguien que se hace pasar por ti. Para decidirlo mira tres cosas en el DNS de tu dominio, que es el sitio donde tú publicas las reglas de tu nombre.

SPF es la lista de carteros autorizados. Un registro de texto en tu dominio que dice "los correos de miempresa.es solo pueden salir de estos servidores". Si el correo llega desde un servidor que no está en la lista, falla. La lista tiene que incluir a todo el que envíe con tu nombre: tu proveedor de correo, el programa de facturación, la herramienta del boletín y la propia web si manda avisos.

DKIM es el sello de lacre. Tu servidor firma cada correo con una clave privada, y en el DNS publicas la clave pública para que cualquiera pueda verificar la firma. Si alguien cambia una coma por el camino, o falsifica el remite, el sello no cuadra. A diferencia de SPF, el sello sobrevive a los reenvíos.

DMARC es la instrucción de qué hacer con las cartas sospechosas. Otro registro de texto, esta vez en _dmarc.miempresa.es, que dice al receptor tres cosas: qué hacer si SPF y DKIM fallan (nada, cuarentena o rechazo), que el dominio del remite tiene que coincidir con el que pasa SPF o DKIM (lo que llaman alineación) y a qué dirección enviar un informe diario con lo que han visto. Sin DMARC, los dos controles anteriores existen pero nadie manda cumplirlos.

Lo que piden Google, Yahoo y Microsoft desde 2024

En febrero de 2024 Google y Yahoo empezaron a aplicar requisitos a todo el que envía correo a sus usuarios. Microsoft hizo lo mismo con Outlook y Hotmail el 5 de mayo de 2025. No son recomendaciones. Google pasó de mandar los correos a spam a rechazarlos con un error 5xx en noviembre de 2025, y el remitente recibe un rebote con el código 5.7.26 que no explica gran cosa a quien no sabe qué buscar.

Los 5.000 correos al día parecen lejos para una pyme, pero Google los cuenta por dominio y en cualquier día del año. Una tienda que manda un boletín a su lista de clientes el día de una campaña puede pasar el umbral una vez y quedar marcada como remitente masivo. Y aunque no llegues, la columna de la izquierda ya te obliga a tener SPF o DKIM y un PTR correcto, que es justo lo que suele faltar en los servidores compartidos baratos.

Sin DMARC, cualquiera envía en tu nombre

Y nadie va a impedirlo. Sin una política publicada, el servidor que recibe un correo falso con tu remite no tiene instrucciones, así que lo entrega, lo manda a spam o lo rechaza según su criterio. Tú no te enteras de nada, porque tampoco has pedido informes.

En las auditorías el patrón se repite. El dominio tiene SPF porque el proveedor de hosting lo puso al crear el correo, DKIM a veces, y DMARC casi nunca, porque nadie lo pone por defecto. La empresa lleva años así y no ha notado nada. Hasta que cambia de proveedor de facturación, o empieza a mandar un boletín, o un cliente le dice que su presupuesto ha llegado a spam. Entonces se busca al culpable en el texto del correo, se quitan las mayúsculas del asunto, y el problema sigue.

Hay un segundo efecto menos visible. Cuando alguien usa tu dominio para enviar phishing, aunque sea a gente que no conoces, la reputación de tu dominio baja en los filtros de Google y Microsoft. Y esa reputación es la misma que usan después para decidir dónde va tu factura legítima. DMARC con informes es la única forma de saber que está pasando.

Los cinco errores que más vemos

Varios registros SPF. El estándar solo admite uno. Cuando hay dos, los receptores lo tratan como error permanente y es como no tener ninguno. Suele ocurrir porque cada proveedor nuevo (el correo, el boletín, el CRM, la facturación) te da su línea para "añadir al DNS" y se añade tal cual en vez de unirla a la que ya había.

Más de diez consultas DNS en el SPF. Cada include: cuenta, y los que hay dentro de ese include también. Diez es el límite. Google Workspace gasta varias con su include, un servicio de boletines otras tantas, el programa de facturación uno más, y de pronto el registro es demasiado largo de evaluar y falla aunque todo esté bien escrito. La solución es aplanar el registro o quitar servicios que ya no se usan.

DKIM que firma pero no alinea. Tu proveedor de boletines firma con su dominio, no con el tuyo. Para DMARC eso no vale. Hay que activar en ese servicio la firma con tu propio dominio, lo que normalmente son dos registros CNAME que te dan en su panel y que casi nadie llega a poner.

p=reject el primer día. Es tentador poner la política más dura de golpe, y es la forma más rápida de perder correos legítimos. Si el programa de facturación envía las facturas desde tu dominio sin estar en el SPF, con p=reject dejan de llegar y te enteras cuando un cliente dice que no ha recibido nada. Por eso DMARC tiene el modo none: publica, recibe informes, corrige y sube.

El formulario de la web que envía "desde" el correo del cliente. Muchos formularios de contacto de WordPress ponen en el remite la dirección que ha escrito el visitante, para que al responder salga su nombre. Si ese visitante tiene Gmail, tu servidor está enviando un correo con remite de gmail.com sin ser Google. Falla SPF, falla DKIM y Gmail lo rechaza. El resultado es que no recibes los mensajes de tu propia web y no lo sabes. El remite tiene que ser una dirección de tu dominio y la del cliente va en "Responder a".

Compruébalo tú en diez minutos

No hace falta tocar nada ni pedir acceso al hosting. Con el nombre del dominio basta.

1. Entra en MXToolbox (mxtoolbox.com), escribe tu dominio y elige "SPF Record Lookup". Tiene que salir un solo registro que empiece por v=spf1 y termine en -all o ~all. Si salen dos, o ninguno, ya tienes el primer problema. La misma herramienta te dice cuántas consultas DNS gasta.
2. En la misma web, elige "DMARC Lookup". Si no hay registro, verás un aviso en rojo. Si lo hay, mira qué dice detrás de p= y si tiene una dirección en rua=. Si prefieres la consola, en Windows es nslookup -type=txt _dmarc.tudominio.es.
3. Envíate un correo desde tu cuenta de empresa a una cuenta de Gmail. Ábrelo en Gmail, pulsa los tres puntos y "Mostrar original". Las tres primeras líneas dicen SPF, DKIM y DMARC con PASS o FAIL. Repite la prueba desde el formulario de la web y desde el programa de facturación, que son las que suelen fallar.
4. Si tienes DMARC con informes, abre uno de los que llegan cada día (son XML comprimidos, se leen mejor pegándolos en dmarcian.com o en la herramienta de MXToolbox). Verás cada IP que ha enviado en tu nombre y si ha pasado o no. Las que no reconozcas son el motivo por el que no puedes poner reject todavía.

Cómo se arregla y cuánto cuesta

El arreglo casi nunca es complicado. Se inventaría quién envía con tu dominio (correo, web, facturación, CRM, boletín), se escribe un solo SPF que los incluya a todos sin pasar de diez consultas, se activa DKIM en cada servicio con tu dominio, se publica DMARC en p=none con una dirección para los informes y se revisa a las dos semanas. Si los informes están limpios, se sube a quarantine y al mes a reject.

En la mayoría de casos eso es una hora de trabajo a 65 € sin IVA, más una revisión corta al cabo de un mes. Cuando hay muchos servicios enviando o el hosting no permite editar el DNS con comodidad puede llevar dos. Si tienes el plan Básico de mantenimiento (49 €/mes) está incluido en la puesta en marcha, y los buzones de correo profesional que damos a 3 € por buzón salen con SPF, DKIM y DMARC configurados y alineados desde el primer día.

Lo que sí depende de cada caso es el paso a reject. Hay empresas que tardan un mes en tener todos los envíos alineados porque el programa de gestión que usan no admite DKIM, y ahí la salida es cambiar el remite de ese programa a un subdominio o hacer que pase por un servidor de correo que sí firme. Se decide con los informes delante, no antes.

Nuestra auditoría gratuita comprueba SPF, DKIM y DMARC de tu dominio junto con el resto de la web. Si sale algo en rojo, te dice qué es y qué haría yo primero. Y si prefieres hacerlo tú, los cuatro pasos de arriba te dan la misma información.