Requisitos de Gmail y Yahoo para remitentes: qué cambió en 2024 y qué revisar
Desde febrero de 2024, Gmail y Yahoo exigen a todos los remitentes que autentiquen su correo y fijan reglas más estrictas para los envíos masivos: SPF y DKIM, un registro DMARC publicado, un dominio From alineado con SPF o DKIM, baja con un clic en el correo de marketing y una tasa baja de quejas por spam. El correo que no cumple estos requisitos puede retrasarse, ir a la carpeta de spam o ser rechazado.
Estas reglas se aplican a cualquiera que envíe a direcciones personales de Gmail y Yahoo, lo que para la mayoría de las empresas supone una gran parte de sus clientes. Las facturas, los restablecimientos de contraseña y las confirmaciones de pedido se ven tan afectados como los boletines.
A continuación se explica qué exige realmente cada proveedor, con enlaces a su propia documentación, y después las comprobaciones que puede hacer usted mismo.
Qué exige Gmail
Las directrices para remitentes de Google entraron en vigor en febrero de 2024. Para todos los remitentes que envían a cuentas personales de Gmail:
- Autenticación SPF o DKIM para el dominio de envío.
- Registros DNS directos e inversos (PTR) válidos para las IP de envío.
- Una conexión TLS para transmitir el correo.
- Una tasa de spam, según Postmaster Tools, inferior al 0,3 %.
- Mensajes con formato conforme al RFC 5322.
Para quienes envían 5000 mensajes o más al día, Google añade:
- SPF y DKIM a la vez.
- Un registro DMARC para el dominio de envío (la política puede ser
p=none). - El dominio From alineado con el dominio SPF o con el dominio DKIM.
- Baja con un clic para los mensajes de marketing y de suscripción, más un enlace de baja visible en el cuerpo.
Las preguntas frecuentes de las directrices de Google añaden 3 detalles que importan en la práctica. Los mensajes del mismo dominio principal cuentan conjuntamente para el umbral de 5000. Un remitente que lo supera una vez se considera de forma permanente un remitente masivo. Y a partir de noviembre de 2025 Gmail intensificó la aplicación, con rechazos temporales y permanentes para el correo que no cumple.
Qué exige Yahoo
Las buenas prácticas para remitentes de Yahoo también entraron en vigor en febrero de 2024. Para todos los remitentes: SPF o DKIM, una tasa de spam inferior al 0,3 %, DNS directo e inverso válidos y cumplimiento de los RFC 5321 y RFC 5322.
Para los remitentes masivos, Yahoo exige:
- SPF y DKIM a la vez.
- Una política DMARC válida de al menos
p=none, y DMARC debe superarse. - El dominio From alineado con el dominio SPF o DKIM (se acepta la alineación relajada).
- Una cabecera List-Unsubscribe funcional que admita la baja con un clic. Yahoo recomienda encarecidamente el método POST del RFC 8058.
- Las bajas atendidas en un plazo de 2 días.
A diferencia de Google, Yahoo no publica un número fijo de mensajes a partir del cual se le considera remitente masivo, así que lo sensato es cumplir los requisitos de envío masivo siempre que envíe correo de marketing.
Dónde suelen fallar las empresas
DKIM solo en el buzón principal. El correo de la oficina va firmado, pero el CRM, la herramienta de boletines o el sistema de facturación envían correo sin firmar o firmado con el dominio del proveedor de la herramienta, lo que rompe la alineación.
SPF que se supera para el dominio equivocado. Muchos servicios de envío usan su propio dominio de rebote, así que SPF se supera para bounces.vendor.net, no para su dominio. Sin un DKIM alineado, DMARC falla.
Ningún registro DMARC. Ambos proveedores exigen al menos p=none a los remitentes masivos. Nuestra guía sobre SPF, DKIM y DMARC explica el formato del registro.
La baja solo como enlace. La baja con un clic implica cabeceras sobre las que el proveedor de correo puede actuar directamente, no solo un enlace en el pie.
Listas antiguas. Enviar a direcciones que nunca dieron su consentimiento dispara las quejas por spam, y el techo del 0,3 % es bajo.
Cómo revisar su dominio
Empiece por el DNS:
dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
Después envíe un mensaje desde cada sistema que escribe a sus clientes (correo de oficina, CRM, boletines, facturación, servicio de ayuda) a una dirección de Gmail que controle. En Gmail, abra el mensaje, elija "Mostrar original" y busque:
SPF: PASS with domain yourcompany.com
DKIM: PASS with domain yourcompany.com
DMARC: PASS
El dominio que aparece para SPF o DKIM debe coincidir con su dominio From. En el correo de marketing, el código original debe contener las 2 cabeceras necesarias para la baja con un clic:
List-Unsubscribe: <https://yourcompany.com/unsubscribe?id=...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Por último, registre su dominio en Google Postmaster Tools para ver la tasa de spam que Google mide para usted.
Una lista de comprobación breve
- SPF publicado y superado para su dominio.
- Firma DKIM con su propio dominio en cada sistema de envío.
- DMARC publicado, al menos
p=none, con los informes revisados con regularidad. - Dominio From alineado con SPF o DKIM en cada sistema.
- Cabeceras de baja con un clic en el correo de marketing, solicitudes atendidas en 2 días.
- Tasa de spam vigilada en Postmaster Tools y muy por debajo del 0,3 %.
- Registros PTR válidos para cualquier IP desde la que envíe directamente.
Microsoft introdujo reglas similares para Outlook.com en 2025, explicadas en requisitos de Outlook para remitentes y el rechazo 550 5.7.515.
Cómo ayuda Datahorses
La autenticación del correo forma parte de lo que Datahorses vigila desde fuera cada día. Si cambia su registro SPF, desaparece una clave DKIM, se debilita DMARC o su dominio acaba en una lista de bloqueo, una persona lo revisa y usted recibe los pasos exactos para su desarrollador. Consulte qué vigilamos para ver la lista completa, o solicite una propuesta si quiere que cubramos sus dominios.
Más artículos
Puertos de bases de datos expuestos: MySQL, PostgreSQL, MongoDB, Redis y Elasticsearch
Las bases de datos están hechas para hablar con su aplicación, no con todo internet. Así puede saber si la suya es accesible desde fuera y cómo cerrarla.
Cabeceras de seguridad HTTP que toda web de empresa debería enviar
Unas pocas líneas en la respuesta del servidor indican al navegador que use HTTPS, bloquee el enmarcado y limite los scripts. Estas son las cabeceras que vale la pena enviar.
PHP2Shell: qué versiones de PHP están corregidas y cómo comprobar la suya
El proyecto PHP corrigió 2 fallos críticos el 21 de octubre de 2026. Le explicamos qué versiones incluyen el parche, qué indica su servidor y qué preguntar a su proveedor de hosting.