Autenticación de email en 2026: SPF, DKIM, DMARC, MTA-STS y BIMI, bien configurados

El panorama de autenticación en 2026 está lo bastante estable como para que no sea controversial: necesitas SPF, DKIM y DMARC alineados, deberías tener MTA-STS y TLS-RPT publicados y, si a tu marca le importa cómo se ve el correo en Gmail, probablemente quieras BIMI. La enforcement Microsoft del 5 de mayo 2025 (550 5.7.515 Access denied para senders no compliant a 5.000+/día) y el endurecimiento Gmail post-noviembre 2025 elevaron sustancialmente las consecuencias operacionales de un baseline mal configurado — lo que en 2022 causaba degradación de placement gradual ahora produce hard rejection inmediato a escala. Cómo configurar cada capa bien, errores comunes y cómo saber que tu configuración funciona de verdad.

La pila de autenticación visualizada — capas, dependencias y decisiones

Antes del detalle por capa, el diagrama muestra la pila completa de autenticación moderna desde lo más bajo (transporte) hasta lo más alto (marca visual), con las dependencias entre capas y las decisiones operacionales en cada nivel.

El diagrama hace explícito el aspecto más malinterpretado de la autenticación moderna: las capas son dependientes, no opcionales. BIMI sin DMARC en p=quarantine o p=reject no funciona; ARC sin SPF/DKIM/DMARC funciona técnicamente pero no aporta valor. La construcción de abajo hacia arriba — transporte, identidad, alineación, preservación, marca, control de emisión — es la única progresión que no produce regresiones.

SPF: la primera milla

SPF le dice al servidor receptor qué IPs pueden enviar en nombre de tu dominio. Conceptualmente simple y la gente lo sigue arruinando mayormente de dos formas: demasiados includes (SPF tiene límite de 10 DNS-lookups, excederlo hace fallar SPF) y terminación equivocada (quedarse en ~all por siempre en vez de pasar a -all).

Nuestro patrón recomendado:

v=spf1 include:_spf.bluespirithosting.com ~all

Donde _spf.bluespirithosting.com es un único TXT que agrega tus hosts de envío. Mantén todo en un include para esquivar el límite de 10 lookups.

Arranca con ~all durante el warmup, que indica al receptor “soft fail” — probablemente spam, pero entrega. Pasa a -all (hard fail) cuando confíes en que el SPF está completo y estable. Hard fail es contra lo que DMARC va a enforzar; soft fail es red de seguridad operativa.

Error común: listar IPs individuales directamente. Cuando añades más servidores, tienes que actualizar SPF en cada dominio en lugar de en un include central. Usa include y TXT macro.

DKIM: la capa de firma

DKIM firma cada mensaje saliente con una clave privada. El receptor verifica la firma contra una clave pública publicada en DNS en selector._domainkey.tudominio.com. La firma prueba que el mensaje no fue modificado en tránsito y que fue firmado por alguien con acceso a la clave.

Configuración moderna: RSA 2048 bits, un selector por sistema de envío, rotar el selector cada 6-12 meses. Los dos fallos comunes son claves débiles (512 o 1024 bits, que algunos sistemas legacy aún emiten) y olvidar publicar la pública del selector que tu MTA usa.

Prueba con dig TXT selector._domainkey.tudominio.com apenas publiques. Si no obtienes respuesta que coincida con el selector de tu MTA, arregla la propagación DNS antes de enviar nada.

DMARC: la capa de política

DMARC liga SPF y DKIM y le dice al receptor qué hacer con mail que falla alineamiento. “Alineamiento” es el concepto que muchos pierden: SPF y DKIM pueden pasar técnicamente pero fallar alineamiento si el dominio del MAIL FROM o la firma DKIM no coincide con el dominio visible del From.

Progresión recomendada:

1. Semana 1-4: publica v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]. Esto pide reportes agregados pero no enforza. Monitorea. Vas a encontrar fuentes de mail que no sabías (CRMs olvidados, facturación de terceros, alguien con un relay aún usando tu dominio).
2. Semana 5-8: alineadas las legítimas, pasa a p=quarantine. El no alineado va a spam. Sigue monitoreando.
3. Mes 3+: pasa a p=reject. El no alineado rebota. Estás enforzado.

Los reportes rua son XML no amigable al humano. Usa un parser (Postmark DMARC Digests, Valimail, dmarcian, OnDMARC) para convertirlos en dashboard.

Error común: ir directo a p=reject sin observar los reportes primero. Vas a rebotar correo legítimo (el mailer del contador, notificaciones automáticas del CRM) sin entender por qué.

MTA-STS: seguridad de transporte

MTA-STS dice a servidores emisores que deben usar TLS para entregar a tu dominio. Sin MTA-STS un atacante man-in-the-middle puede degradar la conexión a no cifrada y leer. Los grandes receptores chequean MTA-STS; publícalo.

El setup implica publicar un documento de política por HTTPS en https://mta-sts.tudominio.com/.well-known/mta-sts.txt con los MX permitidos y el modo (enforce tras testing). En DNS un TXT en _mta-sts.tudominio.com con el ID de política.

Usa modo testing 30 días primero, mira los reportes TLS-RPT (similares a DMARC pero para fallos TLS), luego pasa a enforce. TLS-RPT va en _smtp._tls.tudominio.com.

BIMI: la capa visual

BIMI hace que un logo de marca validado aparezca al lado de tu correo en la bandeja (actualmente Gmail, Yahoo y Apple Mail). Requiere DMARC p=quarantine o p=reject, un SVG compatible con BIMI y, para el tier más visible, un Verified Mark Certificate (VMC) de una CA aprobada. Los VMC cuestan alrededor de € 1.500/año.

Para la mayoría de remitentes BIMI no es donde debe ir el primer esfuerzo — arregla SPF/DKIM/DMARC primero, luego MTA-STS, luego considera BIMI. Para marcas cuya identidad importa en reconocimiento de inbox (ecommerce, financieras, consumer conocido), BIMI merece la inversión.

Configuración mínima vs recomendada — la matriz comparativa

La tabla resume las tres opciones de configuración con sus disparadores y costo operacional. Úsala para mapear tu situación actual al tier apropiado antes de invertir esfuerzo de ingeniería.

Componente	Tier 1 — Mínimo viable	Tier 2 — Recomendado producción	Tier 3 — Defensivo enterprise
SPF	~all, 1 include	-all, ≤10 lookups	-all con flattening si necesario
DKIM	2048-bit, 1 selector	2048-bit, rotación 6-12 mo	2048-bit, rotación documentada y testeada
DMARC	p=none con rua	p=quarantine con rampa pct staged	p=reject pct=100 en padre + subdominios
MTA-STS	Diferir	Modo enforce con TLS-RPT	Modo enforce con monitoreo activo
ARC	No requerido	Si mix europeo dominante	Sealing en cada forwarder propio
BIMI	Diferir	SVG self-signed o CMC €600/año	VMC €1.500/año para consumer-facing
CAA	Diferir	Diferir	Restricción CA explícita
Disparador	sub-5K/día, B2B nicho	5K-500K/día, mainstream B2C/B2B	500K+/día o PCI DSS v4.0 / DORA / NIS2
Costo operacional	4-8 horas setup inicial	16-40 horas + €0-€50/mes reporting	80-160 horas + €100-€500/mes

Herramientas que sí funcionan

Verificación de setup: mxtoolbox.com, mail-tester.com, dmarcian.com/dmarc-inspector. Procesamiento DMARC: Postmark DMARC Digests (gratis para hobbyistas), Valimail Monitor (pago), dmarcian (pago).

Monitoreo día a día: Google Postmaster Tools, Microsoft SNDS. Alertas cuando la autenticación se rompe: un parser DMARC con digests por email.

Errores comunes que vemos

Publicar SPF que excede 10 lookups. Diagnóstico: mxtoolbox.com/spf.aspx. Arreglo: aplanar includes o consolidar a un solo include.

Usar el mismo selector DKIM en todos los sistemas. Si uno se compromete, pierdes DKIM en todo. Separa selectores por fuente.

Publicar DMARC sin dirección de reporting. Tienes enforcement pero no ves qué se rechaza ni por qué. Siempre publica rua.

Olvidar actualizar DMARC al añadir un nuevo remitente. Esa cuenta nueva de Mailchimp fallará DMARC hasta que la añadas a SPF o autorices el DKIM. Inventaría tus remitentes periódicamente.

Ir a p=reject sin pasar por p=none de monitoreo. Vas a rebotar correo legítimo sin saber por qué. Siempre escala vía quarantine primero.

Adopción de DMARC enforcement por región — el paisaje 2024-2026

El gráfico abajo muestra adopción de DMARC p=reject (enforcement estricto) por región a través de 2024-2026, con datos derivados de scans públicos de los 100K dominios principales por región. La progresión muestra que UE/UK lideran adopción, US/Canadá siguen de cerca, LATAM va materialmente atrás, y el gap regional crea ventaja competitiva en placement para operadores que adoptan enforcement temprano en regiones de baja adopción.

Adopción DMARC p=reject por región a través de 2024-2026, top 100K dominios

Categoría	UE	Reino Unido	Estados Unidos	Canadá	Asia-Pacífico	LATAM
Q1 2024	38	35	32	28	18	12
Q3 2024	44	41	38	34	22	15
Q1 2025	50	47	44	39	26	19
Q3 2025	54	52	49	44	29	22
Q1 2026	58	56	52	48	32	25

Datos derivados de scans públicos DMARC adoption tracking en 2024-2026 (DMARC.org adoption reports, EasyDMARC industry trends, Valimail State of Email Trust). UE va a la cabeza por presión regulatoria post-NIS2 (octubre 2024) que clasifica enforcement DMARC como control técnico apropiado bajo Artículo 21. Estados Unidos sigue impulsado por mandato federal CISA Binding Operational Directive 18-01 que obliga DMARC reject para dominios .gov y crea presión competitiva en .com. LATAM va detrás por adopción más lenta de frameworks compliance regional con triggers DMARC explícitos — LFPDPPP México, LGPD Brasil, ley 25.326 Argentina mencionan autenticación pero no enforcement explícito. Implicación operacional: operadores LATAM publicando DMARC en p=reject están materialmente adelantados a la curva regional, lo cual provee ventaja competitiva en entregabilidad con receptores que ponderan enforcement DMARC. El gap regional es upgrade gratuito de posicionamiento para senders LATAM que invierten en autenticación al nivel de mercados maduros.

Alineación frente a paso técnico — la distinción que rompe DMARC para operadores nuevos

El concepto que con más frecuencia se les escapa a los recién llegados a DMARC es la diferencia entre “SPF/DKIM pasa técnicamente” y “SPF/DKIM se alinea para fines de DMARC”. El paso técnico significa que la comprobación criptográfica tiene éxito. La alineación significa que el dominio que pasó debe coincidir con el dominio del header From visible (o ser un subdominio suyo, dependiendo del modo de alineación).

Considera el modo de fallo canónico: configuras SPF para tudominio.com y tu proveedor de mailing list envía desde bounces.maillistprovider.com. SPF pasa porque bounces.maillistprovider.com está correctamente autorizado. Pero el header From dice [email protected] y el return-path de SPF es bounces.maillistprovider.com — esos dominios no se alinean. DMARC ve esto como “SPF pasó pero no alinea con el dominio From” y lo trata como fallo de autenticación.

La solución tiene tres opciones según lo que controles. Opción 1: configurar tu proveedor de mailing list para usar un return-path propio que alinee con tu dominio (por ejemplo, [email protected]). Opción 2: depender enteramente de la alineación DKIM — firma con una firma DKIM d=tudominio.com, y la alineación SPF se vuelve irrelevante a efectos de DMARC (DMARC requiere alineación de SPF O DKIM, no de ambos). Opción 3: configurar el modo de alineación relaxed (aspf=r; adkim=r; en tu registro DMARC) que permite alineación a nivel de dominio organizacional en lugar de coincidencia exacta — sigue requiriendo el mismo dominio raíz pero acepta variaciones de subdominio.

Por nuestra experiencia, la alineación DKIM es el camino de menor resistencia para la mayoría de operadores. Configura tus sistemas de envío para firmar con una clave DKIM cuyo parámetro d= coincida con tu dominio From visible, y la alineación DMARC vía DKIM funciona sin importar qué return-path use tu infraestructura de envío. La alineación SPF es más difícil de manejar entre varias fuentes de envío porque cada una debe usar un return-path correctamente alineado.

Los operadores que se saltan entender esta distinción publican DMARC en p=reject basándose en reportes de prueba que muestran “SPF: pass” y “DKIM: pass”, entran en producción y descubren que el 30-50% de su correo está siendo rechazado porque las comprobaciones de alineación fallan a pesar de que la autenticación técnica pasa. Los reportes agregados DMARC distinguen claramente los dos estados; si los lees, evitas la sorpresa.

Leyendo reportes agregados DMARC — qué significa el XML en la práctica

Los reportes DMARC rua llegan como ficheros XML (con gzip, enviados a diario desde cada receptor que procesó tu correo). La estructura es simple pero el volumen es abrumador para cualquier operación de envío relevante — un remitente típico de 100K al mes recibe 30-60 reportes rua distintos al día desde varios ISPs. Leerlos manualmente es impracticable; las herramientas se encargan de la agregación, pero entender qué te muestra la herramienta importa.

El cluster de campos más útil: <row>, <auth_results>, <policy_evaluated>. La fila te dice la IP fuente y el conteo de mensajes desde esa IP procesados durante el periodo de reporte. Auth results te dice si SPF y DKIM pasaron o fallaron técnicamente. Policy evaluated te dice si la alineación DMARC tuvo éxito o falló y qué disposición aplicó el receptor (none, quarantine, reject).

El patrón a observar: alto volumen de mensajes desde una IP fuente mostrando auth_results: spf=pass, dkim=pass pero policy_evaluated: disposition=quarantine, dkim=fail, spf=fail. Esta es la firma del fallo de alineación. Las comprobaciones técnicas pasaron; las de alineación fallaron; el receptor está tratando el correo como no autenticado a pesar de pasar ambos métodos de autenticación. Tu herramienta debería marcar este patrón con prominencia; si no lo hace, puede que necesites un mejor procesador DMARC.

El segundo patrón a observar: volumen pequeño pero persistente desde IPs fuente que no reconoces, mostrando auth_results: spf=fail, dkim=fail. Esto es o bien correo spoofeado (alguien suplantando tu dominio) o correo legítimo desde un remitente olvidado. Los reportes agregados no te dicen cuál; tienes que investigar las IPs fuente. La mayoría de procesadores DMARC ofrecen reverse DNS lookup e información RIR (Regional Internet Registry) para ayudarte a identificar si la IP pertenece a un proveedor de correo conocido que olvidaste (común — tu software contable, una cuenta antigua de MailChimp, ese único sistema CI/CD que envía correos de notificación) o si son intentos genuinos de spoofing.

El tercer patrón: drift gradual en la tasa de éxito de alineación a lo largo del tiempo. Publicas DMARC en p=quarantine, la tasa de éxito de alineación arranca en el 95% y luego, durante seis meses, deriva al 88% conforme se añaden nuevos remitentes sin autorización DKIM. Es la decadencia operacional habitual que se cuela a los remitentes. Configura alertas sobre la tasa agregada de éxito de alineación; recomendamos alertar si baja más de un 2% semana sobre semana.

ARC y el problema del forwarding

El forwarding de correo rompe DMARC, de forma predecible y estructural. Cuando el usuario A se suscribe a tu newsletter y la reenvía a la dirección del usuario B, el servidor de forwarding entrega tu correo con la firma DKIM original intacta (bueno) pero con SPF devolviendo la IP del servidor de forwarding (malo — no alinea). Dependiendo de tu política DMARC, el mensaje reenviado puede acabar en cuarentena o rechazado en el buzón del usuario B.

ARC (Authenticated Received Chain), especificado en el RFC 8617, aborda esto. Cuando un correo se reenvía, el servidor de forwarding publica cabeceras ARC que registran “recibí este correo con autenticación válida y atestiguo que debería seguir considerándose autenticado cuando llegue al siguiente salto”. Los receptores modernos (Gmail, Microsoft, Yahoo) entienden ARC y pueden preservar la confianza de autenticación a través de uno o dos saltos de forwarding.

La implicación para los remitentes: si tu correo fluye a través de servicios de forwarding conocidos como buenos (servidores de mailing list, forwarding corporativo, forwarding de direcciones de antiguos alumnos), asegúrate de que esos servicios publican ARC. No puedes obligarlos a hacerlo, pero puedes preferir servicios que sí lo hacen. Para tu propia infraestructura, si operas un sistema de mailing list que reenvía correo (Mailman, Listserv, equivalentes modernos), publica cabeceras ARC desde tus nodos de forwarding. La configuración no es trivial pero está bien documentada; lo cubrimos en nuestra guía de implementación de ARC.

La interacción entre forwarding y DMARC es la razón individual más común por la que los remitentes reciben quejas inesperadas del tipo “DMARC está rechazando mi correo legítimo” — miran el correo rechazado y descubren que se reenvió a través de un servicio que no publicó ARC, el DMARC original quedó estricto en el extremo receptor y el correo rebotó sin culpa del remitente original. La solución rara vez está en la configuración de autenticación del remitente original; está en la publicación ARC del servicio de forwarding o en la postura de confianza ARC del receptor.

Precios de BIMI y VMC/CMC en 2026 — el desglose real de costes

A BIMI se le suele citar como “publica un logo por €1.500 al año”, pero la estructura de coste real se ha vuelto más matizada conforme el ecosistema BIMI maduró entre 2024 y 2026. Existen ahora tres caminos de certificado con precios distintos y tiers de visualización distintos.

Verified Mark Certificate (VMC) es el camino de certificado original de BIMI. Lo emiten CAs aprobadas (Entrust, DigiCert, ZeroSSL, GlobalSign) tras una verificación legal de la propiedad del marcaje del logo. El precio en 2026 va de €900 a €1.800 al año según el CA y el bundle. Tier de visualización: el más alto — el logo aparece en Gmail, Yahoo, Apple Mail y Microsoft Outlook (en despliegue) con prominencia completa. Necesario para grandes marcas donde el reconocimiento del logo importa.

Common Mark Certificate (CMC), introducido en 2024, es el nuevo camino alternativo para organizaciones cuyo logo no es una marca registrada. Lo emiten las mismas CAs tras verificar que el logo representa a la organización aunque no sea necesariamente una marca registrada. Precio 2026: €450-€800 al año. Tier de visualización: igual que VMC en Gmail y la mayoría de los demás receptores — los receptores no distinguen visiblemente VMC de CMC al mostrar el inbox. CMC es la respuesta práctica para startups SaaS, negocios regionales y organizaciones cuyo logo es anterior al registro de marca o cuyos mercados no requieren registro.

BIMI auto-aseverado (sin certificado) es el camino de menor esfuerzo. Publica un SVG conforme a BIMI en la URL publicada, sin certificado. Tier de visualización: el más bajo — Yahoo mostrará el logo, Apple Mail mostrará el logo, Gmail no mostrará el logo (Gmail exige explícitamente VMC o CMC). Sin coste de certificado. Útil para organizaciones que quieren presencia parcial de BIMI sin la inversión en certificado, particularmente si su audiencia se inclina hacia Yahoo o Apple Mail más que hacia Gmail.

La economía honesta: para un remitente mid-market típico (100K-1M correos al mes, audiencia B2C con presencia significativa en Gmail), CMC a €600 al año es la respuesta correcta. El VMC a €1.500 al año no entrega presencia adicional en el inbox frente a CMC para la mayoría de remitentes; la verificación legal de marca solo compensa si tienes una marca registrada que quieras validar. Para marcas muy grandes (Fortune 500, principales marcas B2C de consumo), VMC sigue valiendo el precio porque la verificación de marca refuerza la protección de marca más allá de la mera visualización en inbox. Para remitentes pequeños o aún validando el valor de BIMI, BIMI auto-aseverado es un punto de partida razonable.

El otro driver de coste en 2026: preparación del SVG del logo. BIMI requiere SVG Tiny 1.2 PS profile, ratio de aspecto cuadrado, con restricciones muy específicas de tamaño y complejidad. La mayoría de SVGs de marca existentes necesitan refactoring profesional para cumplir. Presupuesta €200-€500 para preparación del SVG si tu logo es complejo; los logos simples basados en texto suelen funcionar sin modificación.

Particularidades europeas — autenticación de email para operadores en jurisdicción UE

Tres factores específicos UE que afectan materialmente las decisiones de autenticación de email para operadores en jurisdicción europea en 2026, donde los frameworks regulatorios cruzan con las decisiones técnicas:

NIS2 efectivo octubre 2024 — implicaciones para autenticación email. La directiva NIS2 expandió la definición de “entidades esenciales” e “importantes” para incluir provider de servicios DNS, registries TLD, providers de servicios de cloud computing, y providers de servicios gestionados ICT — categoría que incluye providers de email infrastructure. Para entidades en alcance NIS2, el Artículo 21 requiere “medidas técnicas, operacionales y organizacionales apropiadas” — DMARC enforcement (p=quarantine o p=reject) cualifica como control técnico apropiado bajo Article 21, y los enforcement supervisors regionales (BSI Alemania, ANSSI Francia, NCSC Reino Unido) están explícitamente recomendando enforcement DMARC como baseline para entidades en alcance.

DORA efectivo enero 2025 — registro de terceros ICT incluye stack de autenticación. Para entidades financieras UE, el stack de autenticación email es parte del registro de terceros ICT requerido por DORA Artículo 28. Esto significa documentación explícita del provider de DMARC reporting (Postmark Digest, EasyDMARC, dmarcian, parsedmarc autohospedado), del periodo de retención de reportes, de los controles de acceso a la información de autenticación. Parsedmarc autohospedado en Hetzner Falkenstein o Helsinki simplifica la pregunta de riesgo de tercero vs reporting SaaS US-based — la decisión de jurisdicción del provider de reporting tiene implicaciones DORA.

Schrems II y residencia de datos UE — implicaciones para reporting DMARC. Los reportes DMARC contienen IP addresses, dominios de envío, y volúmenes de mensajes — datos potencialmente clasificables como personal data bajo GDPR (las IPs son explícitamente personal data según jurisprudencia CJEU). Para operadores con scope GDPR strict, el reporting DMARC SaaS US-based (Postmark, EasyDMARC con processing US) requiere análisis Schrems II — Standard Contractual Clauses no son suficientes per se, requieren Transfer Impact Assessment documentado. Parsedmarc autohospedado en infraestructura UE elimina la pregunta Schrems II completamente; la SaaS reporting con processing UE-only (algunas tiers de Valimail, dmarcian EU) la simplifica significativamente.

Madurez de adopción regional: Alemania (impulsado por BSI Grundschutz), Francia (CNIL guidance 2024), Países Bajos (BIO baseline) lideran adopción de enforcement DMARC en mercados europeos; España (post-AEPD guidance 2024), Italia (post-Garante enforcement), Portugal van detrás pero acelerando. Para operadores B2B sirviendo clientes en mercados líderes (DE, FR, NL), publicar DMARC en p=reject es crecientemente expectativa de auditoria de seguridad de cliente, no opcional.

Configurador de baseline de autenticación — la herramienta de decisión

La decisión de baseline de autenticación involucra cinco factores interactuando: volumen diario, mix de proveedores destinatarios, alcance compliance, madurez operacional, prioridad de marca. Usa la herramienta abajo para obtener una recomendación calibrada de tier; la lógica refleja 200+ engagements de auditoría de autenticación a través de 2024-2026 y considera el environment de enforcement post-2025.

La lógica de la herramienta, en resumen:

• Tier 1 — Mínimo viable — sub-5K/día, B2B nicho, sin compliance específico. SPF + DKIM + DMARC p=none con reporting parseado.
• Tier 2 — Producción recomendada — 5K-500K/día o GDPR scope o mix europeo o Apple-heavy. Stack moderno completo con MTA-STS enforce, ARC sealing condicional, BIMI con CMC para consumer-facing.
• Tier 3 — Defensivo enterprise — 500K+/día o PCI DSS v4.0 / DORA / NIS2 / multi-framework. Stack completo con p=reject pct=100, ARC sealing universal, BIMI con VMC, registros CAA.

Troubleshooting de autenticación — los cuatro escenarios que más diagnosticamos

Tras correr auditorías de entregabilidad para varios cientos de operadores, cuatro escenarios de fallo de autenticación se repiten con frecuencia suficiente para sistematizarlos.

Escenario 1 — “Los reportes DMARC muestran fallo de alineación pero todo se ve correctamente configurado”. Casi siempre la causa son remitentes terceros que el operador olvidó. La lista que vemos más a menudo: cuentas legacy de MailChimp sin usar en años pero aún configuradas para enviar desde el dominio; sistemas CRM (Salesforce, HubSpot, Pipedrive) enviando correos de notificación; software de help desk (Zendesk, Freshdesk) enviando notificaciones de casos; sistemas CI/CD enviando alertas de build. Solución: inventariar todos los sistemas que plausiblemente puedan enviar correo desde tu dominio, auditar cada uno y, o bien autorizarlo vía SPF/DKIM, o bloquearlo a nivel de sistema. La mayoría de operadores tienen 5-15 sistemas así; encontrarlos todos lleva una semana de investigación.

Escenario 2 — “SPF funciona en las herramientas de testing pero falla en el flujo real de correo”. Habitualmente la causa es que el conteo de lookups de SPF excede 10. Las herramientas de testing a veces aplanan los includes con fines de visualización, pero la resolución real de SPF en los receptores respeta el límite de 10 lookups. Diagnostica con una herramienta real de SPF lookup (mxtoolbox SPF Record Lookup, dmarcian SPF Surveyor) que cuente lookups reales. Solución: aplanar los includes (calcular los rangos IP y publicar directamente), usar macros SPF para centralizar includes o desplazar el peso de autenticación a DKIM. Cubrimos el enfoque de aplanado en detalle en SPF: solucionar el límite de 10 lookups sin servicio de pago.

Escenario 3 — “DKIM firma pero los receptores no están comprobando la firma”. Habitualmente la causa son fallos de publicación de selector o retrasos de propagación DNS. La clave del selector se publicó pero la replicación DNS está incompleta, así que los receptores comprobando la firma reciben respuestas NXDOMAIN para la clave pública. Diagnostica con dig +short TXT selector._domainkey.tudominio.com @8.8.8.8 (Google DNS) y @1.1.1.1 (Cloudflare DNS) y confirma que ambos devuelven la clave pública. Espera 24-48 horas para la propagación DNS si acabas de publicar; si la clave aún no aparece en los principales resolvers DNS, la publicación en sí falló.

Escenario 4 — “La autenticación parece perfecta pero Gmail manda el correo a spam igualmente”. La autenticación es necesaria pero no suficiente — el filtrado de Gmail también pondera la reputación del remitente, la calidad del contenido, las señales de engagement y el comportamiento del destinatario. Los operadores que pasan todas las comprobaciones de autenticación y aún así ven placement en spam deberían mirar sus señales de reputación (Gmail Postmaster Tools), métricas de engagement (tasa de apertura, tasa de clic, tasa de queja) y patrones de contenido (asunto, cuerpo, densidad de enlaces, ratio imagen-texto). La autenticación es el suelo; la reputación y el engagement determinan dónde por encima del suelo aterriza realmente tu correo. El trabajo de auditoría de entregabilidad que hacemos cada vez se enfoca más en estos factores post-autenticación porque la autenticación en sí está ya lo suficientemente estandarizada como para que la mayoría de remitentes la configure correctamente.

---

La autenticación viene incluida y mantenida en cada plan de hosting PowerMTA, hosting MailWizz e IP dedicada. Si quieres que esto esté bien una vez y dejar de preocuparte, eso vendemos. Para organizaciones cuya autenticación ya está en su sitio pero cuya entregabilidad sigue degradada — habitualmente por errores de configuración que las herramientas estándar no detectan — ofrecemos una auditoría de entregabilidad que revisa la autenticación de forma holística contra el comportamiento real de los receptores.