Industria · 10 min de lectura

Qué cambiaron las reglas de bulk sender de Gmail y Yahoo de febrero de 2024

Por AcelleMail Team May 8, 2026 10 min de lectura
industry deliverability

A dos años de los requisitos de bulk sender de febrero de 2024, ya se asentó el polvo: DMARC es de entrada obligatorio, el unsubscribe de un clic se exige y el techo del 0,3% de complaint rate es real. Qué significa todo esto para operadores autohospedados en 2026.

§1

Recapitulación: qué cambió en febrero de 2024

El 1 de febrero de 2024 Google y Yahoo empezaron a aplicar simultáneamente nuevos requisitos para todo remitente que excediera las 5.000 mensajes diarios a sus respectivas bases de usuarios. Los dos comunicados siguen siendo las referencias canónicas — las "Email sender guidelines" de Google y las "Sender best practices" de Yahoo — y se mantienen casi idénticos en el fondo. Las tres exigencias:

  1. Autenticación. SPF y DKIM son obligatorios; DMARC con mínimo p=none es obligatorio. El correo no alineado va a spam o se rechaza.
  2. Unsubscribe de un clic. La cabecera List-Unsubscribe (RFC 2369, 1998) siempre estuvo disponible; lo que 2024 añadió fue el requisito de un clic — la URL de baja debe aceptar una única petición POST y procesarla sin paso de confirmación (RFC 8058, 2017). El usuario hace clic una vez en su cliente de correo y queda dado de baja.
  3. Techo de complaint rate. Los bulk senders deben mantener su tasa de quejas de spam por debajo del 0,3% en todo momento. Tasas sostenidas más altas disparan una degradación automatizada a la carpeta de spam.

§2

DMARC pasó de "buena práctica" a requisito de entrada

Antes de 2024, la mayoría de operadores autohospedados solo corrían SPF + DKIM y se saltaban DMARC. El argumento: DMARC es solo una policy encima de los otros dos, y recibir reportes de vuelta es operativamente engorroso. Ese argumento ya no aplica.

Concretamente, la regla de 2024 exige que DMARC exista — aunque sea en p=none — y que alinee. "Alinear" en DMARC significa que o bien el dominio From de SPF o bien el dominio firmante de DKIM coincide con la cabecera visible From:, en modo de alineación estricto o relajado. Un fallo común: el remitente usa marketing@suempresa.com como From visible pero enruta a través de un CRM de terceros que firma DKIM con el dominio del CRM — la alineación falla, DMARC falla y Gmail / Yahoo encaminan el mensaje a spam en silencio.

La solución es el rollout estándar de DMARC: publicar p=none con reportes RUA, observar los agregados diarios durante dos a cuatro semanas, identificar y arreglar los streams no alineados, escalar a p=quarantine y asentarse en p=reject. No hay atajo.

§3

El unsubscribe de un clic es el requisito que más se pasa por alto

La barra técnica son dos cabeceras, ambas por RFC 8058:

List-Unsubscribe: <https://suempresa.com/unsub?token=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

El cliente de correo (Gmail, Yahoo, Apple Mail) renderiza esto como un enlace "Unsubscribe" de un clic en la cabecera del mensaje. Cuando el usuario hace clic, el cliente hace POST de List-Unsubscribe=One-Click a la URL. Su servidor procesa la baja y devuelve 200 OK. Sin página de confirmación, sin captcha, sin login.

AcelleMail emite ambas cabeceras por defecto en cualquier lista de campaña con el manejo de baja habilitado. Donde tropiezan los operadores es en integraciones a medida — flujos transaccionales que evitan el motor de campañas, relays SMTP de terceros que despojan las cabeceras o URLs de baja que redirigen por una página de confirmación del CMS. Cada uno de esos casos es un golpe a la entregabilidad.

La verificación más sencilla: envíese una prueba a sí mismo, haga clic en "Mostrar original" en Gmail y busque List-Unsubscribe-Post. Si la cabecera falta o no dice One-Click, no está en cumplimiento. Arréglelo antes de que el volumen cruce los 5.000/día hacia cualquiera de los dos proveedores.

§4

El techo del 0,3% de complaint rate es real

El complaint rate es el porcentaje de destinatarios que marcaron su mensaje como spam, computado por día sobre una ventana móvil. El anuncio de Google pidió "por debajo del 0,3%" sostenido, y "queremos ver su tasa consistentemente por debajo del 0,1%" como margen de trabajo.

Dos notas de implementación:

  1. Es por dominio, no por cuenta. Si separa marketing en un subdominio (por ejemplo, news.suempresa.com), el complaint rate se computa solo contra ese subdominio. Un subdominio que cruce el 0,3% no degrada automáticamente su tráfico transaccional del dominio apex, lo que es una de las razones por las que la práctica estándar es aislar el marketing en un subdominio. (Vea /glossary/email-deliverability.)
  2. Gmail y Yahoo miden distinto. Gmail usa la tasa de clic en el botón de spam entre destinatarios que abrieron. Yahoo usa una métrica similar en su interfaz. Ambos números deberían seguirse entre sí dentro de ~0,05%; divergencias grandes indican sesgo de audiencia en lugar de un problema del remitente.

Para visibilidad, regístrese en Google Postmaster Tools (gratis, requiere verificación DNS de su dominio) y en el Complaint Feedback Loop de Yahoo. Ambos exponen cifras diarias de complaint rate. AcelleMail consume el feed de quejas a nivel SES vía webhooks SNS (app/SendingServers/Webhooks/ComplaintReceived.php), que es la fuente de verdad a nivel del sending server. Las tasas de Gmail / Yahoo son post-entrega; la tasa SES es at-acceptance.

§5

El mito del "envío menos de 5.000/día, así que estoy exento"

Estrictamente, las reglas de 2024 aplican solo a bulk senders — >5.000/día hacia Gmail o Yahoo. Por debajo de ese umbral los requisitos son "buena práctica" en vez de exigidos.

En la práctica, eso no significa nada. Los remitentes por debajo de 5.000 igual caen en spam por falta de DMARC, falta de unsubscribe de un clic o complaint rate alto. La heurística que corren los proveedores es en buena medida la misma; la diferencia es que por encima de 5.000 lo publican a usted en una cola de "bulk sender" con automatización más estricta, mientras que por debajo cae en una vía de revisión manual / impulsada por engagement. De cualquier modo, ignorar las reglas por debajo de 5.000 produce pérdida medible de entregabilidad.

El encuadre correcto: las reglas de 2024 codificaron lo que ya era la barra de facto en los grandes proveedores. No inventaron requisitos nuevos; hicieron explícitos y exigibles los existentes. Los operadores autohospedados por debajo de 5.000/día deberían tratar las reglas como la barra de trabajo, sin importar el volumen.

§6

Qué se rompió para los operadores autohospedados

Tres patrones se rompieron a escala en febrero-marzo de 2024 y siguen causando pérdida medible de entregabilidad hoy:

  1. Forwarder-DMARC-fail. Los operadores con mailing lists que reenviaban correo a las direcciones personales de los suscriptores (el clásico patrón de "list service") vieron su correo reenviado rechazado en masa. La solución es reescribir la cabecera From en el correo reenviado (el enfoque ARC) o pasar las listas a envío directo desde el dominio de la lista. Mailman 3 y el módulo de listas de Postal lo soportan.
  2. Remitentes vía CRM de terceros. Enviar a través de un relay SMTP atado al CRM que firma con el dominio del CRM rompe la alineación DMARC, salvo que el CRM también publique su propio DKIM bajo su subdominio. SES, Mailgun, SparkPost y SendGrid lo soportan; relays más viejos o menos mainstream pueden no hacerlo.
  3. Flujos transaccionales sin autenticar. "Mandamos los password resets por Postfix en la misma máquina que corre la app, sin DKIM" dejó de funcionar a cualquier volumen significativo. La solución es publicar claves DKIM para el dominio apex y configurar OpenDKIM sobre la instalación de Postfix — trabajo de una sola vez que paga dividendos en todo el tráfico transaccional.

§7

Dónde estamos dos años después

Las reglas de 2024 resultaron más significativas de lo que parecían a primera vista. No solo elevaron la barra — la volvieron concreta y testeable. Sender Score, Talos, GlockApps, Postmark y los varios vendors de monitoreo de entregabilidad incorporaron los tres pilares en sus checks en cuestión de meses. Para mediados de 2025 todo el ecosistema comercial de herramientas de entregabilidad asumía DMARC + unsubscribe de un clic + complaint rate como precondiciones; los servicios viejos del tipo "te ayudamos a debuggear tu SPF" se actualizaron o se retiraron en silencio.

Para los operadores autohospedados en particular, las reglas de 2024 aceleraron un giro que ya estaba en marcha: alejarse del "enviar cualquier cosa desde cualquier lado" (la norma autohospedada de los 2010) hacia "enviar solo correo autenticado, alineado y fácilmente cancelable desde un dominio cuya reputación se gestiona activamente". Es una barra operativa más alta pero un estado estable de menor riesgo. Las herramientas de AcelleMail para ese estado estable — WarmupStrategy, BounceHandler, suppression list, adaptadores de verificación NeverBounce / ZeroBounce — ya estaban en el codebase antes de 2024; lo que cambió es que pasaron de opcionales a necesarias.

Si no hizo una auditoría de cumplimiento con las reglas de 2024 sobre su dominio de envío en los últimos seis meses, hoy es un buen día para empezar. La versión de cinco minutos: envíese una prueba a sí mismo, "Mostrar original" en Gmail, verifique tres veredictos pass más la cabecera List-Unsubscribe-Post: List-Unsubscribe=One-Click. Si todo cuadra, está bien. Si no, el trabajo para llegar ahí está bien recorrido.

Ejecute esto en su propia infraestructura.

AcelleMail es una plataforma de email autoalojada con licencia de pago único. Código fuente completo, sin precios por suscriptor.

Probar la demo en vivo