Revisa la autenticación, las respuestas de los proveedores, la calidad de la audiencia y las bajas para saber por qué tus emails se rechazan o acaban en spam.
Que un email se entregue no significa que llegue a la bandeja de entrada. Un servidor receptor puede aceptar un mensaje y dejarlo en spam. Que el panel de una campaña muestre “Entregado” no demuestra que el lector lo haya visto.
Cuando aparezca un problema, reúne las pruebas antes de cambiar los textos o de proveedor. Lo que falla puede ser la autenticación, la reputación, la audiencia o el propio mensaje.
En los mensajes rechazados o aplazados, examina la respuesta SMTP real y el código de estado ampliado. Los fallos temporales y los rechazos permanentes requieren un tratamiento distinto. Las preguntas frecuentes para remitentes de Google describen ambos casos; no dicen que cualquier incumplimiento genere ahora errores permanentes.
Si los mensajes se aceptan pero aparecen en spam, revisa los resultados de autenticación en los encabezados del mensaje recibido, los datos de reputación del proveedor, si los hay, y los cambios recientes en la audiencia o en el volumen. Unas cuantas bandejas de entrada semilla ayudan a diagnosticar un problema, pero no miden la llegada a la bandeja de entrada en toda la lista.
Un código de estado ampliado (enhanced status code) tiene tres números separados por puntos, definidos en el RFC 3463. El primer número es la clase. Un código que empieza por 4 es un fallo temporal, y el servidor que envía debería reintentarlo más tarde. Un código que empieza por 5 es un fallo permanente, así que reintentar el mismo mensaje sin cambios no servirá de nada.
El segundo número concreta el tema. Los códigos del rango X.1.X tienen que ver con la dirección, y 5.1.1 suele significar que el buzón no existe. Suprime esa dirección. Los códigos del rango X.7.X tienen que ver con la seguridad o las políticas, que es donde suelen aparecer los problemas de autenticación y de reputación.
Google recoge las respuestas que devuelve Gmail en su referencia de errores SMTP. Lee el texto completo de la respuesta, no solo el código, porque un mismo código puede abarcar varios motivos distintos.
Google Postmaster Tools muestra cómo ve Gmail tu dominio de envío, incluida la tasa de spam notificada por los usuarios a la que se refieren los requisitos de Google. El dominio se verifica con un registro DNS. Gmail solo muestra datos cuando un dominio envía a sus usuarios suficiente correo diario, así que un remitente pequeño puede encontrarse con los paneles vacíos.
Smart Network Data Services, de Microsoft, más conocido como SNDS, informa sobre el correo que envían determinadas direcciones IP a los buzones personales de Outlook.com, con datos como las tasas de quejas y los envíos que caen en trampas de spam. Solo puedes registrar direcciones IP que controlas, así que resulta más útil con IP de envío dedicadas. Si usas IP compartidas, pregunta a tu proveedor de envío qué supervisa.
Ninguna de las dos herramientas te dice dónde acabó una campaña concreta. Muestran tendencias diarias, que es lo que necesitas cuando un problema se ha ido acumulando a lo largo de varios envíos.
SPF autoriza la infraestructura de envío de un dominio del sobre. DKIM firma un mensaje con la identidad de un dominio. DMARC comprueba la alineación con el dominio visible del From y publica una política y un mecanismo de informes. Ninguno de los tres garantiza la llegada a la bandeja de entrada.
Usa los registros que te facilita tu proveedor de envío y verifica el resultado en un mensaje real recibido. No añadas registros SPF contradictorios ni des por hecho que un registro DNS demuestra que todas las vías de envío lo usan correctamente. Tu infraestructura también necesita un DNS inverso adecuado y un transporte seguro.
En Brew, sigue el proceso de verificación del dominio y publica los registros que se te piden. Revisa la dirección del From que usan realmente la campaña o la automatización, sobre todo cuando un agente gestiona varias marcas.
Una política DMARC es un registro TXT en el host _dmarc del dominio de la dirección del From. Empieza con p=none. Esta política pide a los receptores que no tomen ninguna medida concreta con el correo que falla, y aun así envían informes agregados a la dirección de rua.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Los informes recogen todas las fuentes que envían correo con tu dominio y si cada una superó SPF o DKIM con alineación. Cuenta con encontrar herramientas de las que te habías olvidado, como un sistema de facturación o una herramienta de soporte. Corrige o elimina cada fuente que falle.
Cuando todo el correo legítimo supere las comprobaciones, pasa a p=quarantine. Esta política pide a los receptores que traten como sospechoso el correo que falla, lo que normalmente significa enviarlo a spam.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"La política más estricta, p=reject, pide a los receptores que rechacen el correo que falla. Pasa a ella solo cuando quarantine lleve un tiempo funcionando sin que falle correo legítimo. Sigue leyendo los informes en cada etapa: si una herramienta nueva empieza a enviar con tu dominio, aparecerá ahí primero.
Un subdominio de envío dedicado, como mail.example.com, es la excepción. Si nada más envía desde él y tu proveedor ha verificado su SPF y su DKIM, puede empezar directamente en p=reject. Brew recomienda p=reject para un subdominio dedicado que haya configurado él mismo, y p=none para un dominio principal desde el que puedan enviar otros servicios.
Las directrices de Google distinguen entre los requisitos para todos los remitentes y las normas más estrictas para quienes envían unos 5000 mensajes al día a cuentas personales de Gmail. Google pide tasas de spam inferiores al 0,1 % y advierte de que no se llegue al 0,3 %. Sus requisitos para remitentes masivos incluyen SPF y DKIM, DMARC, alineación y baja con un clic para el correo de suscripción al que se aplique.
La lista de Google para cualquier remitente, sea cual sea su volumen, incluye estos puntos:
Los remitentes masivos también deben cumplir lo siguiente:
p=none.Para aplicar el umbral, Google cuenta juntos los envíos de un mismo dominio principal, y un dominio que lo ha superado una vez conserva la consideración de remitente masivo. Sus preguntas frecuentes para remitentes explican cómo funciona el recuento.
Las indicaciones de Yahoo también tratan la autenticación, las quejas y las bajas. Yahoo no publica el mismo umbral numérico para remitentes masivos; consulta sus preguntas frecuentes en lugar de aplicar la cifra de Gmail a todos los proveedores.
Microsoft anunció en 2025 que los dominios que envían más de 5000 emails al día a sus buzones personales (las direcciones de outlook.com, hotmail.com y live.com) deben superar SPF y DKIM y publicar DMARC. La política DMARC puede ser p=none, y el dominio del From debe estar alineado con SPF o con DKIM.
Indicaciones de los proveedores revisadas el 28 de septiembre de 2026. Consulta las páginas enlazadas cuando diagnostiques una incidencia nueva.
La baja con un clic del RFC 8058 es un mecanismo basado en encabezados y en una solicitud POST por HTTPS. Un enlace visible en el pie de página también es útil, y las normas aplicables lo exigen, pero una página de preferencias por sí sola no implementa el protocolo.
Un mensaje compatible con la baja con un clic lleva dos encabezados:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickCuando el lector hace clic en darse de baja desde la bandeja de entrada, el proveedor de correo envía un POST a la URL HTTPS con el cuerpo List-Unsubscribe=One-Click. La dirección mailto: es una alternativa para los programas de correo que no admiten la baja con un clic. El RFC 8058 también exige una firma DKIM válida que cubra ambos encabezados. Haz que la URL sea específica de cada destinatario y difícil de adivinar. Los escáneres de seguridad suelen abrir los enlaces del correo entrante, así que una simple solicitud GET a esa URL no debería dar de baja a nadie.
Brew añade los encabezados List-Unsubscribe y List-Unsubscribe-Post a los envíos de marketing, con una URL HTTPS firmada y propia de cada destinatario que acepta el POST de la baja con un clic.
Confirma que una baja de marketing impide los envíos de marketing posteriores por todas las vías que usas. Conserva las supresiones al importar contactos o al cambiar de plataforma. Mantén los mensajes transaccionales esenciales separados, tanto en su finalidad como en su configuración de envío.
Revisa de dónde salieron las direcciones y qué esperaba la gente al registrarse. Elimina las direcciones no válidas mediante el proceso de supresión del proveedor, investiga los picos de quejas y no vuelvas a enviar un email a alguien solo porque el seguimiento diga que no lo abrió.
No existe una antigüedad de la lista, una proporción entre imagen y texto ni una palabra prohibida que garanticen la entrega en todos los casos. Un aumento repentino del volumen hacia una lista que no conoces bien es un problema más grave que usar la palabra “gratis”.
Si es un agente quien envía la campaña, se aplican las mismas comprobaciones. Usa datos verificados, una audiencia relevante y una dirección de respuesta que alguien revise. Corrige la causa que hayas identificado, haz un envío de prueba controlado y revisa las respuestas de los proveedores antes de volver a ampliar.
