Cumplimiento para remitentes masivos

¿Cuáles son las cuatro obligaciones, en lenguaje claro?

Por debajo de la jerga, lo que exigen los proveedores se reduce a cuatro cosas. La primera es autenticar: publicar SPF y DKIM para tu dominio, y un registro DMARC válido cuya alineación pase por SPF o por DKIM, de modo que el dominio que firma coincida con el que se ve en el remitente. La segunda es no enviar correo no deseado, medido como una tasa de quejas por debajo de un límite que detallamos más abajo. La tercera es facilitar la baja: un mecanismo de baja en un clic, legible por máquina, en el correo de marketing, además de un enlace de baja visible en el cuerpo. La cuarta, menos comentada, es tener la infraestructura en orden: registro PTR de DNS inverso para tus IPs, TLS en las conexiones y un nombre de saludo (HELO) válido y coherente. Tres de las cuatro se configuran una vez y se vigilan; la de las quejas depende de cómo y a quién envías cada día, y es la que más remitentes subestima.

SPF, DKIM y DMARC: qué comprueba cada proveedor

La autenticación es la pata que más confusión genera, porque pasar cada protocolo por separado no basta. SPF declara qué servidores pueden enviar en nombre de tu dominio, y se comprueba contra el dominio del sobre (el «return-path»). DKIM firma el mensaje con una clave cuya pública vive en tu DNS, de modo que el receptor verifica que el contenido y la cabecera no se alteraron. DMARC es la capa que ata las dos anteriores al dominio que el destinatario ve en el «De», y aquí está el matiz que tumba a muchos remitentes correctos: lo que exigen los proveedores es alineación, es decir, que el dominio que pasa SPF o DKIM coincida con el del remitente visible. Un correo puede pasar SPF y DKIM y aun así fallar DMARC si esos dominios no alinean, que es el caso típico cuando un proveedor de terceros envía con su propio return-path. Los tres grandes piden lo mismo en el fondo —SPF, DKIM y un DMARC válido que alinee por una de las dos vías—, así que el trabajo consiste en cerrar la alineación, leer los informes agregados y subir la política cuando los datos respaldan el cambio.

Los requisitos sin número: PTR, TLS y formato

Por debajo de las cuatro obligaciones grandes hay una capa de higiene técnica que no lleva una cifra llamativa y que, precisamente por eso, se olvida. Tus IPs de envío necesitan un registro PTR de DNS inverso que resuelva a un nombre coherente con el dominio de envío; una IP sin PTR, o con uno genérico del proveedor de alojamiento, es una señal de aficionado que los filtros penalizan. Las conexiones deben negociar TLS: el correo en claro entre servidores está, a efectos prácticos, descartado. El nombre de saludo SMTP (HELO/EHLO) tiene que ser un nombre de dominio válido y estable, en vez de una cadena improvisada. Y el formato del propio mensaje importa: cabeceras bien formadas conforme a los estándares, un «De» que no cambie de un envío a otro y una estructura que no parezca la de un correo fabricado para esquivar filtros. Nada de esto es difícil, pero su ausencia mina la confianza acumulada por la autenticación bien hecha.

La baja en un clic, bien hecha

La baja en un clic conforme a la RFC 8058 consiste en dos cabeceras —List-Unsubscribe y List-Unsubscribe-Post— que permiten al buzón mostrar un botón de baja nativo junto al nombre del remitente. Cuando el destinatario lo pulsa, el proveedor envía una petición POST a tu servidor y la persona queda dada de baja sin pasar por una página de preferencias. El sentido es darle una salida cómoda distinta del botón de «marcar como spam», porque una baja no daña tu reputación y una queja de spam sí. Tres matices marcan la diferencia entre cumplir y tropezar. Primero, aplica al correo de marketing y promocional; el transaccional queda fuera, y conviene no poner estas cabeceras en recibos o restablecimientos de contraseña, donde una baja accidental haría daño. Segundo, hay que respetar la baja en un plazo breve, del orden de dos días. Tercero, el botón nativo no sustituye al enlace de baja visible en el cuerpo: los proveedores siguen esperando ambos.

La tasa de quejas, en detalle

De todas las métricas, esta es la que manda sobre las demás: una autenticación impecable no te salva si la gente marca tu correo como spam. La cifra de trabajo es mantenerse por debajo del 0,10%; el 0,30% —tres quejas por cada mil correos— es la línea donde los proveedores actúan al margen de lo limpia que esté tu configuración. Se calcula a diario, dividiendo las veces que alguien pulsa «marcar como spam» entre el correo entregado, de modo que un volumen bajo es engañosamente frágil: a quien entrega 10.000 mensajes le bastan 30 quejas para tocar el 0,30%. El 0,10% no es una aspiración elegante, es el techo de un remitente estable; vivir entre el 0,10% y el 0,30% significa estar ya en terreno de aviso, perdiendo acceso a las vías de mitigación antes de cruzar el precipicio. Cuando la tasa sube, el primer reflejo correcto es bajar el ritmo y revisar a quién se envía, en lugar de empujar más volumen contra una reputación que se deteriora.

¿Dónde divergen los proveedores?

Las cifras parecen idénticas; el cálculo que hay detrás, no. Yahoo mide la tasa de quejas usando como denominador solo el correo entregado en bandeja, excluyendo lo que fue a la carpeta de spam, mientras que Google la calcula sobre todo lo entregado. Con el mismo número de quejas, el denominador menor de Yahoo arroja un porcentaje mayor, así que un remitente correcto en Google puede estar por encima del límite en Yahoo con idéntico comportamiento. La medición también difiere: Google retiró su panel clásico de Postmaster Tools en octubre de 2025 y lo sustituyó por una versión nueva con un estado de cumplimiento binario —cumples o no cumples— que señala exactamente qué requisito estás fallando; Yahoo trabaja con su propio bucle de retroalimentación de quejas, y Microsoft expone datos a través de SNDS y de sus paneles. La lección operativa es vigilar cada panel por separado y no dar por bueno un proveedor a partir de otro.

Correo en frío y prospección individual

Conviene decirlo con claridad porque genera confusión: estas reglas no prohíben el correo en frío. Lo que hacen es endurecer el entorno donde el correo en frío más fácil incumple. La prospección en frío produce más quejas que ninguna otra categoría, por la sencilla razón de que el destinatario no pidió el mensaje; donde una lista de marketing bien cuidada se mantiene por debajo del 0,1%, una campaña en frío descuidada roza el 0,5% o el 1% sin esfuerzo. El umbral del 0,30% parece generoso hasta que se cae en la cuenta de esos números. Para quien hace prospección legítima, el camino pasa por una segmentación estrecha, una higiene de listas seria y un calentamiento previo de dominios e IPs; el envío masivo en frío desde infraestructura nueva y sin calentar es la receta más fiable para tocar el límite el primer día. Operamos solo en el carril limpio —opt-in legítimo y prospección medida—, y desde ahí la disciplina que exigen estas reglas es, además, buena higiene comercial.

Cómo llegaron estas reglas

Vale la pena situar las fechas, porque explican el tono de aplicación de hoy. Google y Yahoo anunciaron sus requisitos juntos en octubre de 2023, con entrada en vigor en febrero de 2024; durante un tiempo la aplicación fue gradual, con rechazos temporales y avisos, hasta que a partir de noviembre de 2025 Google intensificó la aplicación con rechazos permanentes para el tráfico que no cumple. Microsoft anunció su alineación en abril de 2025 y empezó a aplicarla el 5 de mayo de 2025, dieciséis meses después que los otros dos, pero con el mismo espíritu. La consecuencia es que el periodo de gracia se acabó: lo que en 2024 era una advertencia con margen, en el entorno actual es la condición de entrada a la bandeja. Quien aún trata estos requisitos como una optimización opcional llega tarde a un cambio que ya es la línea de base.

¿Qué cuesta de verdad no cumplir?

El castigo cambió de naturaleza, y ahí está lo serio. Antes, el correo dudoso se filtraba a spam y aún tenía una oportunidad de ser visto; ahora, el correo que falla los requisitos se rechaza en el nivel SMTP, devuelto con un código de error en lugar de entregado en ningún sitio. Verás respuestas como 550 5.7.26 o 5.7.350 en Gmail, 550 o 554 5.7.9 en Yahoo, y 550 5.7.515 en Microsoft, cada una apuntando a un fallo de autenticación o de cumplimiento. Para un negocio que depende del correo —confirmaciones, avisos, campañas— eso deja de ser un problema de entregabilidad y pasa a ser de continuidad: si el correo rebota en el saludo, no hay carpeta de spam que revisar ni recuperación tardía. El coste no se mide solo en mensajes perdidos, sino en la reputación de dominio e IP que cuesta meses reconstruir una vez que los proveedores dejan de confiar en ti. Y la recuperación no es simétrica con la caída: perder reputación es cuestión de días de mal comportamiento, recobrarla exige semanas de envío impecable a volumen reducido, calentando de nuevo lo que se quemó. En el panel renovado de Google el golpe es además visible y binario —pasas de un estado de cumplimiento a otro—, sin los matices intermedios que antes daban margen para reaccionar despacio. Para una operación que factura por correo, asumir ese riesgo a cambio de ahorrarse unas horas de configuración es un mal negocio difícil de justificar.

# Obligación 1: ¿hay DMARC publicado y avanzando más allá de p=none?
$ dig +short TXT _dmarc.ejemplo.com
"v=DMARC1; p=none; rua=mailto:[email protected]"
# presente, pero p=none — cumple la letra, no protege nada

# Obligación 2: ¿está la cabecera de baja en un clic en el correo de marketing?
$ grep -i list-unsubscribe muestra-marketing.eml
List-Unsubscribe-Post: List-Unsubscribe=One-Click   # RFC 8058, correcto

# Obligación 4: ¿PTR válido en la IP de envío?
$ dig +short -x 203.0.113.45
mail.ejemplo.com.    # FCrDNS resuelve en ambos sentidos — bien

Una comprobación antes de cada campaña

El momento de mayor riesgo es el envío grande: una campaña a una lista amplia tras semanas de poco volumen. Conviene una comprobación breve antes de pulsar enviar, que recorra lo que los proveedores miran:

• Autenticación viva: SPF, DKIM y DMARC publican y alinean, y la firma DKIM es la del dominio visible, en lugar de la de un tercero sin alinear.
• Política DMARC consciente: sabes si estás en monitorización o en aplicación, y el salto está respaldado por informes limpios, no improvisado la víspera.
• Baja en su sitio: las cabeceras de baja en un clic están en el correo de marketing y fuera del transaccional, y hay un enlace de baja visible en el cuerpo.
• Tasa de quejas con margen: los últimos días vienen por debajo del 0,10% en los paneles, con holgura suficiente para absorber un envío grande sin acercarte al 0,30%.
• Higiene de lista: los rebotes duros están suprimidos, las direcciones inactivas largo tiempo se han apartado y el destino no es una lista comprada ni recién importada sin verificar.
• Infraestructura calentada: si envías desde una IP o un subdominio nuevos, el volumen sube en escalón y no de golpe.

Ninguno de estos puntos es exótico, y precisamente por eso el fallo casi nunca está en no conocerlos, sino en no revisarlos cuando una prisa empuja a saltarse el paso.

Qué no exigen, y conviene igual

Los requisitos publicados marcan el suelo, y por debajo de ese suelo viven prácticas que ningún proveedor obliga pero que deciden si te quedas cómodamente por encima de la línea o coqueteando con ella. La segmentación por interacción es la primera: enviar más a quien abre y hace clic, y menos —o nada— a quien lleva meses en silencio, baja las quejas más que cualquier ajuste técnico. Una política de retirada para direcciones inactivas, que las aparte antes de que se conviertan en quejas o en trampas de spam, protege la reputación a largo plazo. La cadencia importa: un ritmo previsible enseña a los filtros qué esperar de ti, mientras que los picos erráticos parecen comportamiento de remitente comprometido. Y la calidad de la captación —doble confirmación donde tenga sentido, formularios sin casillas premarcadas— determina la salud de la lista mucho antes de que un correo salga. Operar así no lo pide la norma; lo pide el querer entregarse de forma estable, que es el objetivo real detrás de la norma.

Cómo medir tu tasa de quejas hoy

No puedes gestionar lo que no ves, y cada proveedor ofrece su propia ventana. En Google, el panel renovado de Postmaster Tools muestra la tasa de spam que reportan los usuarios de Gmail y, desde su cambio de octubre de 2025, un estado de cumplimiento que dice sin rodeos si pasas o fallas cada requisito; conviene tener el dominio verificado y mirarlo con regularidad. Yahoo expone las quejas a través de su bucle de retroalimentación, al que te suscribes con tus dominios e IPs para recibir los avisos. Microsoft publica datos de reputación y volumen mediante SNDS y sus herramientas para remitentes. La trampa es fiarse de un solo panel: como cada proveedor calcula y muestra de forma distinta, una imagen tranquila en Google no garantiza la misma lectura en Yahoo. Montar la vigilancia de los tres, y revisarla con una cadencia fija, convierte un problema que te enteras por los rechazos en una señal que ves subir con tiempo para frenar.

¿Por qué el cumplimiento es un estado continuo y no una casilla?

Es tentador tratar todo esto como un proyecto con final: configurar SPF, DKIM y DMARC, cablear la baja en un clic, marcar la casilla y olvidarse. La realidad es que el cumplimiento es una condición que se mantiene o se pierde a diario. La tasa de quejas se recalcula cada día; un cambio de ESP puede dejar de añadir las cabeceras de baja sin que nadie lo note; una IP o un subdominio nuevos arrancan sin reputación y, si se usan sin calentar, hunden la entrega del conjunto; un cliente de alineación de DMARC que cambia rompe la coincidencia de dominios que ayer pasaba. Por eso el trabajo no termina con la configuración inicial. La diferencia entre un remitente que cumple y uno que lo aparenta está en la vigilancia continua de las señales que los proveedores miran.

¿Cómo se cae un remitente que cumplía?

Los incumplimientos rara vez nacen de la ignorancia; nacen del cambio. El patrón se repite. Una lista crece deprisa con contactos menos comprometidos y la tasa de quejas sube por debajo del radar. Se añade un subdominio o una IP para un flujo nuevo y se envía a volumen sin calentar, y la reputación fría arrastra a todo el dominio. Se migra de ESP o de plataforma y la nueva configuración deja de insertar las cabeceras RFC 8058 que la anterior ponía sola. Un proveedor cambia su forma de medir —como hizo Google con su panel— y lo que antes pasaba desapercibido ahora aparece marcado como fallo. En todos los casos, el remitente cumplía y dejó de cumplir sin tocar a propósito nada de lo que importaba. Detectar estas derivas a tiempo es justo lo que separa un susto de una interrupción.

Cómo te dejamos cumpliendo y te mantenemos así

Empezamos por medir dónde estás de verdad: la auditoría gratuita de 25 puntos comprueba tu autenticación y su alineación, tu reputación y tu colocación frente a los requisitos de los tres proveedores, y te dice exactamente qué falla y qué cuesta arreglarlo. A partir de ahí, el trabajo es ordenado: dejar SPF, DKIM y DMARC correctos y alineados; subir la política de DMARC de monitorización a aplicación cuando los informes están limpios; cablear la baja en un clic en los flujos de marketing y dejarla fuera de los transaccionales; y montar la vigilancia de la tasa de quejas en cada panel —el nuevo de Google, el bucle de Yahoo, los datos de Microsoft— para verlo venir en lugar de enterarte por los rechazos. Después puedes llevar tú las riendas con un plan claro, o dejárnoslas como operación continua. En ambos casos, la relación se factura por el trabajo, sin un producto de envío que vender al otro lado de la mesa, que es lo que mantiene el consejo honesto.