Requisitos de Gmail y Yahoo para remitentes masivos: checklist

Desde febrero de 2024, Gmail y Yahoo exigen a los remitentes masivos autenticar con SPF y DKIM, publicar DMARC (al menos p=none) alineado con el From, ofrecer baja con un clic (RFC 8058) en el correo comercial y mantener la tasa de spam por debajo de 0,3%, idealmente por debajo de 0,1%. Además, cualquier remitente, masivo o no, necesita DNS directo e inverso válido, conexión TLS y mensajes con formato correcto. Si incumples, tu correo se retrasa, va a spam o se rechaza.

Quién es "remitente masivo"

Según las directrices de Google, un remitente masivo es quien envía aproximadamente 5.000 mensajes o más en un día a cuentas personales de Gmail (direcciones @gmail.com y @googlemail.com). El conteo se hace sobre el dominio principal del From, sumando subdominios. Google indica también que, una vez que un dominio entra en esa categoría, no vuelve a salir aunque baje el volumen.

Yahoo no publica un umbral numérico equivalente, pero aplica requisitos prácticamente iguales a los remitentes de volumen. La recomendación sensata es cumplir todo como si fueras masivo, aunque hoy envíes poco: es la configuración que esperan todos los grandes proveedores y no cuesta más.

Requisitos para todos los remitentes

Estos aplican incluso si envías unos pocos correos al día.

1. SPF o DKIM

Al menos uno de los dos debe pasar. En la práctica, configura ambos (ver más abajo).

2. DNS directo e inverso válidos

La IP de envío debe tener un registro PTR (DNS inverso) que apunte a un hostname, y ese hostname debe resolver de vuelta a la misma IP (forward-confirmed reverse DNS):

$ dig -x 203.0.113.10 +short
mta1.example.com.
$ dig mta1.example.com +short
203.0.113.10

Lo ideal es que el hostname del PTR coincida con el que tu MTA anuncia en el EHLO.

3. TLS en la transmisión

Gmail exige conexión cifrada para enviar. Tu MTA debe soportar STARTTLS y negociar TLS con los MX del receptor. Un header como este en el mensaje recibido confirma que se usó:

Received: from mta1.example.com (mta1.example.com. [203.0.113.10])
        by mx.google.com with ESMTPS id ...
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);

4. Tasa de spam bajo control

Mantén la tasa de spam reportada en Google Postmaster Tools por debajo de 0,1% y evita llegar nunca a 0,3%. Ojo: esa tasa se calcula sobre el correo que llega a la bandeja de entrada y los usuarios marcan como spam, no sobre el total enviado.

5. Formato conforme a RFC 5322

Un único header From, Date y Message-ID válidos, sin headers duplicados ni malformados. Si reenvías mensajes o usas listas, sigue las prácticas de ARC o reescritura de From correspondientes.

6. No suplantar headers de Gmail

No uses una dirección @gmail.com en el From de un envío masivo desde tu infraestructura. El dominio gmail.com publica su propia política DMARC y tus servidores no están autorizados para él, así que esos mensajes fallarán la alineación.

Requisitos adicionales para remitentes masivos

7. SPF y DKIM, ambos

Ya no basta con uno. El SPF debe pasar para el dominio del MAIL FROM y la firma DKIM debe validar.

8. DMARC publicado y alineado

Necesitas un registro DMARC en el dominio del From, como mínimo:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Y el dominio del From debe estar alineado con el de SPF o el de DKIM. Si tu proveedor firma con d=proveedor.example y usa su propio return-path, no estás alineado aunque SPF y DKIM pasen.

9. Baja con un clic en mensajes comerciales

Los mensajes de marketing y suscripción deben incluir:

List-Unsubscribe: <https://example.com/u/7f3a9c>, <mailto:baja-7f3a9c@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Ambos headers deben quedar cubiertos por la firma DKIM. Además, el cuerpo del mensaje debe tener un enlace de baja visible. Google y Yahoo piden que las bajas se procesen en un plazo de dos días.

10. Tasa de spam por debajo del umbral

Igual que el punto 4, pero aquí es determinante: superar 0,3% de forma sostenida te deja fuera de las mitigaciones que Google ofrece y suele traducirse en rechazos y envíos a spam.

Tabla resumen

Cómo se ve un incumplimiento

Cuando Gmail detecta que no cumples, lo dice en la respuesta SMTP. Los mensajes varían, pero tienen esta forma:

550-5.7.26 Your email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.

421-4.7.0 This message does not meet IPv6 sending guidelines regarding PTR
421-4.7.0 records and authentication.

Los códigos 4.x.x son temporales: tu MTA reintentará, pero si el problema persiste el mensaje acabará expirando. Los 5.x.x son definitivos. Google ha ido endureciendo la aplicación con el tiempo, pasando de demoras temporales a rechazos para el tráfico que no cumple, así que no conviene tratar estos avisos como algo menor.

Errores comunes

• Pensar que "solo es transaccional" y ignorar DMARC. La autenticación y la alineación aplican a todo el correo, también al transaccional.
• Enlace de baja que exige iniciar sesión. Va contra el espíritu del requisito y genera quejas.
• Procesar la baja en un lote semanal. El plazo es de dos días.
• Medir la tasa de spam con tus propios datos. Solo ves las quejas que llegan por feedback loops; Gmail no envía quejas individuales. La cifra que cuenta es la de Postmaster Tools.
• IPv6 sin PTR. Si tu MTA prefiere IPv6, ese camino también necesita DNS inverso y autenticación correctos.
• Usar el dominio del proveedor en DKIM. Pasa DKIM, pero no alinea.

Checklist final

• [ ] PTR configurado y confirmado para cada IP de envío (IPv4 e IPv6).
• [ ] STARTTLS habilitado en el MTA.
• [ ] SPF publicado para el dominio del MAIL FROM.
• [ ] DKIM con tu dominio en d=, clave de 2048 bits.
• [ ] DMARC publicado (p=none como mínimo) con reportes rua.
• [ ] From alineado con SPF y/o DKIM.
• [ ] List-Unsubscribe + List-Unsubscribe-Post en todo el correo comercial, firmados por DKIM.
• [ ] Enlace de baja visible en el cuerpo.
• [ ] Bajas procesadas en menos de 48 horas.
• [ ] Postmaster Tools configurado y revisado cada semana.
• [ ] Alertas internas si la tasa de quejas se acerca a 0,1%.

Cómo lo resuelve Pidgely

Pidgely cubre estos requisitos desde la infraestructura: DKIM por dominio, SPF alineado mediante subdominio de return-path, baja con un clic según RFC 8058 y un guardián de reputación que pausa el envío cuando las tasas de rebote o queja superan los umbrales, antes de que el problema llegue a Gmail o Yahoo.