Entregabilidad del correo: guía práctica de diagnóstico

Envías un mensaje y el servidor responde 250 OK. Dos semanas después descubres que la propuesta estaba en spam o que una pasarela la puso en cuarentena antes de que el destinatario la viera. La aceptación del servidor no demuestra por sí sola dónde acabó el mensaje.

Ese es un problema de entregabilidad del correo. No depende únicamente de asuntos o erratas: también interviene la infraestructura. Desde los cambios de requisitos de principios de 2024, Google, Yahoo y Microsoft aplican controles más exigentes según el tráfico. Autenticación incorrecta o problemas de reputación pueden provocar filtrado o rechazo, pero el tratamiento no es idéntico en todos los receptores.

Esta guía sirve tanto a quien envía diez mensajes importantes al día como a un proveedor que gestiona quinientos dominios. Dejamos a un lado los consejos genéricos sobre asuntos para investigar causas: qué falla, cómo comprobarlo y qué controles conviene mantener en 2026.

Aceptación y entregabilidad: la diferencia

La entregabilidad del correo no equivale a «entregado» en un panel. Ese estado suele indicar que el receptor aceptó el mensaje con 250 OK. La entregabilidad estudia la capacidad de llegar de forma sostenida a la bandeja de entrada, no solo la aceptación SMTP. La pestaña Principal no es el único destino legítimo dentro de la bandeja de entrada.

Conviene distinguir estos tres conceptos:

• Aceptado: El servidor receptor aceptó el mensaje. Aún puede filtrarlo, ponerlo en cuarentena o aplicar otras reglas.
• Ubicación en bandeja de entrada: El mensaje aparece en una bandeja accesible al destinatario, incluida una pestaña legítima como Promociones.
• Entregabilidad: La capacidad de mantener esa llegada a bandeja de entrada en distintas rutas y receptores a lo largo del tiempo.

Si el panel muestra 99% entregado y 2% de aperturas, investiga tanto la clasificación como el seguimiento y las expectativas de los usuarios. Esa diferencia no demuestra que todos los mensajes estén enterrados en spam: las aperturas pueden ser incompletas o distorsionadas. Aceptación y ubicación requieren evidencias diferentes.

El modelo: autenticación, reputación, contenido y clasificación

Los receptores combinan distintas comprobaciones. Algunas decisiones tempranas pueden impedir otras, pero no existe una secuencia universal idéntica en todos los sistemas. Este modelo ayuda a organizar el diagnóstico técnico.

1. Autenticación: SPF, DKIM y DMARC aportan autorización, verificación de firma y alineación. No certifican que el contenido sea seguro; sus fallos requieren interpretación conjunta.
2. Reputación: Dominios e IP pueden acumular señales de historial. Una tasa de spam denunciado de 0.3% es importante en determinados requisitos, no una pérdida automática y universal de reputación.
3. Contenido y comportamiento: Enviar 10,000 mensajes desde una IP sin historial en la primera hora puede provocar controles. Enlaces, estructura y volumen también importan, pero no hay una lista universal de palabras ni una proporción mágica de imágenes.
4. Clasificación: Principal, Promociones, Spam o Cuarentena son resultados distintos. Promociones no equivale a correo no deseado.

Revisa la base técnica antes de dar por resuelto el problema con cambios de contenido. A la vez, no ignores contenido o consentimiento solo porque estás ajustando DNS: varias causas pueden coexistir.

Síntomas: cómo interpretar las respuestas

Los códigos ayudan a acotar el diagnóstico, pero el número aislado no identifica siempre una causa exacta. Lee la respuesta completa y relaciona los síntomas con registros, cabeceras y rutas reales.

Consulta cómo evitar que los mensajes lleguen a spam para organizar las comprobaciones según el síntoma, sin asumir que cada código tiene una única solución.

Fase 1 - SPF, DKIM y DMARC

SPF, DKIM y DMARC son una base importante de la entregabilidad del correo. Desde principios de 2024, los requisitos de Google y Yahoo los incluyen para el tráfico masivo correspondiente; Microsoft también tiene requisitos específicos. Comprueba el alcance vigente: incumplir puede afectar la entrega, pero no implica un resultado único en cada mensaje.

Revisa el proceso completo de autenticación SPF, DKIM y DMARC. Para TrekMail, consulta la documentación de registros DNS necesarios y prueba cada ruta después de configurarla.

SPF (Sender Policy Framework)

SPF publica una política TXT de autorización para el dominio evaluado, normalmente el del remitente del sobre SMTP. El receptor comprueba la IP frente a esa política. Un resultado no aprobado no exige por sí solo rechazo: el receptor combina sus reglas y otras señales.

La política empieza con v=spf1. Es frecuente terminarla con ~all (softfail) o -all (fail), pero no son las únicas posibilidades del protocolo. Las autorizaciones intermedias deben corresponder al inventario real de envío.

Estas dos situaciones merecen especial atención:

• Reenvío: Si alguien reenvía de Gmail a Yahoo, la nueva conexión puede proceder de la IP de Gmail. SPF puede fallar si mantiene una identidad del sobre que no la autoriza. Una firma DKIM válida y alineada puede conservar DMARC; SPF solo no resuelve todas las rutas.
• Presupuesto de 10 términos: SPF permite evaluar hasta 10 términos que requieren consultas DNS, incluidos los relevantes anidados. Incluir Gmail, Outlook, Mailchimp, Zendesk, CRM y transacciones exige medir, no demuestra exceso por sí solo. Superarlo produce PermError en esa evaluación, no necesariamente en todo el correo. Consulta el límite de consultas SPF y la configuración del registro SPF.

DKIM (DomainKeys Identified Mail)

DKIM añade una firma criptográfica a las cabeceras del mensaje. El firmante conserva la clave privada y publica la correspondiente clave pública en DNS. El receptor verifica la firma de los datos cubiertos. Una firma válida demuestra esa comprobación, no ausencia de malware ni autenticidad universal de toda la identidad visible.

DKIM puede sobrevivir al reenvío si los datos firmados siguen siendo válidos según la canonicalización y la clave permanece disponible. Para aportar aprobación DMARC también debe estar alineado. Por eso conviene configurar y probar DKIM en cada flujo legítimo, especialmente con intermediarios.

Google exige al menos 1024 bits para claves RSA y recomienda 2048 bits en sus requisitos aplicables. Una clave heredada de 512 bits no cumple ese mínimo. Al rotar, publica el nuevo selector antes de usarlo y conserva la clave antigua mientras haya mensajes firmados en tránsito. Consulta cómo configurar DKIM.

DMARC: política y alineación

DMARC se apoya en SPF y DKIM y exige resultados alineados con el dominio del From visible. Basta SPF aprobado y alineado o cualquier firma DKIM válida y alineada. La política publicada solicita tratamiento si ninguna vía cumple; el receptor mantiene decisiones locales. No protege por sí solo frente a todos los dominios parecidos o contenidos abusivos.

El registro TXT se publica en _dmarc.yourdomain.com. Sus opciones de política son:

• p=none - No solicita cuarentena ni rechazo DMARC. Los informes requieren configuración y dependen del receptor; tampoco garantiza entrega.
• p=quarantine - Solicita cuarentena o clasificación como spam si DMARC falla, según la política del receptor. Evalúalo después de inventario, informes y pruebas.
• p=reject - Solicita rechazo si DMARC falla. No es obligatorio para todos los entornos ni garantiza eliminación universal; prepara reversión.

Revisa la alineación DMARC. Un proveedor como Mailchimp puede usar un Return-Path bajo mailchimp.com. SPF puede pasar para esa identidad sin alinearse con tu From. DMARC solo falla si tampoco hay una firma DKIM válida y alineada. En modo relajado importa el dominio organizativo; en estricto, la coincidencia exacta.

Configura autenticación personalizada del sobre cuando el servicio lo permita o una firma DKIM válida y alineada. Consulta los fallos de alineación DMARC y cómo configurar DMARC para revisar opciones y pruebas.

El asistente DNS de TrekMail puede proponer registros según la configuración y los recursos disponibles. Revisa las identidades de todos los servicios y verifica los valores antes de publicar. No garantiza excluir errores ni mantener siempre el presupuesto de 10 términos si cambian dependencias externas.

Fase 2 - Entregabilidad y reputación

La entregabilidad del correo no termina en autenticación. SPF, DKIM y DMARC correctos no garantizan bandeja de entrada. Los receptores pueden valorar historial y reputación de dominios e IP; no existe una puntuación única universal ni una velocidad fija de mejora o deterioro.

El umbral de 0.3%

En determinadas reglas de Google, una tasa de spam denunciado de 0.3% es un umbral importante: 3 denuncias entre 1,000 mensajes de la población utilizada en la métrica. No implica pérdida instantánea de toda reputación ni bloqueo automático en Google y Yahoo. Revisa datos diarios, denominador, elegibilidad para mitigación y requisitos actuales.

Tres denuncias entre mil pueden parecer pocas. Una lista comprada o un segmento sin expectativas claras puede generar quejas. Detén el uso de contactos sin consentimiento y revisa la captación y la baja en lugar de confiar en una prueba técnica favorable.

Clasificación de remitente masivo

Google describe un umbral cercano a 5,000 mensajes diarios a cuentas personales de Gmail, agregado por dominio principal, y puede mantener la clasificación histórica aunque baje el volumen. Clasificarse como masivo no equivale a reputación mala. Antes de crecer, revisa la reputación del dominio de correo y la reputación del remitente junto con los requisitos correspondientes.

Reputación del dominio y de la IP

Son conjuntos de señales diferentes que el receptor puede relacionar.

• Dominio: Puede reflejar el historial de identidades de envío. Separar marketing ayuda a gestionar flujos, pero no garantiza proteger todo el correo corporativo.
• IP: Puede reflejar el historial de la conexión SMTP. Algunos alojamientos cPanel, GoDaddy u otros usan IP compartidas, según el despliegue. El abuso de otro remitente puede afectar al conjunto; no toda inclusión en listas se hereda automáticamente ni todos los servicios son iguales.

Evalúa un relé SMTP bien gestionado o una IP dedicada según volumen, costes y capacidad de mantenimiento. Una IP dedicada no es siempre mejor para poco tráfico y ninguna opción garantiza entrega.

Fase 3 - Mantenimiento de infraestructura

Autenticación y reputación son relevantes, pero también hay requisitos de infraestructura en 2026. Revisa DNS inverso y transporte conforme al receptor; sus fallos pueden afectar conexiones, sin producir siempre el mismo rechazo.

PTR y DNS inverso

Comprueba el registro DNS inverso (PTR) de la IP que realmente entrega. FCrDNS requiere además que el nombre obtenido resuelva de vuelta a esa IP mediante A o AAAA según corresponda. Normalmente se configura con el propietario de la IP o proveedor SMTP. La referencia de 10 minutos es orientativa, no un plazo garantizado; cambios y permisos pueden requerir más tiempo.

Cifrado TLS

Los requisitos aplicables pueden exigir TLS para el transporte SMTP. Comprueba negociación y políticas en cada salto relevante. TLS oportunista o exigido depende de la configuración y no equivale a cifrado de extremo a extremo del contenido. No presupongas que TrekMail fuerza TLS en todas las conexiones de cualquier ruta externa. Consulta comprobar el estado DNS para las comprobaciones documentadas; valida TLS por separado donde sea necesario.

Gmail, Outlook y Yahoo: diferencias de evaluación

SPF, DKIM y DMARC proporcionan una base de autenticación para los tres principales proveedores, no garantizan entregabilidad. Cada proveedor puede aplicar requisitos, señales y herramientas diferentes. Compara evidencia específica de cada destino incluso si la autenticación parece correcta.

Google (Gmail)

Google puede combinar interacción y reputación del dominio con autenticación y otras señales. No rastrea las tasas de apertura usadas por las plataformas de marketing. No existe una regla pública universal que transforme cada apertura, eliminación o respuesta en una clasificación predecible.

Google Postmaster Tools puede mostrar spam denunciado y categorías de reputación como alta, media, baja o mala. Los datos tienen cobertura y umbrales de disponibilidad; no es una vista completa de todos los mensajes ni su consulta semanal garantiza evitar bloqueos.

Promociones es una pestaña legítima de la bandeja de entrada, no una degradación equivalente a spam. No supongas ascensos o descensos automáticos por cada acción. Envía mensajes esperados, revisa consentimiento y usa señales de interacción con contexto, sin depender solo de aperturas.

Consulta las directrices oficiales de Google para remitentes para el alcance y las condiciones vigentes.

Microsoft (Outlook / Office 365)

Microsoft aplica requisitos técnicos y políticas de evaluación según el servicio y el tráfico. Enviar 1,000 mensajes desde una IP nueva el día 1 puede provocar controles, pero no garantiza errores 451 o 421. Esas respuestas temporales también pueden tener otras causas. Aumenta el tráfico esperado con cautela y lee el detalle.

Microsoft SNDS (Smart Network Data Services) puede aportar datos de IP para los servicios cubiertos. Acceso, métricas y disponibilidad dependen de su alcance y de tus permisos; no representa toda la red de Microsoft.

La detección de búsqueda de direcciones puede valorar intentos hacia usuarios inexistentes. Una lista desactualizada merece revisión, pero no existe una regla universal por la que Microsoft bloquee antes que Google. Suprime direcciones inexistentes confirmadas y clasifica otros errores permanentes por su respuesta.

Consulta las reglas de calentamiento del dominio de TrekMail y adapta el ritmo a la ruta y al tráfico.

Yahoo / AOL

Las quejas por spam son una señal importante para Yahoo, junto con otras comprobaciones. Interpreta su métrica con el denominador documentado.

Consulta Yahoo Sender Hub para requisitos y herramientas disponibles.

Yahoo calcula el spam denunciado sobre mensajes entregados a la bandeja de entrada, no todos los enviados. Ejemplo: envías 1,000 mensajes; 900 van a spam y 100 llegan a bandeja; 1 persona denuncia uno. La tasa es 1% (1/100), no 0.1% (1/1000). El cálculo explica el denominador, no demuestra la causa del filtrado ni una espiral inevitable de penalizaciones.

Si las quejas aumentan, investiga y considera pausar el marketing implicado. Revisa autenticación, consentimiento y baja, procesa feedback válido y consulta los canales del Sender Hub. No garantiza recuperación ni respuesta inmediata.

Acciones iniciales en 24 horas

Si el correo falla ahora, esta secuencia puede organizar el trabajo del día. Ajusta las prioridades a la evidencia y al impacto; no es un orden obligatorio para cualquier incidente ni una promesa de resolución.

Consulta la lista de revisión de 30 minutos para mejorar la entregabilidad. Esta es una versión inicial:

Paso 1 - Contener el problema

Si el spam denunciado supera 0.3% en la métrica pertinente, revisa los flujos de marketing y considera pausarlos. Las transacciones necesarias, como contraseñas, facturas o confirmaciones, también deben ser legítimas y esperadas; no son inmunes al filtrado. Corrige consentimiento, captación y baja y verifica los requisitos de reanudación, no solo que baje una cifra.

Paso 2 - Revisar listas de bloqueo

Consulta MXToolbox para la IP real de salida y comprueba directamente Spamhaus. Una inclusión en SBL (Spamhaus Block List) puede ser relevante, pero no implica bloqueo por todos los proveedores. Sigue el procedimiento oficial de la lista y demuestra la corrección de la causa cuando corresponda, sin asumir retirada automática.

Paso 3 - Revisar DNS

Usa un validador como Email Health Check de MXToolbox y contrasta sus resultados con las rutas reales. Busca:

• SPF PermError por superar el presupuesto de 10 términos, o por otros errores de política
• Selector DKIM ausente, incorrecto o con clave no verificable
• DMARC ausente o p=none sin una evaluación documentada de política; no cambies medidas sin pruebas
• Desalineaciones en informes agregados DMARC, teniendo presente que esos datos son parciales

Consulta las preguntas frecuentes sobre spam y el diagnóstico de errores de envío para relacionar respuestas con comprobaciones.

Paso 4 - Revisar la lista

La calidad de la lista merece atención. Suprime direcciones inexistentes confirmadas y clasifica los demás rechazos permanentes: no todos significan una dirección inválida. Revisa destinatarios inactivos mediante consentimiento, expectativas y señales fiables. Seis meses sin aperturas no demuestra por sí solo falta de interés, porque el seguimiento puede ser incompleto; evita seguir enviando a quien ya no espera mensajes.

Prevención a largo plazo

El diagnóstico puede corregir causas concretas, pero no garantiza recuperación rápida ni protección permanente. Estas tres prácticas ayudan a mantener una operación documentada y a detectar cambios antes de que el impacto crezca.

Separación por subdominio

Evalúa un subdominio de marketing como @marketing.yourdomain.com o @newsletter.yourdomain.com. Configura las identidades reales del sobre y DKIM. Separar flujos facilita gestión, pero los receptores pueden relacionar dominio organizativo, IP y marca; no garantiza proteger todos los mensajes del dominio raíz.

Las políticas DMARC explícitas por subdominio y el seguimiento separado pueden ayudar a atribuir problemas. Revisa herencia y alineación antes de cambiar registros. La separación no es un mecanismo para eludir requisitos.

Aumento gradual de volumen

Una IP nueva puede tener poco historial disponible. Este calendario es ilustrativo: 20 mensajes el día 1 y 40 el día 2, duplicando cada pocos días solo como ejemplo, no como pauta automática. Un horizonte de 4-6 semanas no garantiza alcanzar el volumen objetivo, y acelerar no produce necesariamente bloqueo Microsoft el día 3. Ajusta el ritmo a tráfico consentido, respuestas y requisitos del proveedor.

Consulta las reglas de calentamiento del dominio para el calendario documentado y su alcance.

Supervisión semanal

Revisa los datos disponibles de Google Postmaster Tools con una frecuencia acorde al riesgo. Un cambio de reputación alta a media puede motivar investigación, no predice siempre bloqueo ni una corrección inmediata. Consulta supervisión de la entregabilidad para una rutina orientativa de 10 minutos semanales.

Dónde encaja TrekMail en la infraestructura de correo

Al comparar alojamiento, conviene distinguir costes, envío y controles. No todas las opciones encajan en los mismos modelos.

Opción A: precio por usuario. La fuente cita Google Workspace o Microsoft 365 a $6-$30 por usuario al mes como referencia histórica. Para 50 clientes con 10 usuarios cada uno, los costes pueden ser importantes, pero dependen de la oferta, las funciones y la contratación actuales. No es una penalización técnica inherente al modelo.

Opción B: correo incluido con alojamiento web. cPanel, GoDaddy o Bluehost pueden usar configuraciones compartidas según el servicio. El abuso de otros remitentes puede afectar una IP común, pero no toda oferta es gratuita ni toda cuenta comparte la misma infraestructura o sufre automáticamente spam.

Compara TrekMail si necesitas otro modelo de gestión, verificando las condiciones actuales.

Tarifa fija y recursos compartidos

La fuente describe tarifa fija sin cargos por usuario y almacenamiento compartido entre dominios. Tener 5 o 500 usuarios no implica necesariamente el mismo coste: hay que respetar límites, capacidad y condiciones del plan, incluidos posibles cambios de nivel.

• Free: La fuente indica hasta 10 dominios, 10 usuarios por dominio y 5GB compartidos, con SMTP propio y sin tarjeta. Confirma la oferta vigente.
• Starter ($3.50 al mes o $42 al año): La fuente indica 50 dominios, 100 usuarios por dominio y 15GB compartidos, SMTP administrado y migración IMAP en servidor. Verifica límites, facturación y recursos actuales.
• Pro ($8 al mes o $96 al año): La fuente indica 100 dominios, 300 usuarios por dominio, 50GB compartidos, mayores límites de envío, reenvío con SRS, migración y soporte prioritario. La disponibilidad depende de la oferta vigente.
• Agency: La fuente menciona 1,000+ dominios y 200GB+ compartidos para grandes carteras. No asumas límites ilimitados; verifica condiciones actuales.

SMTP propio para gestionar el envío por separado

TrekMail puede alojar buzones IMAP, almacenamiento y gestión, mientras el envío usa un proveedor externo compatible como Amazon SES, SendGrid o Mailgun. Confirma opciones, credenciales y limitaciones del plan antes de configurarlo.

El receptor evalúa la IP que realmente entrega y otras identidades. Una cuenta SES no implica automáticamente IP dedicada, mejores resultados ni ahorro. Si una IP tiene problemas, cambiar una clave API no cambia necesariamente la ruta ni corrige abuso. Puedes gestionar el proveedor de salida aparte de los buzones, pero revisa autenticación, reintentos y causas; no uses cambios de identidad para eludir bloqueos.

Consulta la documentación de SMTP propio para opciones y configuración.

Asistente DNS

El asistente puede proponer SPF, DKIM y DMARC según los datos y funciones disponibles. Revisa los registros y las dependencias actuales antes de publicar; no elimina el riesgo de superar el presupuesto de 10 términos. El ahorro de tiempo o dinero depende de la operación, no está garantizado por la suscripción.

Migración en servidor

La migración IMAP puede copiar mensajes y carpetas compatibles desde el servidor de origen con credenciales autorizadas. Evita parte del trabajo manual de clientes, que podría ocupar, por ejemplo, tres horas; no es una duración garantizada. Necesita comprobar acceso, alcance, errores, carpetas, indicadores y recuentos, además de sincronizar cambios y probar resultados. No traslada DNS, reputación, aplicaciones ni toda configuración de cuenta, y no garantiza ausencia de pérdidas o interrupciones.

Catch-all y reenvío con SRS

Catch-all puede dirigir mensajes de direcciones no creadas a un buzón designado si la configuración y las políticas lo permiten. Ayuda con ciertas erratas o direcciones antiguas, pero también puede atraer tráfico no deseado; no evita todos los rechazos.

SRS (Sender Rewriting Scheme) reescribe el remitente del sobre SMTP, reflejado en Return-Path, para usar un dominio del intermediario y puede permitir SPF para ese dominio. No restaura la alineación SPF con el From original ni garantiza DMARC. Una firma DKIM válida y alineada puede conservar la aprobación; prueba la ruta y las modificaciones reales.

Conclusión sobre la entregabilidad

La entregabilidad del correo combina infraestructura, autenticación, reputación, contenido y políticas del receptor. Una operación mantenida verifica DNS, evita listas sin consentimiento y supervisa señales en lugar de esperar a una incidencia. Eso mejora el control, pero no garantiza siempre la pestaña Principal.

Muchas causas pueden corregirse con evidencia y pruebas. Entender SPF, DKIM y DMARC facilita el trabajo; la reputación no tiene un plazo universal de recuperación. Incluso con infraestructura correcta, mantén controles proporcionados al volumen y al riesgo.

Si gestionas varios dominios, compara las funciones y condiciones actuales de TrekMail: tarifa fija, asistente DNS, SMTP propio y migración IMAP de buzones. Decide según necesidades, límites y pruebas, no asumas que el modelo sustituye responsabilidades operativas.

Para proteger las identidades de envío, consulta reputación del dominio y reputación del remitente. Revisa la oferta gratuita de TrekMail en trekmail.net.