Cuando analizas suficientes dominios, dejas de ver casos únicos y empiezas a ver patrones. Hay tres fallos de configuración de correo que aparecen una y otra vez, en empresas de todo tipo y tamaño, y que casi siempre pasan desapercibidos porque no dan la cara hasta que ya han hecho daño. Estos son los tres, por si reconoces alguno en tu propia empresa.
1. DMARC en `p=none` para siempre (o directamente ausente)
El más común con diferencia. O bien no hay registro DMARC —el dominio está completamente abierto a la suplantación—, o bien hay uno en `p=none` que se publicó hace tiempo y ahí se quedó.
El problema de `p=none` es que da una falsa sensación de estar cubierto. Marca la casilla de «tengo DMARC», pero no bloquea absolutamente nada: cualquiera puede seguir enviando correos falsificando el dominio. Es como tener una alarma instalada pero nunca activada. La empresa cree que está protegida y no lo está.
Por qué pasa desapercibido: como `p=none` no rompe nada, tampoco avisa de nada. Todo parece funcionar. El fallo solo se hace visible el día que alguien suplanta el dominio, y para entonces ya es tarde.
2. SPF que ha superado el límite de consultas
El segundo clásico. El registro SPF tiene un tope de 10 consultas DNS, y muchas empresas lo han superado sin saberlo, simplemente por acumular herramientas de envío a lo largo del tiempo: el correo corporativo, la facturación, el marketing, el CRM… cada una añadió su parte, y en algún momento se cruzó la línea.
Cuando eso ocurre, el SPF entra en error permanente y deja de funcionar del todo. La entregabilidad se resiente, los correos empiezan a caer más en spam, algunos rebotan.
Por qué pasa desapercibido: el deterioro es gradual y silencioso. Nadie relaciona «algunos correos van a spam» con «el SPF tiene una consulta de más». Se echa la culpa al contenido o al proveedor, y el fallo real sigue ahí.
3. Fuentes legítimas que no alinean
El más técnico de los tres, y por eso el que más se escapa. Una herramienta envía correo en nombre del dominio de la empresa, pero firma con su propio dominio en lugar del de la marca. Técnicamente autentica —pasa SPF o DKIM—, pero no *alinea*: el dominio del «De:» no coincide con el dominio validado. Y para DMARC, sin alineación no hay validación.
El resultado: correos legítimos de una herramienta real que fallan DMARC. Mientras la política esté en `p=none` no se nota, pero en cuanto la empresa intenta subir a `reject`, esos correos empiezan a bloquearse. Es la razón número uno por la que los despliegues hechos con prisa rompen envíos legítimos.
Por qué pasa desapercibido: requiere leer los reportes y entender la diferencia entre autenticar y alinear. Sin ese análisis, la fuente parece que «funciona» hasta que deja de hacerlo.
El patrón detrás de los tres
Si te fijas, los tres fallos tienen algo en común: ninguno da síntomas evidentes hasta que causa un problema . El dominio parece funcionar, los correos parecen salir, y por eso nadie revisa. La configuración de correo es de esas cosas que se dan por hechas justo porque no protestan.
Y los tres se detectan de la misma forma: analizando los registros del dominio y los reportes que genera. No hay que adivinar; está todo en los datos, solo hay que mirarlos.
Comprueba si tu dominio tiene alguno
Lo más probable, por pura estadística, es que tu dominio tenga al menos uno de estos tres fallos ahora mismo. Saber cuál —y cómo de grave es— es exactamente lo que hacemos en el diagnóstico: revisamos tu configuración, contamos las consultas de tu SPF, comprobamos tu política DMARC y detectamos qué fuentes no alinean.
Pide tu diagnóstico gratuito y averigua cuál de estos tres tienes, antes de que dé la cara.