Por qué tus correos llegan a spam: la guía de diagnóstico completa
Por CaptainDNS
Publicado el 4 de febrero de 2026
Actualizado el 10 de noviembre de 2026
- 5 causas principales: autenticación (SPF/DKIM/DMARC), reputación IP/dominio, contenido sospechoso, mal engagement, configuración técnica
- Verificación prioritaria: prueba tu IP en las blacklists principales y audita tu autenticación
- Desde 2024: Gmail y Yahoo exigen SPF, DKIM y DMARC para los remitentes de envíos masivos
- Rechazos de Outlook.com de noviembre de 2026 (AS9031519): sin un DMARC aplicable, añadir
p=nonees la solución provisional reportada. También se señalan rechazos con SPF, DKIM y DMARC en pass: si tu autenticación ya es correcta, no reescribas tus registros y sigue el procedimiento de notificación de la sección Outlook.com - A partir de noviembre de 2026: Spamhaus implanta de forma progresiva la exigencia de un HELO válido y de registros PTR y A coherentes para cada IP de envío, con el riesgo de que la IP acabe listada
- Umbral crítico: una tasa de quejas superior al 0,1% activa el envío a spam
- Diagnóstico rápido: analiza los encabezados de tus correos para identificar el problema exacto
Por qué tus correos se clasifican como spam
Cada día, miles de millones de correos son filtrados por los sistemas antispam. Uno de cada seis correos nunca llega a la bandeja de entrada de su destinatario. Para las empresas, es un problema crítico: facturas no recibidas, confirmaciones de pedido perdidas, comunicaciones con clientes ignoradas.
La clasificación como spam no es aleatoria. Los proveedores de correo (Gmail, Outlook, Yahoo) utilizan cientos de señales para decidir el destino de cada correo. Comprender estas señales es la clave para resolver el problema: se reducen a cinco pilares medibles (autenticación, reputación, seguridad del transporte, BIMI y engagement) que desglosa nuestra guía sobre la puntuación de entregabilidad de email.
Esta guía analiza las 5 causas principales de la clasificación como spam y te da un plan de acción concreto para cada situación. Ya seas administrador de sistemas, responsable de marketing o desarrollador, encontrarás las respuestas a tus preguntas.
Causa 1: Autenticación de correo ausente o incorrecta
La autenticación de correo se ha vuelto obligatoria en 2024. Gmail, Yahoo y Apple han anunciado que los correos no autenticados serán sistemáticamente rechazados o clasificados como spam.
Los 3 protocolos de autenticación
| Protocolo | Función | Impacto si está ausente |
|---|---|---|
| SPF | Lista los servidores autorizados a enviar para tu dominio | Rechazo o spam |
| DKIM | Firma criptográficamente cada correo | Spam o desconfianza |
| DMARC | Define la política en caso de fallo SPF/DKIM | Sin protección contra la suplantación; rechazos de Outlook.com reportados desde noviembre de 2026 (no es la única situación señalada) |
Verificar tu configuración
Utiliza una auditoría de dominio de correo para verificar instantáneamente si tu dominio está correctamente configurado:
- Introduce tu nombre de dominio
- Consulta los resultados SPF, DKIM y DMARC
- Sigue las recomendaciones de corrección
Errores SPF comunes
| Error | Consecuencia | Solución |
|---|---|---|
| Sin registro SPF | Correos clasificados como spam | Crear un registro TXT con v=spf1 |
| Demasiados includes (>10 lookups) | SPF inválido (PermError) | Optimizar o usar un servicio de flattening |
| IP faltante | Fallo SPF en ciertos envíos | Añadir la IP o el include del servicio |
| ~all vs -all | Política demasiado permisiva | Usar -all en producción |
Errores DKIM comunes
| Error | Consecuencia | Solución |
|---|---|---|
| Sin firma | Correo no autenticado | Configurar DKIM en el servidor de correo |
| Clave demasiado corta (<1024 bits) | Firma considerada débil | Generar una clave de 2048 bits |
| Selector incorrecto | Fallo de verificación | Verificar el DNS y la configuración del servidor |
| Cuerpo modificado | Firma inválida | Verificar los relés intermediarios |
DMARC: la política que lo cambia todo
DMARC es el director de orquesta de la autenticación. Sin él, incluso con SPF y DKIM válidos, tus correos pueden ser clasificados como spam, o rechazados durante la transacción SMTP. Un rechazo no deja nada en la carpeta de correo no deseado: el remitente recibe un informe de no entrega y el mensaje no se entrega. Desde principios de noviembre de 2026, varios operadores informan de este tipo de rechazo en Outlook.com para dominios sin registro DMARC. Los avisos de noviembre también afectan a dominios cuyos SPF, DKIM y DMARC se declaran correctos: la ausencia de DMARC no explica todos los casos (detalles en la sección de Outlook.com más abajo).
# Registro DMARC p=none con informes agregados
_dmarc.captaindns.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"
# Registro DMARC estricto (recomendado en producción)
_dmarc.captaindns.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com"
| Política | Comportamiento | Recomendación |
|---|---|---|
p=none | Solo monitorización | Fase inicial (2-4 semanas) |
p=quarantine | Correos sospechosos a spam | Fase intermedia |
p=reject | Correos sospechosos rechazados | Producción segura |
Causa 2: Reputación IP o dominio degradada
Incluso con una autenticación perfecta, tus correos pueden terminar en spam si tu reputación es mala. Los proveedores de correo mantienen puntuaciones de reputación basadas en el historial de envío.
Entender la reputación
La reputación se compone de dos elementos:
- Reputación IP: Puntuación de la dirección IP que envía los correos
- Reputación de dominio: Puntuación del dominio de envío (From)
| Factor | Impacto en la reputación |
|---|---|
| Tasa de quejas spam | Muy alto (umbral: 0,1%) |
| Tasa de rebote | Alto (umbral: 5%) |
| Engagement (aperturas, clics) | Moderado |
| Historial del dominio | Moderado |
| Blacklists | Crítico |
Verificar si tu IP está en una blacklist
Una IP en una blacklist importante (Spamhaus, Barracuda) verá sus correos sistemáticamente rechazados por Gmail, Outlook y Yahoo.
Para verificar si tu IP está listada, pruébala contra las principales DNSBL:
- Spamhaus ZEN: Utilizada por la mayoría de los grandes proveedores
- Barracuda BRBL: Muy extendida en empresas
- SpamCop: Basada en los informes de usuarios
Blacklists a vigilar en prioridad
| Blacklist | Impacto | Utilizada por |
|---|---|---|
| Spamhaus ZEN | Crítico | Gmail, Yahoo, Outlook |
| Barracuda BRBL | Crítico | Empresas, filtros Barracuda |
| SpamCop | Alto | Numerosos proveedores |
| UCEProtect | Moderado | Filtros antispam |
Mejorar tu reputación
| Acción | Impacto | Plazo |
|---|---|---|
| Solicitar el delisting de las blacklists | Inmediato | 24-72h |
| Reducir la tasa de quejas | Alto | 2-4 semanas |
| Retirar los hard bounces que afectan a la dirección (usuario desconocido, buzón inexistente). Un rechazo que apunta al dominio, a la IP o a la autenticación se corrige en el origen, sin retirar al destinatario | Alto | Inmediato |
| Calentar progresivamente las nuevas IPs | Preventivo | 4-6 semanas |
Causa 3: Contenido problemático
Los filtros antispam analizan el contenido de cada correo. Ciertos elementos activan automáticamente la clasificación como spam.
Palabras y expresiones a evitar
Los filtros antispam utilizan listas de palabras sospechosas. Aquí están las categorías más arriesgadas:
| Categoría | Ejemplos | Riesgo |
|---|---|---|
| Urgencia excesiva | "URGENTE", "Actúa ahora", "Última oportunidad" | Alto |
| Promesas financieras | "Gratis", "Gana dinero", "Sin costes" | Alto |
| Presión comercial | "Oferta limitada", "Solo quedan 24h", "Stock agotado" | Moderado |
| Expresiones sospechosas | "Haz clic aquí", "100% garantizado", "Sin compromiso" | Moderado |
Estructura del correo
| Problema | Por qué se filtra | Solución |
|---|---|---|
| Correo 100% imagen | Texto oculto, técnica de spammer | Ratio 60% texto / 40% imágenes |
| Enlaces acortados (bit.ly) | Ocultan el destino | Usar las URLs completas |
| Demasiados enlaces | Comportamiento spam típico | Máximo 3-5 enlaces por correo |
| Sin versión texto | Solo HTML = sospechoso | Siempre incluir text/plain |
| Formularios integrados | Técnica de phishing | Enlaces hacia el sitio web |
Ratio HTML/texto óptimo
Contenido recomendado:
- Texto: 60-80%
- Imágenes: 20-40%
- Enlaces: 3-5 máximo
- Tamaño total: < 100 Ko
Causa 4: Mal engagement de los destinatarios
Los proveedores de correo miden cómo los destinatarios interactúan con tus correos. Un engagement bajo indica contenido no deseado.
Señales de engagement negativo
| Señal | Impacto | Umbral crítico |
|---|---|---|
| Quejas spam | Muy alto | >0,1% activa el spam |
| Hard bounces | Alto | >5% degrada la reputación |
| Soft bounces repetidos | Moderado | >10% en 30 días |
| Baja tasa de apertura | Moderado | <10% en listas activas |
| Bajas elevadas | Moderado | >1% por campaña |
El círculo vicioso del spam
Bajo engagement → Clasificación como spam → Aún menos engagement → Reputación degradada
Para romper este círculo:
- Limpia tus listas: Elimina las direcciones inactivas desde hace más de 6 meses
- Segmenta: Envía contenido relevante a cada segmento
- Respeta el consentimiento: Doble opt-in obligatorio
- Facilita la baja: Enlace visible, proceso en 1 clic
Buenas prácticas de higiene de lista
| Acción | Frecuencia | Impacto |
|---|---|---|
| Eliminar los hard bounces que afectan a la dirección (usuario desconocido, buzón inexistente). Si el rechazo apunta al dominio, a la IP o a la autenticación: corregir la causa y reenviar, sin tocar la lista | Inmediato | Crítico |
| Eliminar las quejas spam | Inmediato | Crítico |
| Limpiar los inactivos (>6 meses) | Mensual | Alto |
| Re-engagement de los tibios | Trimestral | Moderado |
| Validación de correos al registrarse | Continuo | Preventivo |
Causa 5: Configuración técnica deficiente
Problemas de configuración técnica pueden sabotear todos tus esfuerzos.
Checklist de configuración del servidor
| Elemento | Verificación | Comando |
|---|---|---|
| Reverse DNS (PTR) | La IP debe resolver hacia un FQDN | dig -x <IP> |
| FQDN hacia IP | El FQDN debe resolver hacia la IP | dig A <fqdn> |
| HELO/EHLO | Debe resolver hacia la IP de envío y mantenerse igual | Logs del servidor |
| Puerto 25 abierto | Sin bloqueo del ISP | telnet mail.server.com 25 |
| TLS activado | STARTTLS obligatorio | Test de conexión |
Reverse DNS: por qué es crítico
El reverse DNS (registro PTR) es verificado por todos los proveedores principales. Sin PTR válido, tus correos son inmediatamente sospechosos.
# Verificar el PTR de tu IP
dig -x 192.0.2.1
# Resultado esperado
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.captaindns.com.
# El FQDN debe resolver hacia la misma IP
dig A mail.captaindns.com
# Resultado: 192.0.2.1
Configuración HELO/EHLO
El servidor de correo se identifica con HELO o EHLO. El nombre anunciado debe:
- Ser un FQDN válido (no una IP, no "localhost", no un nombre por defecto del proveedor de hosting)
- Resolver hacia la IP que envía el correo (registro A)
- Mantenerse igual de una conexión a otra desde esa IP
El PTR de esa IP, por su parte, apunta a un FQDN que resuelve hacia la misma IP: es el FCrDNS (forward-confirmed reverse DNS).
# Malo
EHLO localhost
EHLO [192.0.2.1]
EHLO server1
# Bueno
EHLO mail.captaindns.com
Spamhaus, noviembre de 2026. A partir de noviembre de 2026, Spamhaus implanta de forma progresiva una exigencia para cada IP de envío: un HELO válido, un reverse DNS (PTR) y un registro A coherente. Una IP que no la cumpla se expone a ser listada. Spamhaus no publica ni un día concreto ni un calendario. En IPv6, la dirección de envío debe pertenecer a un bloque /64 o mayor, con un reverse DNS válido. Comprueba desde ahora el PTR y el registro A de cada IP de envío con los comandos dig anteriores y, después, el nombre anunciado en el HELO en los logs de tu servidor. Para un control concreto, envía un mensaje a un buzón externo y lee el encabezado Received que añade el servidor destinatario: el nombre que sigue a from suele ser el que tu servidor anuncia en HELO/EHLO. Según el servidor destinatario, aparece más bien entre paréntesis, tras helo= o HELO. El analizador de encabezados de email que se presenta más abajo lo muestra. Si tus servidores de envío son también tus MX, el testeador SMTP/MX señala un banner cuyo nombre no coincide con el del MX.
Diagnóstico por proveedor
Cada proveedor tiene sus particularidades. Aquí te explicamos cómo diagnosticar los problemas para los principales.
Gmail
Herramientas de diagnóstico:
- Google Postmaster Tools: reputación de dominio e IP
- Encabezados Gmail: busca
X-Gm-SpamyX-Gm-Phishy
Requisitos Gmail 2024:
| Criterio | Volumen <5000/día | Volumen >5000/día |
|---|---|---|
| SPF o DKIM | Obligatorio | Obligatorio |
| DMARC | Recomendado | Obligatorio |
| Tasa de quejas | <0,3% | <0,1% |
| TLS | Recomendado | Obligatorio |
| Baja en 1-clic | - | Obligatorio |
Códigos de error comunes:
| Código | Significado | Acción |
|---|---|---|
421 4.7.0 | Demasiadas conexiones | Reducir el ritmo |
550 5.7.1 | Política DMARC | Corregir SPF/DKIM |
550 5.7.26 | Fallo de autenticación | Verificar SPF, DKIM |
Outlook.com y Microsoft 365: distinguir los diagnósticos
Microsoft recibe los correos a través de dos servicios distintos, que no siempre reaccionan igual. Outlook.com es el correo para particulares (direcciones outlook.com, hotmail.com, live.com, msn.com). Microsoft 365 aloja el correo de empresa, bajo el dominio de cada cliente. El nombre del servidor que rechaza, en el informe de no entrega (NDR), ayuda a saber cuál responde: MailRoute describe los servidores de Outlook.com como olc.protection.outlook.com, y el dominio de Microsoft 365 que probó Spam Resource pasaba por un servidor en mail.protection.outlook.com.
Herramientas de diagnóstico:
- SNDS (Smart Network Data Services): reputación IP
- JMRP: feedback loop
Particularidades de Outlook:
- Utiliza Spamhaus y blacklists propias
- Filtrado agresivo de dominios nuevos (<30 días)
- Programa SNDS para monitorizar la reputación
Outlook.com (particulares)
La regla publicada por Microsoft se dirige a los remitentes de gran volumen. Un dominio que envía más de 5000 mensajes al día a Outlook.com debe superar SPF y DKIM, publicar un registro DMARC (como mínimo p=none) y superar DMARC gracias a un SPF o un DKIM alineado con el dominio del From. El anuncio del sitio Postmaster de Outlook.com fija el inicio el 5 de mayo de 2025, primero con el envío a la carpeta de correo no deseado y después con rechazos; el rechazo asociado es 550 5.7.515.
El rechazo reportado tiene esta forma (MailRoute señala también una variante sin el código entre paréntesis):
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
En el informe de no entrega publicado en Microsoft Q&A el 6 de noviembre, este rechazo llega dentro de otro código. La línea "Error Details" dice, con los datos personales retirados por el moderador:
Error: 550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records
El informe muestra 550 5.7.23 como código de estado, bajo el título "SPF validation error". El texto de ayuda que lo acompaña solo habla de SPF: verificar el registro, publicar uno solo, incluir en él spf.protection.outlook.com. El diagnóstico detallado está después de la flecha: es el 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records", que Hornblower409 vincula con AS9031519. Esta plantilla no prueba que tu SPF esté mal. En el mismo hilo, Martin informa de este envoltorio y declara que SPF, DKIM y DMARC llevan años correctos.
Si recibes este rechazo, lee y guarda primero el informe completo: código exterior, texto interior, servidor que rechaza y posible AS9031519. Después, busca el registro DMARC en _dmarc.<dominio>. En un subdominio, mira también el del dominio padre, cuya política puede aplicarse. Puedes verificar el registro DMARC publicado sin línea de comandos. Una consulta DNS que no llega a término (tiempo de espera agotado, error del servidor) no prueba que no haya registro: repítela antes de sacar conclusiones. Esta comprobación muestra lo que está publicado, no el resultado SPF o DKIM de un mensaje concreto.
Si ningún registro DMARC se aplica al dominio:
- Publica un registro TXT en
_dmarc.<dominio>con el valorv=DMARC1; p=none. Muchos proveedores DNS añaden el dominio por su cuenta: en ese caso, escribe solo_dmarccomo nombre. Un dominio solo tiene un registro DMARC: no crees un segundo con el mismo nombre, ni sustituyas una política más estricta que ya funciona. - Comprueba que al menos SPF o DKIM pasa y está alineado con el dominio de la dirección de remitente visible (From). Un registro DMARC sin autenticación alineada falla igualmente. Para controlar la alineación, envía un mensaje a otro buzón y lee su encabezado
Authentication-Results(consulta cómo leer los encabezados de un correo). - Espera a que caduquen las cachés DNS: los servidores guardan un tiempo en memoria el registro antiguo, o el hecho de que no existía ninguno. Para un registro antiguo, ese plazo es su TTL, fijado en tu zona DNS. Si no existía ningún registro, el tiempo durante el que los servidores retienen esa ausencia depende del registro SOA de tu zona (caché negativa, RFC 2308), no del TTL del nuevo registro. Después, reenvía los mensajes rechazados. Un 550 es un fallo permanente: tu servidor no volverá a intentar el envío.
Añadir un p=none se señala como solución provisional para algunos dominios sin DMARC (Hornblower409 y Cameron Scott en el hilo de Microsoft Q&A), no como una reparación del servicio de Microsoft. p=none no pide ni cuarentena ni rechazo en virtud de la política DMARC. Eso no garantiza la aceptación por parte de Outlook.com, ni la llegada a la bandeja de entrada.
Si SPF, DKIM y DMARC ya son correctos y tus mensajes pasan la autenticación:
- No reescribas una configuración correcta solo para responder al texto del informe. No publiques un segundo registro SPF: dos registros SPF provocan un PermError (consulta la guía SPF PermError). Tampoco añadas
include:spf.protection.outlook.comporque el informe lo sugiera: tu SPF debe autorizar los servicios que realmente envían en nombre de tu dominio. - Conserva el informe completo y los datos técnicos, y después notifica el rechazo a Microsoft Sender Support. Es lo que aconseja Hornblower409 cuando los mensajes rechazados con AS9031519 pasan la autenticación.
- En empresa, Daniel-Vo pedía el 9 de noviembre que se facilitaran al soporte de Microsoft 365 Network Message ID recientes, los logs de los mensajes afectados y ejemplos en formato .eml. Estos datos van al soporte, no a un foro público.
- Vuelve a intentarlo más tarde, sin garantía de resultado. Los rechazos se describen como intermitentes, pero un 550 sigue siendo un fallo permanente: tu servidor no volverá a intentar el envío, te toca reenviar el mensaje.
Un pass obtenido en otro mensaje, o con otro destinatario, ayuda al diagnóstico sin probar el veredicto del servidor de Outlook.com que rechazó el tuyo. Como los rechazos son parciales, un reenvío aceptado tampoco demuestra que la configuración sea correcta, advierte MailRoute: comprueba los registros en lugar del resultado de un solo envío.
Microsoft 365 (empresa)
Microsoft 365 aplica sus propios mecanismos de filtrado. Añade un veredicto propietario compauth en la cabecera Authentication-Results; un compauth=fail aumenta el riesgo de acabar en la carpeta de correo no deseado (consulta la guía compauth de Microsoft 365). En la prueba de Al Iverson (Spam Resource) del 7 de noviembre de 2026, el mensaje rechazado hacia outlook.com fue aceptado hacia el dominio de Microsoft 365 probado. Esta prueba aislada no demuestra que los destinatarios alojados en Microsoft 365 estén a salvo, ni que sufran el mismo incidente. En cambio, los clientes de Microsoft 365 pueden verse afectados como remitentes, cuando escriben a Outlook.com: a ellos se dirige la petición de soporte de Daniel-Vo citada más arriba. Lee siempre el texto completo del NDR.
Códigos de error de Outlook.com y Microsoft 365
| Código | Significado | Acción |
|---|---|---|
550 5.7.1 | Rechazo genérico: leer el texto completo del NDR | Solicitar un delisting solo si el texto indica un bloqueo de IP, siguiendo el procedimiento que indica |
550 5.7.1 con "Message lacks SPF/DKIM/DMARC Auth Records" | Rechazo de Outlook.com reportado desde noviembre de 2026 para dominios sin DMARC, pero también para dominios cuya autenticación pasa | Verificar el registro DMARC y la alineación SPF o DKIM sin concluir que fallan solo por el texto del mensaje. Sin DMARC: publicar p=none y después reenviar. Si todo pasa: notificarlo a Microsoft Sender Support |
550 5.7.23, cuando acompaña al diagnóstico AS9031519 | Envoltorio orientado a SPF alrededor del rechazo 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records" (informes publicados en Microsoft Q&A, noviembre de 2026). Por sí solo, este código indica un fallo SPF y no prueba este incidente | Leer el diagnóstico después de la flecha antes de tocar el SPF y luego seguir la situación que corresponda (DMARC ausente o autenticación ya correcta) |
550 5.7.515 | Nivel de autenticación requerido no alcanzado (remitentes de gran volumen hacia Outlook.com) | SPF y DKIM válidos, DMARC publicado, alineación con el From |
550 5.7.606 | IP con baja reputación | Consultar SNDS y seguir el procedimiento de delisting indicado en el NDR. El rechazo apunta a la IP: no retirar a los destinatarios rechazados |
421 4.7.0 | Límite de ritmo | Reducir los envíos |
Yahoo / AOL
Herramientas de diagnóstico:
- Yahoo Sender Hub: reputación y guidelines
- Complaint Feedback Loop: quejas en tiempo real
Requisitos Yahoo 2024:
| Criterio | Requerido |
|---|---|
| SPF | Obligatorio |
| DKIM | Obligatorio |
| DMARC | Obligatorio para >5000 correos/día |
| Baja en 1-clic | Obligatorio |
| Tasa de quejas | <0,3% |
Plan de acción recomendado
Paso 1: Diagnóstico inmediato (30 minutos)
- Prueba tu IP en las blacklists principales
- Verifica la autenticación (SPF, DKIM, DMARC) de tu dominio
- Analiza un correo problemático a través de sus encabezados con el analizador de encabezados de email
Si tus mensajes son rechazados en lugar de clasificados como spam, parte del texto exacto del NDR antes de cualquier solicitud de delisting. Un mismo código 550 5.7.1 abarca varias causas. "Message lacks SPF/DKIM/DMARC Auth Records" no apunta a tu IP: verifica DMARC y la alineación, sin concluir que fallan solo por el texto del mensaje. También se señalan rechazos con la autenticación en pass; en ese caso, sigue el procedimiento "autenticación ya correcta" de la sección Outlook.com. Un delisting solo se justifica si el texto señala la IP o una lista de bloqueo.
Paso 2: Correcciones prioritarias (1-2 días)
- Solicita el delisting si estás en una blacklist (Spamhaus, Barracuda en prioridad)
- Corrige los errores de autenticación detectados
- Configura el reverse DNS si falta
Paso 3: Mejora continua (2-4 semanas)
- Inscríbete en los feedback loops (Gmail, Outlook, Yahoo)
- Monitoriza las tasas de quejas (objetivo <0,1%)
- Limpia tus listas: retira las direcciones inactivas desde hace más de 6 meses y los hard bounces cuyo rechazo afecta a la dirección (usuario desconocido, buzón inexistente). Si el rechazo apunta a tu dominio, a tu IP o a tu autenticación, corrige la causa y reenvía, sin retirar al destinatario
- Implementa una monitorización regular de las blacklists
Paso 4: Prevención a largo plazo
- Doble opt-in para todas las inscripciones
- Baja fácil (1-clic, header list-unsubscribe)
- Monitorización automatizada de blacklists y reputación
- Auditoría trimestral de la configuración de correo
FAQ
¿Por qué mis correos llegan a spam aunque tengo configurado SPF y DKIM?
SPF y DKIM no son suficientes por sí solos. Desde 2024, Gmail y Yahoo también exigen DMARC a los remitentes de envíos masivos. En Outlook.com se reportan desde principios de noviembre de 2026 rechazos a dominios sin DMARC, incluso con volúmenes bajos, pero también a dominios cuya autenticación pasa; el 9 de noviembre, un moderador de Microsoft Q&A los vinculaba a una degradación del servicio (consulta la pregunta siguiente). Verifica también que tu IP no esté en una blacklist y que tu tasa de quejas sea inferior al 0,1%. Un fallo en cualquiera de estos puntos puede activar el spam, incluso con autenticación parcial.
¿Por qué Outlook.com rechaza mis correos con AS9031519 a pesar de tener SPF y DKIM válidos?
Desde principios de noviembre de 2026 se reportan dos situaciones. Varios operadores (lista Mailop, MailRoute, Spam Resource) observan este rechazo en dominios sin registro DMARC; participantes del hilo de Microsoft Q&A "SPF Validation Error" también lo señalan, de forma intermitente, con SPF, DKIM y DMARC en pass. El 9 de noviembre de 2026, Daniel-Vo, presentado en ese hilo como "Microsoft External Staff" y moderador, describía un problema del servicio Exchange hacia Outlook.com, Hotmail.com y Live.com, clasificado como "service degradation", cuya causa seguía en investigación. No es ni una entrada de Service Health ni una nueva regla publicada. El informe de no entrega puede mostrar 550 5.7.23 y el título "SPF validation error": lee el diagnóstico después de la flecha antes de tocar el SPF. Si no se aplica ningún DMARC, publica un TXT v=DMARC1; p=none en _dmarc.<dominio>, comprueba que SPF o DKIM pasa y sigue alineado con el dominio del From, y después reenvía los mensajes rechazados: un 550 es definitivo y tu servidor no lo volverá a intentar. p=none es una solución provisional reportada, sin garantía de aceptación. Si la autenticación ya pasa, no reescribas tus registros: conserva el informe completo y notifica el rechazo a Microsoft Sender Support.
¿Cómo sé si mi IP está en una blacklist?
Utiliza un verificador de blacklist que pruebe tu IP contra las principales listas (Spamhaus, Barracuda, SpamCop). La prueba cubre más de 25 blacklists simultáneamente y proporciona los enlaces de delisting para cada lista afectada. Prueba tu IP inmediatamente si tus correos son rechazados o clasificados como spam.
¿Cuánto tiempo se tarda en salir de una blacklist?
Los plazos varían según la blacklist: SpamCop se elimina automáticamente en 24-48h sin nuevo informe. Spamhaus procesa las solicitudes manuales en 24-48h. Barracuda responde en 12-24h. UCEProtect tiene un plazo de 7 días. En todos los casos, el problema que originó el listado debe corregirse antes de solicitar el delisting.
Mis correos van a spam solo en Gmail, ¿por qué?
Gmail es particularmente estricto desde febrero de 2024. Verifica los siguientes puntos: (1) ¿Está DMARC configurado con al menos p=none? (2) ¿La tasa de quejas está por debajo del 0,1%? (3) ¿Está implementada la baja en 1-clic para los correos masivos? Usa Google Postmaster Tools para ver tu reputación de dominio en Gmail.
¿Cómo puedo mejorar mi tasa de entregabilidad rápidamente?
Acciones inmediatas: (1) Verifica y corrige tu autenticación SPF/DKIM/DMARC. (2) Prueba tu IP en las blacklists y solicita el delisting si es necesario. (3) Retira de tu lista los hard bounces cuyo rechazo afecta a la dirección (usuario desconocido, buzón inexistente), así como los inactivos de más de 6 meses. Si el rechazo apunta a tu dominio, a tu IP o a tu autenticación, corrige la causa y reenvía antes de tocar la lista. (4) Reduce los envíos hacia las direcciones que nunca abren. Estas acciones pueden mejorar la entregabilidad en 1-2 semanas.
¿Cuál es la tasa de quejas aceptable?
El umbral crítico es 0,1% (1 queja por cada 1000 correos). Por encima, Gmail y Yahoo comienzan a clasificar tus correos como spam. Google recomienda mantenerse por debajo del 0,05% para una entregabilidad óptima. Monitoriza esta tasa a través de los feedback loops y Google Postmaster Tools.
Mi servidor de correo está bien configurado pero mis correos siguen yendo a spam, ¿qué pasa?
Si la configuración técnica es correcta, el problema probablemente está relacionado con: (1) La reputación de tu IP o dominio (verifica las blacklists). (2) El contenido de tus correos (palabras activadoras, ratio imagen/texto). (3) El engagement de los destinatarios (baja tasa de apertura, quejas). Analiza tus encabezados para identificar el factor desencadenante.
¿Cómo caliento una nueva IP para el envío de correos?
El calentamiento de IP consiste en aumentar progresivamente el volumen de envío durante 4-6 semanas. Comienza con 50-100 correos/día hacia tus destinatarios más comprometidos, luego duplica el volumen cada semana. Monitoriza los bounces y quejas. Nunca pases de 0 a miles de correos/día o activarás los filtros antispam.
¿Qué cambia la exigencia HELO/PTR de Spamhaus de noviembre de 2026?
A partir de noviembre de 2026, Spamhaus implanta de forma progresiva una exigencia para cada IP de envío: un reverse DNS (PTR) que apunte a un FQDN, que ese FQDN resuelva hacia la misma IP (registro A) y un nombre HELO/EHLO que resuelva hacia la IP de envío y se mantenga igual de una conexión a otra. Según Spamhaus, un reverse DNS ausente o incoherente es uno de los motivos más habituales para plantearse listar una IP. Spamhaus no ha publicado ni un día concreto ni un calendario: se trata de un despliegue progresivo, no de un corte en una fecha fija. En IPv6, la dirección de envío debe estar en un bloque /64 o mayor, con un reverse DNS válido.
Glosario
- DNSBL (DNS-based Blackhole List): Lista negra de IPs consultable por consulta DNS. También llamada RBL (Realtime Blackhole List).
- SPF (Sender Policy Framework): Registro DNS que lista los servidores autorizados a enviar correos para un dominio.
- DKIM (DomainKeys Identified Mail): Firma criptográfica añadida a los correos para probar su autenticidad.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Política que define el tratamiento de los correos que fallan SPF/DKIM.
- Hard bounce: Fallo de entrega permanente (código 5xx). Puede que la dirección no exista, pero el rechazo también puede apuntar a tu dominio o a tu autenticación. El servidor de envío no vuelve a intentarlo: tras la corrección, reenvía el mensaje. Antes de retirar una dirección de tus listas, comprueba que el rechazo se refiere realmente a ella.
- Soft bounce: Correo rechazado temporalmente (buzón lleno, servidor no disponible).
- Feedback loop: Programa que permite a los remitentes recibir los informes de spam de los destinatarios.
- Reverse DNS (PTR): Registro DNS que asocia una dirección IP a un nombre de dominio.
- FQDN (Fully Qualified Domain Name): Nombre de dominio completo (ej: mail.captaindns.com).
- Reputación IP: Puntuación asignada a una dirección IP basada en su historial de envío.
Guías relacionadas sobre blacklists
- Cómo eliminar tu IP de una blacklist: la guía completa del delisting: Procedimientos detallados para Spamhaus, Barracuda, SpamCop y más
- Spamhaus vs Barracuda vs SpamCop: Comparativa: Las 3 blacklists principales explicadas
Fuentes
- Google Email Sender Guidelines (2024) (requisitos oficiales Gmail)
- Yahoo Sender Best Practices (guidelines Yahoo/AOL)
- Microsoft 365 Anti-Spam Protection (documentación Outlook)
- Microsoft Support - Fix NDR error 550 5.7.515 in Outlook.com (regla oficial para los remitentes de gran volumen hacia Outlook.com)
- Outlook.com Postmaster (anuncio de los requisitos para los remitentes de gran volumen, inicio el 5 de mayo de 2025, consultado el 8 de noviembre de 2026)
- Spam Resource - Microsoft newly rejecting mail lacking DMARC? (7 de noviembre de 2026) (observaciones y pruebas de Al Iverson)
- Mailop - Microsoft requiring DMARC now or just us? (testimonios de operadores, noviembre de 2026)
- MailRoute - 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (6 de noviembre de 2026) (experiencia operativa de un proveedor de relay)
- Microsoft Q&A - SPF Validation Error (hilo abierto el 6 de noviembre de 2026) (intercambio de soporte, no documentación normativa: declaración del 9 de noviembre de 2026 de Daniel-Vo, Microsoft External Staff y moderador, respuesta del moderador voluntario Hornblower409 y testimonios de usuarios; consultado el 10 de noviembre de 2026)
- The Register - Outlook.com bounces legit emails as Microsoft's authentication crackdown goes sideways (9 de noviembre de 2026) (artículo de prensa)
- RFC 7489 - DMARC (especificación técnica)
- Spamhaus - Understanding DNSBLs (funcionamiento de las blacklists)
- Spamhaus Sender Guidelines (requisitos HELO, PTR y A para las IP de envío)
