Pulsas Enviar y el servidor responde 250 OK. Dos semanas después descubres que el mensaje no llegó a la bandeja de entrada: estaba en spam o, según la política del gateway, pudo descartarse antes de que el destinatario iniciara sesión. El asunto y el contenido también pueden influir, pero otra posible causa es la reputación de tu dominio de correo, que quizá llevaba semanas deteriorándose.
Desde que Google y Yahoo endurecieron sus requisitos en febrero de 2024, los remitentes y flujos incluidos en sus definiciones deben cumplir normas concretas. Incumplirlas puede reducir la entrega o provocar rechazos, pero no implica un silenciamiento universal. Esta guía explica por qué falla la reputación del dominio, qué indican distintos códigos de error y cómo plantear la recuperación. Si antes necesitas una base de DNS, empieza por configurar el correo en tu dominio.
Qué es realmente la reputación del dominio de correo
La reputación del dominio reúne las señales de confianza que proveedores como Google, Microsoft y Yahoo asocian a un dominio según el comportamiento histórico del correo enviado. Las quejas por spam, los fallos de autenticación y una lista mal mantenida pueden perjudicarla. No existe una puntuación universal ni un plazo fijo de recuperación: cada proveedor pondera sus señales y el comportamiento reciente.
La reputación tampoco vuelve por sí sola a un valor predeterminado. Un dominio con un historial sólido puede tolerar errores ocasionales, mientras que otro afectado por quejas o fallos de autenticación podría tardar semanas o meses en mejorar. El resultado depende de la causa, el proveedor y la calidad del tráfico posterior.
Algunas señales pueden agregarse en el dominio raíz, pero los subdominios no se combinan de forma idéntica en todos los proveedores. Si marketing.example.com entra en una lista de bloqueo, ceo@example.com no irá automáticamente a spam, aunque el problema sí puede afectar señales relacionadas. La separación ayuda, pero no es una barrera absoluta.
El nivel máximo alcanzado y una clasificación persistente
Cuando Google clasifica un dominio como remitente masivo, aproximadamente 5,000 mensajes al día a cuentas personales de Gmail, esa clasificación puede mantenerse aunque después baje el volumen. Esto no significa una condición permanente en todos los proveedores. Para el tráfico al que se aplican, siguen vigentes requisitos como la cancelación con un clic en mensajes promocionales y una política DMARC publicada; las normas generales no obligan por sí solas a usar p=quarantine o p=reject. Comprueba siempre la política actual.
Si el volumen diario se mantiene por debajo de ~100 mensajes/día a Gmail, Postmaster Tools puede mostrar "No Data" porque no hay datos suficientes. Las pruebas con cuentas semilla y el análisis de rebotes aportan indicios limitados, pero no sustituyen los datos reales ni garantizan una conclusión.
Las 4 causas habituales del deterioro de la reputación
Cuando la reputación del dominio cae, conviene investigar cuatro áreas frecuentes: tasas de quejas, alineación de la autenticación, límite de consultas SPF y rebotes permanentes. No son las únicas causas. Identificar cuál afecta a tu tráfico evita aplicar una corrección inadecuada y perder tiempo.
1. El riesgo de superar el 0.3% de quejas
Las quejas por spam pueden dañar rápidamente un dominio. Google y Yahoo publican umbrales y criterios específicos. Llegar al 0.3%, es decir, 3 quejas por 1,000 mensajes, aumenta el riesgo de filtrado y puede afectar la elegibilidad para determinadas medidas de mitigación, pero no produce un bloqueo inmediato y universal. Google recomienda mantenerse por debajo del 0.1%. El 0.3% es un umbral de riesgo, no un objetivo. Verifica las reglas actuales aplicables a tu tráfico.
Yahoo puede calcular o presentar estas métricas con una base distinta. Antes de asumir que usa únicamente los mensajes que llegaron a la bandeja de entrada, consulta su definición vigente.
Escenario ilustrativo: envías 1,000 mensajes. 900 se filtran automáticamente como spam. 100 llegan a la bandeja de entrada. 1 persona se queja.
Cálculo ilustrativo: 1 queja ÷ 100 mensajes recibidos = tasa de quejas del 1.0%.
Resultado: el valor sería 3× superior al límite de este ejemplo, aunque el cálculo real depende de la definición del proveedor.
Las aperturas pueden disminuir, pero su medición no es fiable como prueba aislada. Google Postmaster Tools puede mostrar "Low" o "Bad" cuando hay datos suficientes, y tanto las etiquetas como la interfaz pueden cambiar. Combina esa información con rebotes, quejas y respuestas SMTP.
2. Autenticación no alineada y señales de suplantación
Puedes tener SPF y DKIM configurados y aun así fallar DMARC si ninguno se alinea con el dominio visible del remitente. DMARC aprueba cuando se alinea SPF o DKIM, no necesariamente ambos. Un fallo repetido puede perjudicar la reputación y parecer una suplantación, pero debe diagnosticarse con los encabezados completos.
Por ejemplo, utilizas un ESP como Mailchimp o SendGrid. El remitente del sobre usado por SPF apunta a mail.sendgrid.net, mientras que el encabezado From usa yourcompany.com. SPF puede aprobar porque la IP está autorizada, pero la alineación DMARC falla si tampoco existe una firma DKIM alineada. Los dominios personalizados del ESP pueden alinear SPF, DKIM o ambos, según su configuración.
Microsoft puede devolver 550 5.7.515 en determinados escenarios de autenticación o políticas, especialmente con tráfico de gran volumen. No siempre es un bloqueo de contenido ni se resuelve únicamente cambiando Return-Path. Revisa el texto completo y configura la autenticación de dominio personalizada de tu ESP según su documentación.
3. El límite de 10 consultas SPF (RFC 7208)
SPF no es una lista infinita. La RFC 7208, en su sección 4.6.4, limita a 10 los términos que provocan consultas DNS durante una evaluación SPF. Al incluir Google, Outlook, Zendesk, Mailchimp y un CRM, puedes acercarte al máximo. Las directivas include: anidadas también consumen consultas cuando se evalúan.
Con 11 consultas relevantes, la evaluación puede producir PermError. No des por hecho que algunos proveedores aceptarán siempre un SPF inválido mediante analizadores permisivos. El síntoma varía según el receptor y su política, así que confirma el resultado SPF y el árbol de consultas.
4. Rebotes permanentes y detección de direcciones
Microsoft presta atención a los rebotes permanentes. Una tasa de 2-3% puede usarse como señal operativa ilustrativa para revisar la lista, pero no es un umbral oficial que active siempre un bloqueo instantáneo por actividad automatizada. Distingue direcciones permanentemente inexistentes de errores permanentes por políticas o autenticación. Entre las respuestas posibles están 550 5.7.1 y errores temporales como 421 RP-001.
Incluso con un 0% de quejas puede haber bloqueos por otros motivos. Las métricas son distintas, pero una tasa de quejas nula no garantiza la entrega. Valida la lista y analiza los códigos mejorados antes de contactar direcciones de Microsoft.
Información específica de cada proveedor
Para mejorar la reputación del dominio, primero identifica qué proveedor está filtrando o rechazando el tráfico. Cada uno pondera señales distintas y ofrece herramientas diferentes. La disponibilidad de datos, los requisitos de volumen y las funciones cambian, por lo que conviene consultar la documentación vigente.
| Proveedor | Área de atención | Herramienta de diagnóstico | Matiz importante |
|---|---|---|---|
| Google (Gmail / Workspace) | Quejas e interacción, entre otras señales | Google Postmaster Tools | Con poco volumen (<100/día a Gmail) puede mostrar "No Data"; las cuentas semilla solo aportan una muestra |
| Microsoft (Outlook / 365) | Cumplimiento técnico y reputación de IP, entre otras señales | SNDS (Smart Network Data Services), sujeto a registro y disponibilidad | Las IP nuevas suelen requerir un aumento gradual; la limitación depende del tráfico y la política |
| Yahoo / AOL | Contenido y quejas, entre otras señales | Yahoo Sender Hub y CFL, cuando el remitente sea elegible | El Complaint Feedback Loop requiere registro y los informes ARF dependen de su cobertura y condiciones |
Flujo de diagnóstico: aislar el fallo
No adivines. Ejecuta estas comprobaciones de lectura únicamente en sistemas que estés autorizado a consultar y después revisa los encabezados. Los resultados aportan indicios sobre infraestructura, autenticación o comportamiento de envío, pero no identifican por sí solos una causa exacta.
Comprobación de infraestructura desde el terminal
Comprueba la pila de autenticación antes de cambiar políticas. Estas tres consultas de solo lectura cubren varios puntos frecuentes; sustituye los valores de ejemplo por recursos propios autorizados.
# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short
# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short
# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.
# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4
Si falla la comprobación FCrDNS y la IP no coincide con el nombre de host, puede aumentar el riesgo de rechazo en Gmail, Yahoo u otros receptores, pero no existe un rechazo universal automático. Corrige la configuración autorizada y espera a que se propague antes de repetir la consulta.
Análisis de encabezados
Envía un único mensaje de prueba esperado a una cuenta de Gmail que controles. Ábrelo, pulsa los tres puntos y selecciona "Mostrar original". Busca el encabezado Authentication-Results generado por el receptor; no confíes en una copia añadida por el remitente.
Señal problemática, fallo de alineación:
spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com
SPF ha aprobado. DKIM también. DMARC falla porque ninguno de los dominios se alinea con yourcompany.com. Este ejemplo muestra una configuración no alineada que puede afectar negativamente a la reputación, aunque una muestra no representa todo el tráfico.
Señal correcta, autenticación alineada:
spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass
Protocolo de recuperación
Si Google Postmaster Tools muestra "Bad", una recuperación podría requerir 2-4 semanas o más de envío estructurado y de calidad. No es un plazo garantizado ni el único enfoque posible. Trabaja por fases y observa las respuestas del proveedor antes de aumentar el volumen.
Fase 1: revisión de la lista
No bases una purga automática únicamente en que alguien no haya abierto o pulsado durante 90 días, porque la medición de aperturas es incompleta. Revisa consentimiento, actividad real, rebotes y obligaciones de conservación; suprime las direcciones no válidas confirmadas y los destinatarios que no esperan el correo. Si una dirección rebota dos veces con User Unknown, analiza los códigos mejorados y el estado de tu sistema de supresión antes del siguiente lote.
Fase 2: corrección técnica
No cambies DMARC de p=none a p=quarantine sin autorización y sin revisar informes y todos los remitentes legítimos. Despliega la política gradualmente; la cuarentena reduce ciertos abusos, pero no impide por sí sola toda suplantación. Si usas claves DKIM de 1024 bits, comprueba el algoritmo, la compatibilidad y la política actual del proveedor antes de rotarlas a 2048 bits y actualizar DNS. La guía de registros DNS requeridos muestra el formato previsto para dominios de TrekMail.
Fase 3: aumento gradual
Empieza con destinatarios que esperan el mensaje y cuya actividad reciente esté respaldada por señales fiables, no solo por aperturas durante los últimos 30 días. Este calendario es meramente ilustrativo y debe adaptarse al proveedor, la capacidad y las respuestas:
- Día 1: 50 mensajes
- Día 2: 100 mensajes
- Día 3: 200 mensajes
- Día 4: 400 mensajes
Revisa diariamente los datos disponibles. Si la reputación empeora, una pausa de 48 horas y la vuelta al volumen anterior pueden ser una opción, no una regla universal. Ajusta el plan a los códigos y políticas actuales.
Higiene de infraestructura: problemas poco visibles
Dos aspectos de infraestructura pueden afectar a la reputación sin generar señales evidentes. Incluso con la autenticación correcta, conviene revisar el transporte cifrado y el grupo de IP, junto con los demás factores.
Política de TLS
Muchos proveedores esperan TLS cuando está disponible, y algunos flujos o políticas exigen cifrado. Esto no significa que todo MTA deba imponer siempre TLS 1.2 a cualquier destino, pues SMTP puede usar TLS oportunista o políticas obligatorias específicas. Comprueba la configuración y los requisitos actuales de TrekMail o de tu proveedor.
Otros remitentes en una IP compartida
En un hosting compartido económico o un nivel gratuito de un ESP, puedes compartir IP con miles de remitentes. Si otro usuario envía spam, la IP podría entrar en Spamhaus SBL y afectar a tu correo, incluso si el dominio no originó el abuso. El efecto y la corrección dependen del listado y del proveedor.
Por encima de 100k/mes, una IP dedicada puede ofrecer más control, pero no es universalmente mejor y exige suficiente volumen y gestión. Con menos tráfico, puede convenir un proveedor que administre bien su pool o un SMTP externo. La opción BYO SMTP de TrekMail permite conectar Amazon SES, SendGrid o Mailgun cuando el plan lo admita; esto no significa necesariamente que la IP sea tuya, esté bajo tu control exclusivo o tenga buena reputación.
Cómo encaja TrekMail
La reputación del dominio es una restricción operativa, no una variable de marketing. Requiere DNS preciso, gestión responsable de destinatarios e infraestructura de salida adecuada.
Si administras varios dominios, consulta la guía de hosting de correo multidominio para estructurarlos y reducir riesgos compartidos. Para profundizar en la autenticación, la base de seguridad del correo explica las políticas DMARC y la rotación de claves DKIM.
Según la configuración y el plan vigentes, TrekMail puede proporcionar funciones de entrada como almacenamiento de tarifa plana, buzones IMAP, rutas catch-all y migración del servidor, sin precio por usuario en las ofertas descritas. Para la salida, se conecta un proveedor SMTP compatible. El asistente ayuda a configurar SPF/DKIM/DMARC durante el alta, pero debes validar DNS y cada flujo; no garantiza que todos los mensajes queden autenticados automáticamente.
La oferta descrita indica planes desde $3.50/mes. También menciona una prueba gratuita de 14 días que requiere tarjeta y un plan Nano sin tarjeta, descrito como gratuito, con 10 dominios y 5 GB. Los precios, límites, funciones y condiciones pueden cambiar; consulta trekmail.net/pricing antes de contratar.
Resumen
Entre las causas frecuentes de deterioro figuran una tasa de quejas superior al 0.3%, la falta de alineación DMARC en un ESP, superar el límite de 10 consultas SPF y los rebotes permanentes. No son las únicas causas, y cada una requiere su propia comprobación.
Si la reputación ya está dañada, revisa la lista con criterios fiables, corrige la capa técnica de forma gradual y aumenta el volumen según las respuestas. Dos a cuatro semanas son solo una referencia posible; no existe un plazo fijo ni un único protocolo.
Revisa hoy tu DNS mediante consultas autorizadas. Si detectas un error, planifica la corrección y verifícala antes de la siguiente campaña.
