# Entregabilidad: diagnostica el camino a la bandeja de entrada URL canónica: https://brew.new/es/blog/email-deliverability Autoría: Brew Team Publicado: 2026-08-23 Actualizado: 2026-09-29 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. ## Empieza por la respuesta del servidor receptor 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](https://support.google.com/mail/answer/14229414) 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. ### Lee el código de estado ampliado Un código de estado ampliado (enhanced status code) tiene tres números separados por puntos, definidos en el [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html). 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](https://support.google.com/a/answer/3726730). Lee el texto completo de la respuesta, no solo el código, porque un mismo código puede abarcar varios motivos distintos. ### Dónde encontrar los datos de reputación de los proveedores [Google Postmaster Tools](https://postmaster.google.com/) 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](https://substrate.office.com/ip-domain-management-snds/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. ## Verifica la identidad en los mensajes reales 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. ### Pasa de monitorizar DMARC a aplicar la política 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`. ```text _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. ```text _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. ## Lee los requisitos de los proveedores en la fuente Las [directrices de Google](https://support.google.com/mail/answer/81126) 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. ### Requisitos de Google para todos los remitentes La lista de Google para cualquier remitente, sea cual sea su volumen, incluye estos puntos: - Configura SPF o DKIM para tu dominio de envío. - Asigna a los dominios o las IP de envío registros DNS directos e inversos válidos. - Envía a través de una conexión TLS. - Mantén la tasa de spam que muestra Postmaster Tools por debajo de los límites anteriores. - Da formato a los mensajes según el RFC 5322. ### Requisitos adicionales para remitentes masivos Los remitentes masivos también deben cumplir lo siguiente: - Configura tanto SPF como DKIM. - Publica un registro DMARC para el dominio de envío. Google acepta una política `p=none`. - Alinea el dominio del From con el dominio de SPF o con el de DKIM. - Admite la baja con un clic en los mensajes de marketing y de suscripción, e incluye un enlace de baja bien visible en el cuerpo del mensaje. 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](https://support.google.com/mail/answer/14229414) explican cómo funciona el recuento. Las [indicaciones de Yahoo](https://senders.yahooinc.com/best-practices/) 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](https://senders.yahooinc.com/faqs/) en lugar de aplicar la cifra de Gmail a todos los proveedores. ### Microsoft Outlook.com Microsoft [anunció en 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) 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. ## Prueba que la baja funciona, no solo que existe La baja con un clic del [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) 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: ```text List-Unsubscribe: , List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` Cuando 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](/es/blog/transactional-emails) esenciales separados, tanto en su finalidad como en su configuración de envío. ## Revisa la audiencia antes de aumentar el volumen 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](/es/blog/agent-email-deliverability), 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.