¿Sus correos salientes rebotan con códigos de error 550? ¿Los destinatarios reportan que sus mensajes llegan a la carpeta de correo no deseado en lugar de la bandeja de entrada? Hay una razón clara. En febrero de 2024, Google y Yahoo dejaron de tratar la autenticación de correo electrónico como opcional: ahora es un requisito estricto. Para cualquier negocio que dependa del correo electrónico, ignorar estos cambios dañará la entregabilidad y, con ella, los ingresos.

Puntos clave:

• Google y Yahoo exigen que los remitentes masivos autentiquen el correo saliente con SPF y DKIM y que publiquen un registro DMARC.
• El umbral de 5.000 mensajes diarios que define a un remitente masivo cubre todo el tráfico combinado del dominio principal.
• Las tasas de quejas de spam en Google Postmaster Tools deben mantenerse por debajo del 0,1%; alcanzar el 0,3% activa penalizaciones automáticas de entregabilidad en los servidores receptores.
• Los correos de marketing y suscripciones deben admitir encabezados de cancelación de suscripción con un clic conforme a RFC 8058.
• Comenzar con p=none cumple con la normativa básica, pero pasar a p=quarantine o p=reject es importante para prevenir la suplantación de dominios y construir reputación a largo plazo.

Qué cambió y por qué: las nuevas reglas de remitentes de Gmail/Yahoo

¿Por qué existen estas reglas? La causa raíz está en cómo se diseñó originalmente el correo electrónico. El Simple Mail Transfer Protocol (SMTP), estandarizado en 1982 mediante el RFC 821, no tenía ningún mecanismo nativo para verificar la identidad del remitente. Cualquier servidor de correo podía transmitir un mensaje que afirmara provenir de cualquier dirección, y los servidores receptores lo aceptaban, lo que significaba que cualquiera podía suplantar un nombre de dominio en el encabezado visible con poco esfuerzo.

Los ingenieros de seguridad fueron corrigiendo este defecto estructural a lo largo de los años. SPF llegó a mediados de los 2000 para validar las direcciones IP de envío contra una lista pública de DNS. Luego llegó DKIM, que utiliza criptografía de clave pública para que los remitentes firmen los encabezados salientes. En 2012, los principales actores de la industria publicaron DMARC para vincular las verificaciones de SPF y DKIM y dar a los propietarios de dominios una forma de establecer políticas de aplicación.

Durante años, los proveedores de bandeja de entrada trataron estos estándares como opcionales. Los dominios con SPF y DKIM ganaban puntos extra; los que no los tenían normalmente llegaban igualmente a la bandeja de entrada, siempre que la dirección IP estuviera limpia.

Eso terminó en febrero de 2024. Como se establece en las directrices para remitentes de correo de Google, los proveedores de bandeja de entrada pasaron la autenticación de ser una sugerencia deseable a un requisito estricto de acceso.

En lugar de bloquear de golpe todo el correo no autenticado, los proveedores implementaron la aplicación por fases. A principios de 2024 comenzaron a ralentizar las velocidades de conexión y a devolver códigos temporales de aplazamiento 4xx en los flujos no autenticados. En los meses siguientes escalaron a códigos estrictos de rechazo 5xx y a la clasificación automática como spam. Microsoft alineó rápidamente sus filtros de puerta de enlace con los mismos estándares para remitentes de alto volumen, y desde entonces ha anunciado que Outlook.com aplicará requisitos comparables de SPF, DKIM y DMARC para remitentes masivos en 2025, señal de que estas reglas se están convirtiendo en una base de referencia para toda la industria y no solo en una política de Google y Yahoo.

Quién cuenta como remitente masivo según las directrices de Gmail

Google define como remitente masivo a cualquier dominio que envíe aproximadamente 5.000 o más mensajes en una ventana de 24 horas a cuentas personales de Gmail; Yahoo aplica un estándar similar. Pero centrarse solo en esa cifra es un error común.

Primero, el volumen se calcula en todo el dominio raíz, no por dirección IP ni por nombre de servidor. Si una plataforma de marketing envía 3.500 correos de boletín mientras un servidor de aplicaciones envía 2.000 restablecimientos de contraseña o recibos de facturas bajo el mismo dominio, el umbral ya se ha superado.

Segundo, la regla se aplica a todo el correo saliente, no solo al de marketing. Las notificaciones del sistema, los recibos para clientes y los correos comerciales diarios cuentan para el límite diario. Cualquier dominio que envíe cerca de 3.000 mensajes al día debería configurar la autenticación completa como si ya hubiera superado el límite.

Los requisitos centrales para remitentes de correo

Para cumplir con los requisitos de remitentes masivos de Google y Yahoo, la infraestructura de correo debe pasar seis verificaciones técnicas:

1. Configurar registros SPF válidos y pares de claves DKIM para todos los flujos de correo saliente.
2. Publicar un registro DMARC TXT válido en el DNS del dominio.
3. Asegurar que el dominio del encabezado visible "From:" coincida con el dominio autenticado por SPF o DKIM.
4. Mantener las tasas de quejas de spam de los usuarios por debajo del 0,1% en Google Postmaster Tools y nunca dejar que lleguen al 0,3%.
5. Incluir encabezados nativos de cancelación de suscripción con un clic en todo el correo de marketing y boletines.
6. Asegurar que las IP de los servidores de envío tengan registros A/AAAA coincidentes y DNS inverso (PTR) válido.

Qué sucede si no cumple

Fallar las verificaciones de autenticación daña la reputación del dominio en los servidores de correo receptores, típicamente en tres pasos:

1. Los servidores receptores responden con códigos de aplazamiento 4xx; las colas de correo se llenan y la entrega se retrasa por horas.
2. Los mensajes pasan la puerta de enlace pero son redirigidos a las carpetas de spam de los destinatarios en lugar de la bandeja de entrada principal.
3. Los servidores de correo cortan la conexión por completo y devuelven errores de rebote definitivo 5xx.

Cómo cumplir cada requisito: paso a paso

1. Configure SPF y vigile el límite de 10 consultas

Agregue un registro DNS TXT en la raíz del dominio que liste todas las direcciones IP autorizadas y proveedores de correo de terceros. Tenga en cuenta el límite de 10 consultas DNS: el RFC de SPF limita los registros a un máximo de 10 consultas DNS externas (include, a, mx, redirect). Superarlo causa un PermError de SPF, que los servidores receptores tratan como un fallo de autenticación. Audite el registro periódicamente y elimine las inclusiones de proveedores obsoletas para mantenerse bajo el límite.

2. Configure la firma DKIM en todos los canales salientes

DKIM firma los encabezados del correo saliente con una firma criptográfica y debe habilitarse en todas las plataformas que envíen correo en nombre del dominio. Genere un par de claves DKIM de 2048 bits en el portal de su servicio de correo y publique la clave pública como registro CNAME o TXT en el DNS. Una vez que el DNS se propague, active la firma en la consola de administración e inspeccione los encabezados sin procesar de un correo de prueba para confirmar que el encabezado DKIM-Signature está presente y pasa la validación.

3. Publique un registro DMARC

Para cumplir el requisito básico de DMARC que exigen Gmail y Yahoo, publique un registro DMARC TXT en _dmarc.yourdomain.com. Las configuraciones por primera vez deberían iniciar con una política de monitoreo (p=none) para recopilar datos de reportes sin arriesgar la entrega del correo. Antes de activar los cambios, pruebe la entrada DNS con un verificador de registros DMARC público para detectar errores de sintaxis.

4. Agregue encabezados de cancelación con un clic según RFC 8058

Un simple enlace HTML de cancelación de suscripción al final del correo no es suficiente para el correo de marketing. Deben inyectarse dos encabezados de correo sin procesar en el flujo saliente:

List-Unsubscribe:
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Cuando clientes como Gmail o Yahoo procesan estos encabezados, muestran un botón destacado de "Cancelar suscripción" junto al nombre del remitente en la interfaz de la bandeja de entrada. Al pulsarlo se envía una solicitud POST automática al servidor, eliminando al suscriptor de inmediato sin abrir una ventana del navegador.

5. Verifique el DNS directo e inverso

Los servidores receptores comprueban que la dirección IP de envío coincida con el dominio en el DNS. La IP debe resolverse a un nombre de host válido mediante un registro PTR, y ese nombre de host debe resolverse de vuelta a la misma IP mediante un registro DNS A estándar. Los operadores de servidores de correo dedicados o instancias en la nube pueden editar la configuración de DNS inverso en la consola de su proveedor o abrir un ticket de soporte para mapear la IP al nombre de dominio completo (FQDN) del servidor de correo.

6. Monitoree métricas en Postmaster Tools y reportes DMARC

Cree una cuenta en Google Postmaster Tools y verifique la propiedad del dominio mediante un registro DNS TXT. El panel ofrece visibilidad directa sobre la reputación del dominio, las tasas de quejas de spam y las tasas de éxito de autenticación. Mantenga la tasa de quejas por debajo del 0,1%; alcanzar el 0,3% hace que Google envíe el correo a carpetas de spam sin importar el estado de SPF y DKIM. Para monitorear fallos de autenticación en todos los proveedores receptores y detectar IP de envío no autorizadas, configure reportes DMARC automatizados.

Más allá del cumplimiento: usar las reglas para mejorar la entregabilidad

Una política p=none por sí sola deja el dominio desprotegido contra la suplantación: indica a los servidores receptores que registren los datos de autenticación, pero no impide que atacantes suplanten el dominio en ataques de phishing.

Una vez que todos los flujos legítimos de correo pasen la alineación de SPF y DKIM, actualice la política DMARC a p=quarantine o p=reject. p=quarantine envía el correo no autenticado directamente a spam, mientras que p=reject descarta los mensajes falsos en la puerta de enlace receptora.

Tras alcanzar la aplicación de DMARC, los remitentes pueden publicar Brand Indicators for Message Identification (BIMI), que muestra un logotipo verificado de la marca junto a los mensajes en las bandejas de entrada de los destinatarios, aumentando la visibilidad y la confianza en la marca.

Preguntas frecuentes sobre los requisitos para remitentes masivos

¿Cuál es el umbral de remitente masivo para Google y Yahoo?

Google y Yahoo definen como remitentes masivos a los dominios que envían ~5.000 o más mensajes diarios a cuentas personales. El volumen se calcula en todo el dominio principal, combinando todos los servicios de envío.

¿Estas reglas también se aplican al correo transaccional?

Sí. Los correos transaccionales como restablecimientos de contraseña, actualizaciones de pedidos y alertas del sistema deben pasar las verificaciones de SPF, DKIM, DMARC y DNS, aunque no requieren encabezados de cancelación de suscripción con un clic.

¿Basta una política DMARC de p=none para cumplir?

Sí, p=none cumple los requisitos básicos de Google y Yahoo. Sin embargo, solo monitorea el tráfico sin bloquear la suplantación, por lo que se recomienda pasar a p=quarantine o p=reject.

¿Qué pasa con mi correo si no cumplo los requisitos?

Los proveedores de correo limitarán las conexiones SMTP con códigos de error 4xx, enviarán sus correos directamente a carpetas de spam o emitirán rebotes definitivos 5xx que rechazan el correo por completo.

¿Cuánto tarda la recuperación de tasas altas de quejas de spam?

Una vez corregida la higiene de la lista y con las tasas de quejas de vuelta por debajo del 0,1%, normalmente toma de 7 a 14 días de envío limpio para que Google Postmaster Tools reconstruya la reputación del dominio.

¿Cómo verifico si mi registro SPF supera el límite de 10 consultas?

Inspeccione el registro SPF TXT y cuente cada mecanismo que genere una consulta DNS. Si el total de consultas DNS entre el registro principal y los registros anidados supera 10, el registro SPF fallará con un PermError.

Fuente: FinTechZoom