Por qué tus correos van a spam, y qué ayuda de verdad
Los consejos habituales hablan del asunto. La entrega la deciden tres registros DNS, la reputación de tu dominio y la calidad de tu lista.
El guion suele ser siempre el mismo. La confirmación del formulario no llega nunca al cliente, la newsletter aparece en la carpeta de promociones o de spam de la mitad de los destinatarios, y la primera búsqueda de solución termina en una lista de palabras que hay que evitar en el asunto. Así que fuera el signo de exclamación y se reescribe "gratis". Después no cambia nada.
Ocurre porque ese consejo actúa sobre la palanca más pequeña. Un servidor de correo que recibe un mensaje pregunta primero quién escribe y solo después qué pone dentro. La primera pregunta la responden tres registros DNS y lo que tu dominio ha enviado en las últimas semanas. Nada de eso está en el asunto.
Este artículo ordena las palancas por efecto real. Al final sabrás qué registro te toca revisar primero.
El trabajo rinde en este orden
La mayoría de las listas de comprobación sobre entregabilidad mete veinte puntos en el mismo saco y no pondera ninguno. Ordenados por efecto, el asunto queda más claro:
- Autenticación. SPF, DKIM y DMARC están configurados y la alineación cuadra.
- Ruta de envío. Tus correos salen de un servidor que tus propios registros DNS autorizan a enviar por el dominio.
- Calidad de la lista. En la lista hay direcciones con consentimiento documentado y los rebotes se retiran.
- Reputación del remitente. El volumen y la frecuencia encajan con lo que ese dominio ha enviado hasta ahora.
- Contenido. Asunto, texto, proporción entre imagen y texto, número y destino de los enlaces.
El punto cinco es del que más se escribe. Solo empieza a contar cuando los cuatro anteriores están resueltos. Quien invierte el orden pule frases de un correo que el servidor receptor no sabe atribuir a nadie.
Qué comprueba de verdad cada uno de los tres
Los tres se nombran siempre juntos y se confunden con la misma frecuencia. Responden a tres preguntas distintas.
SPF dice qué servidores pueden enviar
SPF está descrito en el RFC 7208. Es un registro TXT en tu dominio donde consta qué servidores pueden entregar correo en nombre de ese dominio. El servidor que recibe compara la dirección IP del servidor que entrega con esa lista y obtiene una respuesta: si la ruta está permitida o no.
El segundo fallo más frecuente de la práctica está justo aquí. Evaluar un registro SPF puede provocar como máximo diez consultas DNS, y cada servicio incluido cuesta al menos una. Si vas añadiendo el proveedor del buzón, un servicio de newsletter, una herramienta de facturación y un sistema de tickets, en algún momento cruzas el límite. El resultado es un permerror, y un registro SPF con permerror no vale nada. En el panel de DNS sigue viéndose completamente normal.
DKIM demuestra que nada se alteró por el camino
DKIM está en el RFC 6376. Al enviar se añade una firma criptográfica en la cabecera del mensaje y la clave pública correspondiente vive en el DNS de tu dominio. Con eso el destinatario comprueba dos cosas a la vez: que el correo sale realmente de ese dominio y que la parte firmada llegó sin cambios.
DMARC une los dos resultados con una instrucción
DMARC está descrito en el RFC 7489 y es el registro que convierte dos resultados en una decisión. Ahí defines qué debe hacer quien recibe cuando la comprobación falla. Hay tres valores: none significa no hacer nada, quarantine significa a la carpeta de spam, reject significa rechazar. Además DMARC abre el canal de informes que te cuenta quién envía en tu nombre.
El error más habitual con diferencia: el registro está en p=none y se queda ahí para siempre. Como punto de partida es correcto, porque lo primero que quieres es ver qué sale con tu nombre. Como estado permanente es una línea en el DNS sin efecto. Un registro que va en serio acaba así:
_dmarc.tuempresa.es. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@tuempresa.es"La alineación es donde falla la mayoría de las configuraciones
Aquí está lo que casi ninguna guía cuenta. DMARC no comprueba solo si SPF o DKIM han pasado. Exige además que el dominio remitente visible coincida con el dominio que se comprobó. Eso se llama alineación, en inglés alignment, y es el término que verás en las herramientas.
En la práctica pasa esto. Envías tu newsletter con un servicio de envío. En el campo del remitente aparece tu propia dirección. Técnicamente, sin embargo, quien entrega es el servicio, y el servicio tiene un registro SPF impecable para su propio dominio. Así que SPF pasa. La firma también se aplica con el dominio del servicio. Para DMARC la escena queda así: se comprobó un dominio ajeno y el visible es el tuyo. La alineación falla, DMARC falla con ella, y cualquier herramienta de comprobación sigue mostrando un SPF en verde.
La salida es la misma en todos los proveedores serios: das de alta tu propio dominio en tu cuenta del servicio de envío y publicas en tu DNS la clave DKIM que te entrega para él. A partir de ahí la firma está emitida a nombre de tu dominio, la alineación cuadra y DMARC pasa.
Qué exigen Google, Yahoo y Microsoft a los remitentes masivos
Desde febrero de 2024, Google y Yahoo aplican requisitos a los remitentes masivos, o sea a grandes rasgos a quien envía más de unos 5.000 mensajes al día a cuentas de Gmail. Se exigen SPF, DKIM y DMARC, una baja en un clic que funcione en la cabecera del correo según el RFC 8058 y una tasa de quejas por spam por debajo del 0,3 por ciento. Microsoft anunció y aplicó requisitos comparables para Outlook.com en 2025.
Si estás muy por debajo de ese volumen, formalmente no cuentas como remitente masivo. Eso no cambia nada de la configuración: los tres registros te cuestan una hora una sola vez, la baja en un clic la pone tu herramienta de envío y la tasa de quejas depende del estado de tu lista con cualquier volumen. La única diferencia por debajo del umbral es que nadie te está midiendo.
Busca tu caso en esta tabla
| Síntoma | Causa probable | Cómo comprobarlo |
|---|---|---|
| Las confirmaciones de formulario no llegan a ninguna parte | Envío por la ruta estándar de PHP desde el servidor web, sin SPF y sin firma | Mirar las cabeceras de un correo de prueba y ver qué servidor lo entregó |
| Gmail acepta los correos, Outlook.com los aparta | Falta DMARC o está en p=none | Consultar el registro TXT bajo _dmarc y leer el valor detrás de p |
| La newsletter cae en spam, las facturas no | Dos rutas de envío, solo una firmada con tu dominio | Comparar la firma DKIM en la cabecera de los dos tipos de correo |
| SPF pasa y DMARC falla igualmente | Alineación: el dominio remitente visible no coincide con el comprobado | Mirar la línea Authentication-Results, ahí sale spf=pass junto a dmarc=fail |
| Las herramientas avisan de permerror en SPF | El registro provoca más de diez consultas DNS | Contar todos los include y quitar los servicios que ya no usas |
| Primero buena entrega y de repente spam | Volumen subido demasiado rápido o tasa de quejas al alza | Revisar los volúmenes de las últimas semanas y las bajas por envío |
Por qué el primer envío grande casi siempre se frena
Los sistemas que reciben llevan una especie de historial de cada dominio que envía. Un dominio que lleva años sin enviar nada y de pronto entrega 2.000 correos un martes por la mañana parece una cuenta secuestrada. Se le frena, y da igual lo limpios que estén los registros DNS.
La salida se llama calentamiento, warmup en las herramientas, y es poco espectacular. Empieza con poco y sube el volumen a lo largo de varias semanas. Arranca por los destinatarios que han abierto, hecho clic o comprado hace poco, porque su reacción es lo que construye tu reputación. Los contactos de los que hace tiempo que no sabes nada vienen después.
Si el contacto más reciente de tu lista tiene tres años, el calentamiento por sí solo sirve de poco. Entonces el trabajo con la lista va antes que el envío.
Una lista cuidada rinde más que cualquier retoque del texto
Las listas compradas, las direcciones que llevan años ahí y los rebotes que nadie atendió te cuestan más entregabilidad que cualquier palabra que hayas evitado en el asunto. El motivo es sencillo: cada correo a una dirección muerta y cada queja es una señal que cuenta directamente contra tu reputación.
Las reglas son cortas. Los hard bounces, o sea las direcciones definitivamente no entregables, salen de la lista de inmediato. Los soft bounces se pueden reintentar varias veces y luego se retiran. Una queja significa baja en el acto, sin preguntar. Las direcciones que llevan años sin abrir nada son un riesgo para todos los demás de la lista.
Al principio de todo está el consentimiento. Cómo es un doble opt-in limpio, qué hay que registrar y por qué eso también ayuda en lo técnico está en el artículo sobre el doble opt-in y el RGPD. Esto es una orientación práctica y no asesoramiento jurídico, para una valoración vinculante de tu caso necesitas a alguien con habilitación.
WordPress envía de fábrica por la ruta equivocada
Merece un apartado propio, porque en proyectos pequeños es la causa aislada más frecuente. WordPress envía a través de wp_mail y, sin más configuración, eso termina en la función mail() de PHP, que entrega el mensaje directamente al servidor web. Ese servidor web no suele estar en ningún registro SPF de tu dominio y tampoco firma nada. El correo sale y falla las dos comprobaciones a la vez.
La salida habitual es llevar el envío por SMTP o por la API de tu proveedor, con tu propio dominio verificado. Esto afecta a todo lo que tu web envía sola: confirmaciones de formulario, correos de restablecer contraseña, confirmaciones de pedido y facturas. Esos correos le importan al cliente más que cualquier newsletter, y son los que desaparecen de la forma más discreta.
Dónde estás perdiendo el tiempo
Queda la pregunta de qué se salva de los consejos habituales. Las palabras sospechosas en el asunto son el clásico, y hoy son en buena medida folclore. Los filtros valoran el comportamiento del remitente mucho más que una palabra suelta. La palabra "gratis" en el asunto no es un problema mientras el remitente tenga buena reputación, y no salva nada mientras no la tenga.
Con eso el trabajo sobre el asunto no queda sin sentido. Solo que rinde para la tasa de apertura y no para la entrega. Separar esas dos obras te ahorra un montón de reescrituras estériles.
p=none, tienes informes y ningún efecto. Si ahí no pone nada, ni siquiera tienes informes.Newsletter desde tu propio WordPress, con la entrega en mente
Kurato envía con tu propio acceso de proveedor y trae baja en un clic según el RFC 8058, gestión de rebotes y quejas y un semáforo de entregabilidad para SPF, DKIM y DMARC. Los datos de contacto se quedan en tu base de datos.
Lo que cubre la versión gratuita y dónde empieza Pro está en la página de precios. Por honestidad: las secuencias de automatización con ramas todavía están en construcción en Kurato.
Preguntas frecuentes
¿Qué diferencia hay entre SPF, DKIM y DMARC?
SPF (RFC 7208) dice qué servidores pueden enviar por tu dominio. DKIM (RFC 6376) añade una firma criptográfica con la que el destinatario comprueba que el correo sale de tu dominio y que no se alteró por el camino. DMARC (RFC 7489) une los dos resultados con una instrucción sobre qué hacer si la comprobación falla, y abre los informes. Solo los tres juntos dan una imagen completa.
Mi registro DMARC está en p=none. ¿Es suficiente?
Como punto de partida sí, como estado permanente no. Con p=none no pasa nada cuando una comprobación falla, solo recibes informes. El sentido de esa fase es ver durante unas semanas quién envía en tu nombre. Después la instrucción debe pasar a quarantine y más tarde a reject, si no el registro es una línea sin efecto.
SPF pasa y DMARC falla igualmente. ¿Cómo puede ser?
Casi siempre es la alineación. DMARC exige que el dominio remitente visible coincida con el dominio que comprobaron SPF o DKIM. Quien envía por un servicio de envío sin verificar y firmar allí su propio dominio pasa SPF por el dominio del servicio y falla en DMARC. La solución es la clave DKIM emitida para tu propio dominio.
¿Sirve de algo evitar palabras sospechosas en el asunto?
Muy poco. Los filtros actuales valoran el comportamiento del remitente mucho más que una palabra suelta. Un remitente con buena reputación pasa sin problema con la palabra gratis en el asunto, y uno sin reputación falla incluso con la fórmula más prudente. Trabajar el asunto rinde para la tasa de apertura, para la entrega aporta poco.
¿Por qué las confirmaciones de formulario de WordPress caen en spam?
Porque sin más configuración WordPress envía con la función mail() de PHP y el mensaje sale del servidor web. Ese servidor no suele estar en ningún registro SPF de tu dominio y no firma nada, así que SPF y DKIM fallan a la vez. Lo habitual es enviar por SMTP o por la API de tu proveedor con tu propio dominio verificado.
