Probar la entregabilidad del email: la guía completa antes del envío

⚡TL;DR

• Uno de cada cinco emails nunca llega a la bandeja de entrada, principalmente por una autenticación SPF, DKIM o DMARC ausente o mal configurada
• Puntuación de entregabilidad: SPF (+25), DKIM (+25), DMARC (+20), MX/PTR (+15), encabezados (+15) = 100 puntos posibles
• Desde 2024: Gmail y Yahoo exigen SPF + DKIM obligatorios, y DMARC para los remitentes masivos (> 5 000 emails/día)
• Corrección prioritaria: una prueba de 30 segundos identifica los problemas exactos, esta guía detalla cómo corregirlos uno por uno

Acabas de lanzar una campaña de email. Todo está listo: el contenido está cuidado, el diseño es impecable, la lista de destinatarios está limpia. Tres días después, caen las estadísticas: el 22 % de tus emails nunca llegaron a la bandeja de entrada. Sin rebotes. Sin errores visibles. Tus mensajes simplemente desaparecieron en una carpeta de spam o fueron silenciosamente rechazados por el servidor de recepción.

Este escenario no es un caso extremo. Según los datos de Validity (Sender Score), uno de cada cinco emails enviados en el mundo nunca llega a la bandeja de entrada de su destinatario. Para las empresas, el coste es directo: facturas ignoradas, confirmaciones de pedido perdidas, prospectos de marketing desperdiciados, y una reputación de dominio que se degrada silenciosamente.

La buena noticia: la mayoría de estos problemas son detectables antes del envío. Una prueba de entregabilidad analiza tu configuración DNS (SPF, DKIM, DMARC), verifica la reputación de tu IP, controla tus encabezados de email y produce una puntuación global sobre 100. En 30 segundos, sabes exactamente qué funciona y qué bloquea tus emails.

Esta guía cubre el proceso completo: por qué probar, cómo funciona una prueba de entregabilidad, cómo interpretar cada sección de la puntuación, y sobre todo cómo corregir los problemas identificados para pasar de 40/100 a 100/100. Tanto si eres administrador de sistemas, desarrollador o responsable de marketing, cada sección contiene acciones concretas.

Por qué probar la entregabilidad antes de cada envío

El problema invisible

La entregabilidad del email es un problema silencioso. A diferencia de un sitio web caído (visible de inmediato), un email que llega al spam no genera ninguna alerta. El remitente piensa que el mensaje fue entregado. El destinatario no sabe que un email le espera en su carpeta de spam. Nadie se queja porque nadie lo sabe.

Los proveedores de correo (Gmail, Outlook, Yahoo, Apple Mail) toman decisiones de filtrado en cuestión de milisegundos, basándose en cientos de señales. Y estas señales evolucionan constantemente. Un dominio que pasaba todos los controles hace seis meses puede fallar hoy porque un proveedor añadió un include SPF adicional, o porque la rotación de clave DKIM no se realizó.

Los 5 controles de una prueba de entregabilidad

Una prueba completa verifica cinco categorías distintas, cada una contribuyendo a la puntuación global:

Categoría	Puntos	Lo que se verifica
SPF	25/100	Registro DNS TXT válido, IP del remitente autorizada, número de lookups
DKIM	25/100	Firma criptográfica válida, clave pública DNS accesible, alineación del dominio
DMARC	20/100	Política publicada, alineación SPF/DKIM, dirección de reporte configurada
MX / PTR	15/100	Registros MX presentes, reverse DNS configurado, IP no en lista negra
Encabezados	15/100	From/Reply-To coherentes, Message-ID válido, sin campos sospechosos

Una puntuación inferior a 70/100 significa que tus emails tienen una probabilidad significativa de ser clasificados como spam. Por debajo de 50/100, la mayoría de los proveedores rechazará o filtrará tus mensajes.

Las exigencias de Gmail y Yahoo 2024

Desde febrero de 2024, Gmail y Yahoo han hecho obligatorios controles que antes eran opcionales. Estas exigencias se aplican a todos los remitentes, con reglas adicionales para los envíos masivos:

Para todos los remitentes:

• SPF o DKIM válido (al menos uno de los dos)
• Registro DNS de tipo PTR (reverse DNS) configurado para la IP de envío
• Tasa de spam declarada en Google Postmaster Tools inferior al 0,3 %

Para remitentes masivos (> 5 000 emails/día hacia Gmail):

• SPF y DKIM válidos (ambos obligatorios)
• DMARC publicado con al menos p=none
• Alineación del dominio From con SPF o DKIM
• Encabezado List-Unsubscribe con desuscripción en un clic (RFC 8058)
• Formato conforme a la RFC 5322

No cumplir con estas exigencias provoca un rechazo progresivo. Gmail no bloquea el 100 % de los emails de un día para otro: comienza por diferir el 4 % de los mensajes (código 4xx), luego aumenta el porcentaje hasta el rechazo permanente (código 5xx) si el problema no se corrige.

Cómo funciona una prueba de entregabilidad

Una prueba de entregabilidad reproduce el proceso exacto que un servidor de recepción ejecuta cuando recibe tu email. Estas son las cuatro etapas, en orden.

Etapa 1: resolución DNS y verificación SPF

La prueba comienza interrogando el DNS de tu dominio para recuperar el registro SPF.

# Recuperar el registro SPF de captaindns.com
dig TXT captaindns.com +short | grep "v=spf1"

El registro SPF es un registro DNS de tipo TXT que comienza por v=spf1. Lista los servidores autorizados para enviar emails por tu dominio. Aquí tienes un ejemplo real:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

El servidor de recepción compara la IP del servidor que envió el email con las IP autorizadas por tu SPF. El proceso es recursivo: cada include: desencadena una nueva consulta DNS para recuperar las IP del subdominio referenciado.

Punto crítico: la RFC 7208 limita a 10 el número de consultas DNS (lookups) durante la evaluación SPF. Los mecanismos include, a, mx, redirect y exists cuentan cada uno como un lookup. Los mecanismos ip4 e ip6 no cuentan (son valores directos). En el lookup número 11, el servidor devuelve permerror y tu SPF se considera inválido.

# Verificar cuántos lookups genera tu SPF
# Cada include genera al menos 1 lookup
dig TXT _spf.google.com +short
# Resultado: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ..."
# Cada sub-include también cuenta

Etapa 2: verificación de la firma DKIM

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada email. El servidor de envío firma el mensaje con una clave privada. El servidor de recepción verifica esta firma recuperando la clave pública correspondiente en el DNS.

La firma DKIM está presente en el encabezado DKIM-Signature del email:

DKIM-Signature: v=1; a=rsa-sha256; d=captaindns.com; s=google;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

Los campos clave:

• d=: el dominio que reivindica la firma (debe corresponder al dominio From para DMARC)
• s=: el selector, que identifica qué clave pública usar
• a=: el algoritmo de firma (rsa-sha256 o ed25519-sha256)
• bh=: el hash del cuerpo del mensaje
• b=: la firma en sí

La prueba recupera la clave pública vía DNS:

# Recuperar la clave pública DKIM
# Formato: selector._domainkey.dominio
dig TXT google._domainkey.captaindns.com +short

La respuesta contiene un registro TXT con la clave pública:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

El servidor de recepción utiliza esta clave pública para verificar la firma. Si el cuerpo del mensaje o los encabezados firmados fueron modificados después de la firma, la verificación falla.

RSA vs Ed25519: la mayoría de los servidores utilizan RSA-SHA256 con claves de 2048 bits. Ed25519 es más rápido y genera firmas más cortas, pero el soporte del lado de la recepción todavía no es universal. Google Workspace y Microsoft 365 solo soportan RSA para la firma DKIM saliente en marzo de 2026.

Etapa 3: evaluación DMARC y alineación

DMARC (Domain-based Message Authentication, Reporting, and Conformance) verifica que SPF y DKIM no solo son válidos, sino también alineados con el dominio visible en el campo From del email.

# Recuperar la política DMARC
dig TXT _dmarc.captaindns.com +short

Resultado típico:

"v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"

Desglosemos cada etiqueta:

Etiqueta	Valor	Significado
v=DMARC1	obligatorio	Identifica el registro como DMARC
p=	none, quarantine, reject	Política aplicada a los emails que fallan
rua=	dirección email	Destino de los informes agregados (estadísticas diarias)
ruf=	dirección email	Destino de los informes forenses (muestras de fallos)
adkim=	r (relaxed) o s (strict)	Modo de alineación DKIM
aspf=	r (relaxed) o s (strict)	Modo de alineación SPF
pct=	0-100	Porcentaje de emails sometidos a la política

Alineación relaxed vs strict: en modo relaxed (adkim=r), el dominio de la firma DKIM (d=) debe compartir el mismo dominio organizacional que el From. Ejemplo: una firma d=mail.captaindns.com está alineada con un From contact@captaindns.com. En modo strict (adkim=s), los dominios deben corresponder exactamente.

La evaluación DMARC sigue esta lógica:

1. SPF pasa y está alineado con el From: DMARC pasa.
2. DKIM pasa y está alineado con el From: DMARC pasa.
3. Si ninguno de los dos está alineado: DMARC falla, y la política (p=) se aplica.

Un punto que suele malinterpretarse: DMARC pasa si al menos uno de los dos mecanismos (SPF o DKIM) pasa con alineación. No es necesario que ambos tengan éxito.

Etapa 4: controles complementarios (MX, PTR, encabezados, listas negras)

La prueba verifica después elementos técnicos adicionales:

Registros MX: el dominio debe tener registros MX válidos que apunten a servidores de correo activos. Un dominio sin MX señala un dominio que no está configurado para recibir correo, lo cual es sospechoso para un remitente.

dig MX captaindns.com +short
# 10 mx1.captaindns.com.
# 20 mx2.captaindns.com.

Reverse DNS (PTR): la IP del servidor de envío debe tener un registro PTR que resuelva hacia un nombre de host, y ese nombre de host debe resolver de vuelta hacia la misma IP. Es la verificación FCrDNS (Forward-confirmed reverse DNS).

# Verificar el reverse DNS de una IP
dig -x 203.0.113.10 +short
# mail.captaindns.com.

# Verificar que el forward corresponde
dig A mail.captaindns.com +short
# 203.0.113.10

Listas negras: la IP de envío se verifica contra las principales listas negras (Spamhaus ZEN, Barracuda, SORBS, SpamCop). La presencia en una sola lista negra importante puede ser suficiente para que tus emails sean rechazados por la mayoría de los proveedores.

Encabezados de email: la prueba verifica la coherencia de los encabezados From, Reply-To, Message-ID, Date y la presencia de campos obligatorios según la RFC 5322.

Interpretar los resultados sección por sección

Una vez ejecutada la prueba, el informe muestra una puntuación global y un detalle por categoría. Así es como debes leer cada sección e identificar las acciones prioritarias.

Sección SPF (25 puntos)

Resultado	Puntos	Significado	Acción
pass	25/25	La IP de envío está autorizada por tu SPF	Ninguna acción
softfail	10/25	La IP no está explícitamente autorizada (~all)	Pasar a -all tras verificación
fail	0/25	La IP está explícitamente rechazada por tu SPF	Añadir la IP o el include faltante
permerror	0/25	El registro SPF es inválido	Corregir la sintaxis o reducir los lookups
none	0/25	No se encontró ningún registro SPF	Crear un registro SPF

Error frecuente: un resultado softfail da la impresión de que "pasa de todas formas". En realidad, los servidores modernos tratan el softfail casi como un fail, sobre todo en combinación con un DMARC en modo quarantine o reject. El softfail solo debería ser una fase transitoria durante el despliegue inicial del SPF.

Sección DKIM (25 puntos)

Resultado	Puntos	Significado	Acción
pass	25/25	Firma válida y clave pública encontrada	Ninguna acción
fail	0/25	Firma inválida (cuerpo modificado, clave incorrecta)	Diagnosticar la causa exacta
none	0/25	No hay firma DKIM en el email	Configurar DKIM en el servidor de envío
permerror	0/25	Clave pública malformada o inaccesible	Verificar el registro DNS del selector

El resultado dkim=fail es el más complejo de diagnosticar porque las causas son múltiples: hash del body alterado por un relé intermedio, clave pública ausente del DNS, firma expirada (etiqueta x= superada), o algoritmo de canonicalización incorrecto. Consulta la guía de diagnóstico DKIM fail para un árbol de decisión completo.

Sección DMARC (20 puntos)

Resultado	Puntos	Significado	Acción
pass	20/20	SPF o DKIM alineado y válido	Ninguna acción
fail (p=none)	5/20	Fallo pero sin consecuencia (modo vigilancia)	Progresar hacia quarantine y luego reject
fail (p=quarantine)	0/20	Emails enviados a spam	Corregir la alineación SPF/DKIM
fail (p=reject)	0/20	Emails rechazados	Corregir la alineación SPF/DKIM
none	0/20	No hay registro DMARC	Crear un registro DMARC

La trampa de p=none: esta política es indispensable durante la fase de despliegue, ya que permite recopilar informes sin impactar la entrega. Pero quedarse en p=none indefinidamente equivale a no tener DMARC en términos de protección. Los proveedores de correo otorgan un crédito de confianza a los dominios que publican p=quarantine o p=reject.

Sección MX / PTR (15 puntos)

Verificación	Puntos	Criterio
MX válidos	5/15	Al menos un registro MX que resuelva hacia una IP activa
PTR configurado	5/15	Reverse DNS de la IP de envío que resuelva hacia un nombre de host
FCrDNS	3/15	Forward-confirmed reverse DNS (ida y vuelta IP/nombre de host)
Sin lista negra	2/15	IP ausente de las principales listas negras

El reverse DNS (PTR) suele ser descuidado porque depende del propietario del rango de IP, no del propietario del dominio. Si utilizas un VPS o un servidor dedicado, el PTR se configura a través del panel de tu proveedor de hosting. Si utilizas un servicio de envío (SendGrid, Mailgun, Brevo), el PTR normalmente lo gestiona el proveedor en sus IP dedicadas.

Sección encabezados (15 puntos)

Verificación	Puntos	Criterio
From válido	4/15	Dirección email sintácticamente correcta con dominio que resuelve
Message-ID	3/15	Presente y en formato RFC 5322
Date	3/15	Presente y dentro de un intervalo razonable (no en el futuro, no > 7 días)
Reply-To coherente	3/15	Mismo dominio que From o dominio de confianza
Sin X-Mailer sospechoso	2/15	Sin software de spam conocido en los encabezados

Un encabezado Message-ID ausente o malformado es una señal fuerte de spam para los filtros. Cada email debe tener un Message-ID único en formato <identificador@dominio>. Los servidores de correo correctamente configurados lo generan automáticamente, pero ciertos scripts PHP o bibliotecas de envío personalizadas lo omiten.

De 40/100 a 100/100: las correcciones paso a paso

Ejecutaste la prueba y la puntuación no es buena. Este es el orden exacto de las correcciones, clasificadas por impacto en la puntuación.

Prioridad 1: crear o corregir SPF (+25 puntos)

Si tu SPF está ausente o es inválido, esta es la corrección que aporta más puntos de forma inmediata.

Caso 1: Ningún registro SPF

Crea un registro DNS TXT en tu dominio raíz:

captaindns.com.  IN  TXT  "v=spf1 include:_spf.google.com -all"

Adapta los mecanismos a tus servicios de envío:

Servicio	Include a añadir
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com
SendGrid	include:sendgrid.net
Mailgun	include:mailgun.org
Brevo (ex-Sendinblue)	include:sendinblue.com
Amazon SES	include:amazonses.com
OVHcloud	include:mx.ovh.com

Caso 2: SPF PermError (demasiados lookups)

El límite de 10 lookups es la causa más frecuente del PermError. Cada include: cuenta como al menos 1 lookup, y los includes anidados se acumulan. Google Workspace por sí solo consume 4 lookups.

Para diagnosticar el problema:

# Contar los lookups de tu SPF
dig TXT captaindns.com +short | grep "v=spf1"
# Luego seguir cada include recursivamente
dig TXT _spf.google.com +short
# "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
# = 3 lookups adicionales solo para este include

Soluciones de reducción:

• Reemplazar los include: por ip4: e ip6: directos cuando las IP son estables (SPF flattening)
• Utilizar macros SPF (%{i} y exists:) para los casos avanzados
• Eliminar los includes de servicios que ya no utilizas

Para una guía detallada sobre el PermError, consulta la guía SPF PermError.

Caso 3: Dos registros SPF en el mismo dominio

La RFC 7208 prohíbe estrictamente la presencia de varios registros TXT que comiencen por v=spf1 en el mismo dominio. Si tienes dos, el servidor devuelve inmediatamente permerror.

# Verificar si hay duplicados
dig TXT captaindns.com +short | grep "v=spf1"
# Si aparecen dos líneas: fusionar en un solo registro

Fusiona los dos registros en uno solo que contenga todos los mecanismos.

Prioridad 2: configurar DKIM (+25 puntos)

DKIM requiere dos elementos: una clave privada instalada en el servidor de envío (que firma los mensajes) y una clave pública publicada en el DNS (que permite la verificación).

Configuración con Google Workspace:

1. Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email
2. Selecciona tu dominio y haz clic en "Generate new record"
3. Elige una longitud de clave de 2048 bits
4. Copia el registro DNS CNAME o TXT proporcionado
5. Publícalo en tu zona DNS con el formato google._domainkey.captaindns.com
6. Vuelve a la consola y haz clic en "Start authentication"

Configuración con Microsoft 365:

Microsoft 365 utiliza dos registros CNAME por dominio:

selector1._domainkey.captaindns.com  CNAME  selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com
selector2._domainkey.captaindns.com  CNAME  selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com

Verificación post-configuración:

# Verificar que la clave pública es accesible
dig TXT google._domainkey.captaindns.com +short
# Debería devolver un registro que contiene "v=DKIM1; k=rsa; p=MII..."

Si el comando no devuelve nada, el problema es DNS: o bien el registro aún no ha propagado (esperar 24-48h), o hay un error de nombre en el selector.

Longitud de clave: utiliza 2048 bits como mínimo. Las claves de 1024 bits se consideran débiles desde 2020. Algunos proveedores ya rechazan las firmas basadas en claves RSA de menos de 1024 bits.

Prioridad 3: publicar y endurecer DMARC (+20 puntos)

La implementación de DMARC sigue un ciclo en tres fases.

Fase 1: Vigilancia (2 a 4 semanas)

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@captaindns.com; pct=100"

Durante esta fase, ningún email es bloqueado. Los informes agregados (rua=) llegan diariamente en formato XML y contienen las estadísticas de autenticación de todos los servidores que han enviado emails para tu dominio.

Analiza los informes para identificar:

• Las fuentes legítimas que fallan (servidor de facturación, CRM, herramienta de marketing)
• Las fuentes ilegítimas (intentos de suplantación)
• La tasa de alineación SPF y DKIM

Fase 2: Cuarentena (4 a 8 semanas)

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@captaindns.com; pct=25"

El pct=25 aplica la política de cuarentena solo al 25 % de los emails que fallan. Es una red de seguridad: si una fuente legítima aún no ha sido corregida, el 75 % de sus emails todavía pasan. Aumenta progresivamente: 25 %, 50 %, 75 %, 100 %.

Fase 3: Rechazo

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"

En este punto, todo email que falle la alineación DMARC es rechazado por el servidor de recepción. Es la configuración más segura y la que aporta más crédito de confianza ante los proveedores.

Prioridad 4: configurar el reverse DNS (+15 puntos MX/PTR)

Registros MX: si tu dominio no tiene registro MX, añade uno que apunte a tu servidor de recepción:

captaindns.com.  IN  MX  10  mx1.captaindns.com.
captaindns.com.  IN  MX  20  mx2.captaindns.com.

Reverse DNS: conéctate al panel de administración de tu proveedor de hosting y configura el PTR de tu IP de envío para que apunte al FQDN de tu servidor de correo:

# Después de la configuración, verifica:
dig -x 203.0.113.10 +short
# Esperado: mail.captaindns.com.

Listas negras: si tu IP aparece en una lista negra, el procedimiento de retirada depende de la lista:

Lista negra	Procedimiento	Plazo
Spamhaus	Formulario de retirada en spamhaus.org	24-48h tras corrección
Barracuda	Formulario en barracudacentral.org	12-24h
SORBS	Retirada automática tras 48h sin spam	48h
SpamCop	Expiración automática en 24h	24h

Prioridad 5: limpiar los encabezados (+15 puntos)

Los problemas de encabezados suelen estar causados por scripts de envío personalizados o bibliotecas mal configuradas.

Lista de control de encabezados:

• El campo From utiliza una dirección con tu dominio, no un dominio genérico
• El Message-ID está presente y en formato <unique-id@captaindns.com>
• El campo Date está presente y es correcto (zona horaria incluida)
• El Reply-To, si está presente, utiliza un dominio coherente con el From
• Ningún encabezado X-Mailer que referencie una herramienta de spam conocida
• El Content-Type especifica el charset (UTF-8 recomendado)

Si utilizas PHP mail(), pasa a una biblioteca como PHPMailer o SwiftMailer que genera encabezados conformes. Si utilizas un framework (Laravel, Django, Rails), los encabezados suelen ser correctos por defecto.

Los errores más frecuentes

SPF PermError: el límite de 10 lookups

Es el error más extendido. Un dominio que utiliza Google Workspace (4 lookups), SendGrid (2 lookups), Mailchimp (2 lookups) y un servidor interno (1 lookup con un a:) ya alcanza 9 lookups. Añadir un solo servicio más provoca el PermError.

El diagnóstico es sencillo:

dig TXT captaindns.com +short | grep "v=spf1"
# Cuenta cada include, a, mx, redirect, exists
# Sigue los includes anidados recursivamente

La corrección depende de tu situación:

• Elimina los servicios no utilizados: verifica si cada include corresponde a un servicio activo
• Utiliza el SPF flattening: reemplaza los includes por las IP finales (cuidado con el mantenimiento)
• Dedica un subdominio: envía el marketing desde news.captaindns.com con su propio SPF

Si a pesar de estas correcciones tus emails siguen llegando a spam, el problema va más allá del SPF. Consulta la guía de diagnóstico completo del spam para analizar las otras causas (reputación, contenido, engagement).

DKIM fail: body hash did not verify

Este error significa que el contenido del email fue modificado después de la firma. Las causas más comunes:

1. Relé intermedio: un servidor entre el envío y la recepción añadió un pie de página, reescribió URLs o inyectó un píxel de seguimiento
2. Antivirus o DLP: un software de seguridad modificó el cuerpo del mensaje
3. Lista de distribución: los servidores de listas (Listserv, Sympa) suelen añadir un pie de página de desuscripción que rompe la firma

La corrección consiste en identificar qué componente de tu cadena de envío modifica el mensaje después de la firma DKIM, y luego reconfigurar el orden de las operaciones para que la modificación se haga antes de la firma.

Para las listas de distribución, el protocolo ARC (Authenticated Received Chain) permite preservar los resultados de autenticación a través de los relés. Gmail y Microsoft soportan ARC desde 2019.

DMARC fail: defecto de alineación

El error más sutil. SPF pasa, DKIM pasa, pero DMARC falla de todas formas. La causa: ninguno de los dos está alineado con el dominio del campo From.

Escenario típico: envías desde contact@captaindns.com, pero tu proveedor de envío firma con d=sendgrid.net (DKIM no alineado) y el sobre SMTP utiliza bounces@sendgrid.net (SPF no alineado). Resultado: las dos autenticaciones pasan técnicamente, pero ninguna está alineada con captaindns.com.

Corrección:

• Configura tu proveedor para firmar con d=captaindns.com (DKIM alineado)
• Configura el return-path (sobre SMTP) para utilizar un subdominio de tu dominio (SPF alineado)

La mayoría de los proveedores de envío (SendGrid, Mailgun, Brevo, Postmark) ofrecen una opción "Domain Authentication" o "Sender Authentication" que configura automáticamente la alineación DKIM y SPF.

IP en una lista negra

Tu puntuación MX/PTR cae por una IP en lista negra. Las causas principales:

• IP compartida: si estás en una IP compartida con otros clientes de tu proveedor de hosting, el spam de otro cliente puede afectarte
• Compromiso: un script en tu servidor envía spam sin que lo sepas (formulario de contacto explotado, cuenta de email comprometida)
• Historial de la IP: la IP que acabas de recibir era utilizada anteriormente por un spammer

La verificación es inmediata:

# Verificar Spamhaus
dig +short 10.113.0.203.zen.spamhaus.org
# Si aparece una respuesta 127.0.0.x, la IP está listada

Nota que la IP está invertida en la consulta DNS (203.0.113.10 se convierte en 10.113.0.203).

Cuándo probar: las 5 situaciones críticas

Una prueba de entregabilidad no es un control puntual. Estas son las cinco situaciones en las que una prueba es indispensable.

1. Antes del lanzamiento de una campaña de email

Cada campaña de marketing debería estar precedida por una prueba. Un problema de autenticación en un envío de 50 000 emails significa 50 000 emails potencialmente perdidos. La prueba tarda 30 segundos y puede salvar una campaña entera.

Envía un email de prueba a la dirección proporcionada por el mail tester, consulta el informe y corrige los problemas antes del envío masivo.

2. Después de un cambio de proveedor de envío

La migración de un servicio de envío a otro es el momento más arriesgado para la entregabilidad. Hay que actualizar el SPF (reemplazar el antiguo include por el nuevo), reconfigurar DKIM (nuevo selector, nueva clave), y verificar la alineación DMARC.

Lista de control para la migración:

• Actualizar el SPF: eliminar el antiguo include, añadir el nuevo
• Configurar DKIM en el nuevo proveedor y publicar la clave en el DNS
• Verificar la alineación DMARC con el nuevo proveedor
• Probar la entregabilidad antes de cambiar el tráfico
• Conservar el antiguo SPF include durante 48h (emails en tránsito)

3. Después de una modificación DNS

Cualquier modificación de tu zona DNS puede impactar la entregabilidad: cambio de TTL, actualización de un registro TXT, migración de registrador, activación de DNSSEC. Los errores de copiar y pegar en los registros DNS son frecuentes y el resultado es un SPF o DKIM roto sin ningún mensaje de error visible.

4. Cuando las tasas de apertura caen

Una caída repentina de las tasas de apertura (más del 10 % de variación en una semana) puede indicar un problema de entregabilidad. Antes de buscar la causa en el contenido o el asunto de los emails, prueba tu autenticación. Un SPF que supera repentinamente los 10 lookups (porque un proveedor añadió un include anidado) puede provocar una caída brusca.

5. Con un ritmo mensual, en prevención

Las configuraciones DNS cambian, los proveedores actualizan sus registros, las claves DKIM deben renovarse. Una prueba mensual detecta las regresiones antes de que impacten tus envíos. Programa un recordatorio mensual y verifica que tu puntuación se mantiene en 100/100.

Plan de acción recomendado

1. Ejecuta una prueba de entregabilidad en el mail tester de CaptainDNS. Envía un email de prueba y recupera tu puntuación detallada sección por sección.

2. Corrige los problemas por orden de impacto: SPF primero (25 puntos), luego DKIM (25 puntos), luego DMARC (20 puntos). Cada corrección aumenta inmediatamente tu puntuación y tu tasa de entregabilidad.

3. Verifica tus correcciones relanzando la prueba después de cada modificación DNS. Espera la propagación DNS (5 a 60 minutos según el TTL) antes de volver a probar.

4. Implementa el monitoreo DMARC: los informes agregados (rua=) te alertan automáticamente cuando aparece un problema de autenticación. Analízalos al menos una vez por semana durante la fase de escalada, luego mensualmente.

5. Planifica una prueba mensual para detectar regresiones. Las configuraciones DNS evolucionan silenciosamente (proveedor que modifica sus includes, clave DKIM que expira, IP que cambia de lista negra). Una prueba mensual cuesta 30 segundos y puede evitar semanas de entregabilidad degradada.

FAQ

¿Qué es un mail tester y cómo funciona?

Un mail tester es una herramienta que analiza la entregabilidad de tus emails verificando tu configuración DNS (SPF, DKIM, DMARC), la reputación de tu IP de envío, tus encabezados de email y la presencia eventual de tu IP en listas negras. Envías un email de prueba a una dirección proporcionada por la herramienta, y esta produce un informe detallado con una puntuación sobre 100 y las correcciones a aplicar.

¿Qué puntuación de entregabilidad hay que alcanzar?

Apunta a una puntuación de 100/100. Una puntuación superior a 80/100 es aceptable para la mayoría de los envíos transaccionales. Por debajo de 70/100, tus emails tienen una probabilidad significativa de ser clasificados como spam. Por debajo de 50/100, la mayoría de los proveedores (Gmail, Outlook, Yahoo) rechazará o filtrará tus mensajes.

¿SPF, DKIM y DMARC son todos obligatorios?

Desde febrero de 2024, Gmail y Yahoo exigen al menos SPF o DKIM para todos los remitentes. Para los remitentes masivos (más de 5 000 emails por día hacia Gmail), los tres son obligatorios: SPF y DKIM válidos, más un registro DMARC publicado. En la práctica, configurar los tres es recomendable para todos los dominios, sea cual sea el volumen.

¿Qué es el límite de 10 DNS lookups de SPF?

La RFC 7208 limita a 10 el número de consultas DNS recursivas durante la evaluación de un registro SPF. Los mecanismos include, a, mx, redirect y exists cuentan cada uno como un lookup. Los includes anidados se acumulan: un include que contiene a su vez 3 includes consume 4 lookups en total. Más allá de 10, el servidor devuelve un PermError y tu SPF se considera inválido.

¿Por qué mi DMARC falla si SPF y DKIM pasan?

DMARC verifica no solo que SPF y DKIM pasen, sino también que estén alineados con el dominio del campo From del email. Si tu proveedor de envío firma con su propio dominio DKIM y utiliza su propia dirección en el sobre SMTP, ni SPF ni DKIM están alineados con tu dominio From. Configura tu proveedor para utilizar tu dominio (Domain Authentication) para resolver este problema.

¿Cuánto tiempo tardan las correcciones DNS en hacer efecto?

El plazo depende del TTL (Time To Live) de tus registros DNS. Un TTL de 300 segundos (5 minutos) significa que los servidores de recepción verán tu modificación en menos de 5 minutos. Un TTL de 86400 (24 horas) puede requerir hasta 24 horas. Antes de modificar un registro crítico, reduce primero el TTL a 300, espera la propagación de ese nuevo TTL, y luego realiza la modificación.

¿Cómo saber si mi IP está en una lista negra?

Consulta las principales listas negras mediante una consulta DNS inversa. Por ejemplo, para verificar la IP 203.0.113.10 en Spamhaus: dig +short 10.113.0.203.zen.spamhaus.org. Si se devuelve una respuesta de tipo 127.0.0.x, la IP está listada. Una herramienta de verificación de listas negras automatiza esta verificación en varias decenas de listas simultáneamente.

¿Hay que probar antes de cada envío de campaña?

Sí, para las campañas de marketing masivas. Una prueba tarda menos de un minuto y puede evitar desperdiciar un envío entero. Para los emails transaccionales (confirmaciones, facturas), una prueba mensual es suficiente, salvo tras un cambio de configuración DNS o de proveedor de envío. El objetivo es detectar las regresiones antes de que impacten la entregabilidad.

¿Cuál es la diferencia entre alineación relaxed y strict en DMARC?

En modo relaxed (adkim=r, aspf=r), el dominio de la firma DKIM o del sobre SPF debe compartir el mismo dominio organizacional que el From. Ejemplo: una firma d=mail.captaindns.com está alineada con un From @captaindns.com. En modo strict (adkim=s, aspf=s), los dominios deben corresponder exactamente. El modo relaxed es recomendable para la mayoría de los despliegues porque tolera el uso de subdominios.

¿Qué hacer si mi puntuación no sube a pesar de las correcciones?

Verifica que la propagación DNS haya terminado (espera al menos el TTL de tus registros). Prueba cada componente individualmente: SPF solo (dig TXT captaindns.com), DKIM solo (dig TXT selector._domainkey.captaindns.com), DMARC solo (dig TXT _dmarc.captaindns.com). Si los registros DNS son correctos pero la puntuación no cambia, el problema puede venir de la reputación de la IP (lista negra) o del contenido del email de prueba.

Glosario

• SPF (Sender Policy Framework): protocolo de autenticación de email definido por la RFC 7208 que lista los servidores autorizados para enviar emails por un dominio mediante un registro DNS TXT que comienza por v=spf1.
• DKIM (DomainKeys Identified Mail): protocolo de autenticación de email definido por la RFC 6376 que añade una firma criptográfica a cada email, verificable mediante una clave pública publicada en el DNS.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): protocolo definido por la RFC 7489 que verifica la alineación SPF y DKIM con el dominio From y define la política de tratamiento de los fallos (none, quarantine, reject).
• Alineación: en contexto DMARC, correspondencia entre el dominio utilizado por SPF o DKIM y el dominio visible en el campo From del email. Puede ser relaxed (mismo dominio organizacional) o strict (correspondencia exacta).
• PermError: error permanente devuelto cuando un registro SPF es estructuralmente inválido (demasiados lookups, sintaxis incorrecta, duplicados). El registro no puede ser evaluado.
• PTR (Pointer Record): registro DNS que asocia una dirección IP a un nombre de host (reverse DNS). Utilizado por los servidores de recepción para verificar la identidad del servidor de envío.
• FCrDNS (Forward-confirmed reverse DNS): verificación en dos pasos. El reverse DNS de la IP devuelve un nombre de host, y la resolución de ese nombre de host debe devolver la IP de origen.
• Lista negra (DNSBL): lista de bloqueo basada en DNS que registra las direcciones IP conocidas por enviar spam. Las principales son Spamhaus, Barracuda, SORBS y SpamCop.
• Selector DKIM: identificador (cadena de caracteres) que permite localizar la clave pública DKIM en el DNS. El registro se publica en selector._domainkey.captaindns.com.
• RFC 7208: especificación oficial del protocolo SPF que define la sintaxis de los registros, el límite de 10 lookups, los void lookups y los resultados posibles.
• ARC (Authenticated Received Chain): protocolo que preserva los resultados de autenticación de email a través de los relés intermedios (listas de distribución, reenvíos). Soportado por Gmail y Microsoft.
• RFC 8058: especificación del mecanismo de desuscripción en un clic (One-Click Unsubscribe) vía el encabezado List-Unsubscribe-Post, requerido por Gmail para los remitentes masivos desde 2024.

---

Prueba tu entregabilidad ahora: utiliza el mail tester de CaptainDNS para obtener tu puntuación sobre 100 y la lista exacta de correcciones a aplicar. Una prueba tarda 30 segundos y puede transformar tus tasas de entrega.

---

Fuentes

• RFC 7208 - Sender Policy Framework (SPF)
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Google - Email sender guidelines (2024)
• Yahoo - Sender best practices and requirements
• Validity - 2025 Email Deliverability Benchmark Report