# Requisitos de Gmail y Yahoo para remitentes masivos: checklist > Checklist de los requisitos de Gmail y Yahoo para remitentes masivos: SPF, DKIM, DMARC, baja con un clic, PTR, TLS y tasa de spam por debajo de 0,3%. Source: https://pidgely.com/es/blog/requisitos-gmail-yahoo-remitentes-masivos/ · Published: 2026-10-12 · Pidgely 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*): ```text $ 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ó: ```text 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: ```dns _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: ```text List-Unsubscribe: , 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 | Requisito | Todos | Masivos | Dónde comprobarlo | |---|---|---|---| | SPF o DKIM | Sí | Ambos | `Authentication-Results` | | PTR válido y confirmado | Sí | Sí | `dig -x` | | TLS | Sí | Sí | Header `Received` | | Spam < 0,3% | Sí | Sí (ideal < 0,1%) | Postmaster Tools | | DMARC alineado | Recomendado | Obligatorio | Reportes `rua` | | Baja con un clic (RFC 8058) | Recomendado | Obligatorio en comercial | Headers del mensaje | | Bajas en 2 días | Recomendado | Obligatorio | Tus sistemas | ## 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: ```text 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. ``` ```text 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. ## Preguntas frecuentes ### ¿Qué se considera un remitente masivo para Gmail? Según Google, quien envía unos 5.000 mensajes o más en un día a cuentas personales de Gmail. Una vez alcanzado ese volumen, Google indica que la clasificación es permanente. ### ¿Qué tasa de spam exige Google? Google pide mantener la tasa de spam reportada en Postmaster Tools por debajo de 0,1% y no alcanzar nunca 0,3%. ### ¿Los correos transaccionales necesitan baja con un clic? No. El requisito de List-Unsubscribe con RFC 8058 aplica a mensajes comerciales y promocionales. Los transaccionales, como restablecer contraseña o recibos, están exentos. ### ¿Desde cuándo aplican estos requisitos? Google y Yahoo los anunciaron a finales de 2023 y empezaron a aplicarlos en febrero de 2024, endureciendo la aplicación de forma progresiva.