Es una de las consultas que más nos llegan a soporte: "mando un correo desde el formulario de la web o desde la tienda y acaba en spam". Casi siempre son tres registros DNS incompletos, o puestos en el orden equivocado.
Un poco de contexto de por qué ahora pasa más: desde febrero de 2024 Gmail y Yahoo exigen autenticar el correo con SPF o DKIM, y DMARC a quien envía mucho volumen. Microsoft hizo lo mismo en Outlook y Hotmail en mayo de 2025. Y desde noviembre de 2025 Google ya rechaza parte del correo que no cumple, en vez de mandarlo a la carpeta de spam. Antes "llegaba igual"; ahora no.
**Paso 0: haz el inventario antes de tocar el DNS**
Tu dominio probablemente envía desde más sitios de los que crees: el hosting (formularios, avisos), el servidor de correo, la herramienta de newsletters, la tienda, el CRM o el programa de facturación. Apunta cada servicio, qué envía, con qué dirección y si permite firmar con DKIM con tu dominio. Si te salta este paso, lo siguiente te va a fallar.
**SPF: quién puede enviar en tu nombre**
Es un registro TXT con la lista de servidores autorizados. Dos cosas que rompen más SPF que ninguna otra:
– **Solo puede haber un registro SPF por dominio.** Dos registros se consideran error y el SPF deja de valer. Para añadir un servicio se amplía el que ya tienes:
“`
v=spf1 +a +mx ip4:203.0.113.10 include:relay.mailchannels.net ~all
“`
y al añadir la newsletter, el include va antes de `~all`:
“`
v=spf1 +a +mx ip4:203.0.113.10 include:relay.mailchannels.net include:spf.ejemplo-newsletter.com ~all
“`
– **Límite de 10 consultas DNS.** Cuentan `include`, `a`, `mx`, `exists` y `redirect`, también los anidados. Las `ip4` e `ip6` no cuentan. Si te pasas, el SPF falla sin avisar de nada. Se arregla quitando servicios que ya no usas o poniendo las IP fijas con `ip4:` (con el riesgo de que el proveedor las cambie).
Sobre el final: `~all` marca como sospechoso lo que no esté en la lista, `-all` pide rechazarlo. Empieza por `~all` y pasa a `-all` cuando el inventario esté completo y DMARC funcione.
**DKIM: la firma del mensaje**
Cada mensaje se firma con una clave privada y la pública se publica en el DNS como `selector._domainkey.tudominio.com`. Demuestra que el mensaje no se ha modificado y qué dominio lo firmó. Importante: **DKIM se activa servicio por servicio**, buscando en cada herramienta la opción de "autenticar dominio" o "DKIM personalizado". En cPanel lo tienes en Correo electrónico → Email Deliverability.
**Alineación: el fallo que no se ve**
Este es el que más tiempo nos hace perder. DMARC no solo pide que SPF o DKIM pasen: pide que el dominio validado coincida con el del campo From. Basta con uno de los dos, pero alineado.
El caso típico: una herramienta externa envía con tu nombre pero usando su propio dominio. SPF pasa, DKIM pasa, y DMARC falla igualmente. Para comprobarlo, en Gmail abre "Mostrar original" y mira la línea `Authentication-Results`. Por defecto la alineación es relajada, así que un subdominio tipo `news.tudominio.com` cuenta como el dominio principal.
**DMARC: por fases, nunca directo a reject**
Es un TXT en `_dmarc.tudominio.com`. Publicar `p=reject` el primer día es la forma más rápida de tirar el correo de un servicio que no sabías que existía.
| Fase | Registro | Duración |
|—|—|—|
| 1 | `v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com` | 2-4 semanas |
| 2 | `v=DMARC1; p=quarantine; rua=mailto:dmarc@tudominio.com` | 2-4 semanas |
| 3 | `v=DMARC1; p=reject; rua=mailto:dmarc@tudominio.com` | solo si la fase 2 está limpia |
La etiqueta `rua` no es opcional en la práctica: sin ella no recibes informes y estás a ciegas. Los informes llegan en XML comprimido; lo que hay que mirar es `<source\_ip>` y `<count>` (quién envía y cuánto), `<policy\_evaluated>` (resultado con alineación) y `<auth\_results>` (qué dominio validó cada mecanismo). Una IP desconocida enviando mucho en tu nombre es suplantación.
**Síntomas y causa probable**
– Va a spam en Gmail pero no en otros: falta DKIM o DMARC, o la alineación está rota.
– Las facturas de la tienda no llegan: el servidor web no está en el SPF, o la tienda no firma con DKIM.
– Funciona desde el programa de correo pero no desde la web: son dos canales de envío y solo uno está autenticado.
– Empezó justo al contratar la newsletter: o hay dos registros SPF, o te has pasado de las 10 consultas.
**Comprobación en cinco minutos**
“`
dig +short TXT tudominio.com
dig +short TXT default._domainkey.tudominio.com
dig +short TXT _dmarc.tudominio.com
“`
Qué tiene que salir: un único SPF terminado en `~all` o `-all`; una clave después de `p=` en el DKIM (`default` es el selector habitual en cPanel, otros servicios usan el suyo); y un `v=DMARC1` con `p=` y `rua=`. Y luego la prueba de verdad: manda un correo desde cada canal a una cuenta de Gmail y comprueba que aparece `dmarc=pass` en "Mostrar original".
**Lo que esto no arregla**
Autenticar demuestra el origen, no la calidad. Con listas compradas, contenido con pinta de spam o muchas quejas vas a entregar mal aunque el DNS esté perfecto (Google recomienda estar por debajo del 0,1% de quejas). Y el hosting tiene límites de envío por diseño: en nuestro caso 480 correos cada 15 minutos. Para envíos masivos toca una herramienta de email marketing, con su DKIM propio bien alineado.
¿Cuál habéis tenido vosotros: el SPF duplicado, las 10 consultas o la alineación? Si queréis, pongo en comentarios la guía completa con los ejemplos de configuración y el apartado de lectura de informes DMARC.
Source: r/NicaliaHosting · by /u/Nicalia-Hosting-SPA