Seguridad del correo en 2026 (parte 2): de B+ al 100 % con DMARC, DKIM y MTA-STS

Arquitectura aplicada: autenticación del envío (izquierda), cifrado obligatorio en la recepción (derecha) y DNSSEC como base de confianza.

Publicado el 30 de octubre de 2026 · Seguridad del correo · Lectura: 10 minutos

Actualización de un artículo anterior. En junio de 2022 publiqué Garantizar la integridad y confidencialidad en correos electrónicos basado en los protocolos de seguridad, donde explicaba por qué SPF, DKIM, DMARC y el cifrado en tránsito protegen un dominio. Cuatro años después vuelvo a revisarlo con datos: qué he cambiado, por qué y cómo lo he verificado.

Esta semana he llevado la seguridad del correo de mi dominio de un notable a la puntuación máxima (100 %). Hoy cualquier correo que intente hacerse pasar por mi dominio se rechaza, mis envíos legítimos salen firmados y alineados, y el correo que recibo exige TLS válido. Te cuento el proceso como lo haría en una auditoría: estado inicial, cambios, verificación, marco normativo y riesgos.

Resumen ejecutivo

B+ → 100 %Puntuación 2022 → 2026

p=rejectDMARC aplicado al 100 %

2048 bitsDKIM propio y alineado

enforceMTA-STS + TLS 1.3

• Suplantación en el envío: bloqueada. Los receptores rechazan cualquier correo que use mi dominio sin superar SPF o DKIM alineados.
• Interceptación en la recepción: mitigada. Los servidores que me escriben deben usar TLS con un certificado válido; si no pueden, no entregan.
• Visibilidad: recibo informes diarios de los grandes proveedores. En los primeros informes tras el cambio, el 100 % de mis envíos pasa la autenticación y no aparece ningún intento de suplantación.

Diagnóstico final: 100 %

Evaluación externa del dominio (30/10/2026): 100 % Excellent. Correo saliente con DMARC, SPF y DKIM válidos; correo entrante con MTA-STS y TLS-RPT válidos.

El análisis lo hice con varias herramientas públicas e independientes entre sí. El único elemento "no encontrado" es BIMI (el logotipo en la bandeja de entrada), que es opcional, no resta puntuación y exige un certificado de pago; lo explico al final.

2022 frente a 2026: qué ha cambiado

Control	Situación anterior	Situación actual	Efecto
DMARC	Política de rechazo aplicada solo a una parte del correo (pct parcial)	Rechazo al 100 %, alineación estricta, también en subdominios	Ningún correo falso con mi dominio llega a la bandeja
DKIM	Firma con el dominio genérico del proveedor de correo (válida, pero no alineada)	Firma con mi propio dominio, RSA 2048	DMARC pasa por dos vías independientes (SPF y DKIM)
SPF	Correcto	Correcto, alineado en modo estricto, menos de 10 consultas DNS	Solo los servidores autorizados pueden enviar
MTA-STS	Modo testing (solo informa)	Modo enforce, política de 1 semana	Se impide la entrega sin cifrar o a servidores falsos
MX	Política MTA-STS y registros MX no coincidían del todo	Coherencia total entre política y MX	Sin avisos en los validadores
TLS-RPT	Registro duplicado	Un único registro válido	Informes diarios de cifrado
DNSSEC	Activo	Activo en registrador y servidores de nombres	Respuestas DNS firmadas: no se pueden falsificar

Cómo encajan las piezas

El diagrama de la cabecera del artículo resume la arquitectura: en el envío, SPF y DKIM alineados alimentan a DMARC en reject, que entrega el correo legítimo y rechaza la suplantación; en la recepción, MTA-STS en enforce obliga a usar TLS válido y TLS-RPT informa de cualquier fallo; y por debajo de todo, DNSSEC firma los registros DNS para que nadie pueda falsificarlos.

Las mejoras aplicadas, una a una

Los ejemplos usan el dominio ficticio ejemplo.com. Sirven como plantilla para cualquier dominio; no son mis valores reales.

1. DKIM propio y alineado: la pieza que faltaba

Al revisar las cabeceras de mis propios correos descubrí que, aunque DKIM daba pass, la firma no era de mi dominio sino de un dominio técnico del proveedor de correo. Muchos proveedores (Google Workspace, Microsoft 365 y otros) firman así por defecto hasta que el administrador activa la firma con el dominio propio. Para DMARC estricto esa firma no cuenta, porque no está alineada.

Antes:   dkim=pass header.d=dominio-tecnico-del-proveedor   → no alineado
Después: dkim=pass header.d=ejemplo.com  s=selector2026    → alineado

La solución fue publicar la clave pública (RSA 2048) y iniciar la autenticación en la consola del proveedor. Desde ese momento DMARC pasa por dos caminos independientes; si un reenvío rompe el SPF, el DKIM sigue validando.

2. DMARC: de aplicación parcial a rechazo total

El registro tenía pct limitado y la etiqueta rf, ambas en desuso en la revisión del estándar (DMARCbis). Con DKIM ya alineado, el paso a rechazo total era seguro:

_dmarc.ejemplo.com  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; fo=1; rua=mailto:informes-dmarc@ejemplo.com"

• p=reject y sp=reject: rechazar la suplantación en el dominio y en los subdominios.
• adkim=s y aspf=s: alineación estricta; un subdominio no vale por el dominio principal.
• Sin pct: la política se aplica al 100 % del correo.
• rua: buzón para los informes agregados. Es buena práctica usar un buzón dedicado, no el personal.

3. SPF: sencillo y dentro de los límites

ejemplo.com  TXT  "v=spf1 include:_spf.proveedor-de-correo.example ~all"

Un único registro, menos de 10 consultas DNS y ninguna consulta vacía. Mantengo ~all (fallo suave) porque, con DMARC en reject y alineación estricta, es la combinación habitual en las guías del sector: la decisión final la toma DMARC y se evitan rechazos prematuros en reenvíos.

4. MTA-STS: de "testing" a "enforce"

MTA-STS publica, por HTTPS, qué servidores MX son legítimos y obliga a entregar con TLS válido. Lo tenía en modo de prueba; tras validar los MX y el certificado pasé a modo de aplicación:

https://mta-sts.ejemplo.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.proveedor-de-correo.example
mx: *.mx.proveedor-de-correo.example
max_age: 604800

_mta-sts.ejemplo.com  TXT  "v=STSv1; id=20261028"

Regla de oro: cada cambio en la política exige volver a publicar el archivo y cambiar el id del registro DNS. Sin un id nuevo, los remitentes siguen usando la versión que tienen en caché.

Además, añadí a los MX el servidor que ya figuraba en la política, para que política y DNS coincidan exactamente. La política se aloja en un servicio estático con HTTPS y renovación automática del certificado (Firebase Hosting, GitHub Pages o Cloudflare Pages son opciones gratuitas válidas).

5. TLS-RPT y DNSSEC: visibilidad y confianza en el DNS

Eliminé un registro TLS-RPT duplicado (con dos registros, los remitentes ignoran ambos) y comprobé que DNSSEC está activo en el registrador y en los servidores de nombres. Sin DNSSEC, un atacante podría falsificar las respuestas DNS y anular el resto de controles.

6. Inventario de registros heredados

Revisé los registros antiguos (copias de SPF en nombres que nadie consulta, selectores DKIM de años anteriores, MX de subdominios sin uso). No restan puntuación, pero en una auditoría conviene documentarlos, decidir si se mantienen y revocar las claves DKIM antiguas cuando se roten. Un dominio limpio es un dominio auditable.

Cómo lo verifiqué

Un control que no se verifica es solo una hipótesis. Seguí tres niveles de evidencia:

1. Validadores externos. Puntuación global del dominio (100 %), validador de MTA-STS (política, certificado y MX correctos) y consulta directa a los servidores de nombres autoritativos con dig.
2. Cabeceras reales. Envié y recibí correos de prueba con Gmail, Outlook, Yahoo y un servidor corporativo con Microsoft 365. En todos, la cabecera Authentication-Results mostraba SPF, DKIM y DMARC en pass y el transporte con TLS 1.3.
3. Informes DMARC agregados. Google, Microsoft y Yahoo ya envían sus informes diarios. Los posteriores al cambio muestran la política aplicada al 100 %, todos los envíos legítimos alineados y ningún intento de suplantación.

Authentication-Results: mx.receptor.example;
  dkim=pass header.d=ejemplo.com;
  spf=pass smtp.mailfrom=ejemplo.com;
  dmarc=pass (p=REJECT sp=REJECT) header.from=ejemplo.com

Comandos de comprobación que uso (sustituye el dominio):

dig +short TXT _dmarc.ejemplo.com
dig +short TXT _mta-sts.ejemplo.com
dig +short TXT _smtp._tls.ejemplo.com
curl -s https://mta-sts.ejemplo.com/.well-known/mta-sts.txt
dig +dnssec +short SOA ejemplo.com

Marco normativo y buenas prácticas

Como arquitecto de seguridad, cada control debe poder justificarse frente a un estándar. Esta es la trazabilidad de lo aplicado:

Referencia	Qué exige o recomienda	Cómo se cumple
RFC 7208 · 6376 · 7489	Estándares de SPF, DKIM y DMARC	Registros válidos, DKIM 2048 alineado y DMARC en reject
RFC 8461 · 8460	MTA-STS y TLS-RPT	Política en enforce por HTTPS e informes diarios
RFC 4033-4035	DNSSEC	Zona firmada con cadena de confianza desde el registrador
ENS (RD 311/2022)	Medida mp.s.1 Protección del correo electrónico: autenticidad del remitente, protección frente a suplantación y cifrado	Autenticación SPF/DKIM/DMARC y transporte cifrado obligatorio
ISO/IEC 27001:2022	5.14 Transferencia de información · 8.20 y 8.21 Seguridad de redes y servicios de red · 8.24 Uso de criptografía	Correo autenticado, cifrado en tránsito y claves de 2048 bits con rotación planificada
NIST SP 800-177 Rev. 1	Guía de correo electrónico confiable	Aplicación conjunta de SPF, DKIM, DMARC, MTA-STS y DNSSEC
NIS2 (art. 21)	Medidas técnicas de gestión de riesgos, incluida la criptografía	Controles documentados, medidos y revisados
Requisitos de Google, Yahoo y Microsoft	Autenticación y DMARC obligatorios para remitentes (2024–2025)	Se supera el mínimo exigido: DMARC en reject, no solo none

Riesgos tratados y riesgo residual

Amenaza	Antes	Ahora	Control
Suplantación exacta del dominio (phishing, fraude del CEO / BEC)	Media	Muy baja	DMARC reject 100 %
Correo legítimo en spam por falta de alineación	Media	Baja	DKIM y SPF alineados
Degradación de STARTTLS o servidor intermedio falso (MitM)	Media	Baja	MTA-STS enforce + TLS-RPT
Falsificación de respuestas DNS	Baja	Baja	DNSSEC
Dominios parecidos (typosquatting)	Media	Media	Fuera del alcance de DMARC: requiere vigilancia de registros de dominios similares
Robo de la cuenta de correo o del panel DNS	Media	Baja	MFA resistente al phishing (passkeys) y bloqueo de transferencia del dominio

La lección para cualquier organización: DMARC protege tu dominio exacto, no tu marca. Un atacante puede registrar un dominio parecido. Por eso estos controles técnicos se completan con concienciación y vigilancia.

Esta semana, también en el blog

He aplicado el mismo criterio de seguridad y cumplimiento al propio blog:

• Privacidad y legalidad: política de privacidad actualizada (RGPD), aviso legal (LSSI) y gestión del consentimiento de cookies con opciones de aceptar, rechazar o elegir.
• Formulario de contacto protegido: sin exponer ninguna dirección de correo y con varias capas antispam alineadas con OWASP ASVS (validación de entradas y controles antiautomatización).
• Publicidad transparente: archivo ads.txt publicado y bloqueo de categorías de anuncios sensibles.
• Navegación segura: HTTPS obligatorio y DNS sin registros conflictivos.

Checklist para tu dominio

1. Inventaría todos los servicios que envían correo con tu dominio (correo, CRM, boletines, facturación).
2. Publica un único SPF con menos de 10 consultas DNS.
3. Activa DKIM con tu dominio (2048 bits) en cada servicio.
4. Empieza con DMARC p=none y un buzón de informes.
5. Analiza los informes 2–4 semanas y corrige los envíos no alineados.
6. Sube a quarantine y después a reject, sin pct.
7. Publica MTA-STS en testing, revisa TLS-RPT y pasa a enforce.
8. Activa DNSSEC en tu registrador.
9. Protege con MFA las cuentas de correo, DNS y registrador.
10. Revisa informes cada semana el primer mes y rota las claves DKIM cada año.

Sobre BIMI: permite mostrar tu logotipo junto a tus correos, pero requiere DMARC en quarantine o reject y un certificado VMC o CMC de pago. Para una marca con mucho volumen de envíos compensa; para un dominio personal o una pyme pequeña, es opcional.

Conclusión

Pasar del 86 % al 100 % no fue cuestión de añadir registros, sino de leer la evidencia: una firma DKIM que pasaba pero no se alineaba, una política aplicada a medias y un modo de prueba que nunca se cerró. Son exactamente los hallazgos que aparecen en las auditorías de correo de empresas de cualquier tamaño, y se corrigen en horas con método: medir, corregir, verificar y documentar.

Si gestionas un dominio y quieres revisar tu configuración, puedes escribirme desde la página de contacto.

Referencias

• RFC 7489 – DMARC · RFC 6376 – DKIM · RFC 7208 – SPF
• RFC 8461 – MTA-STS · RFC 8460 – TLS-RPT · RFC 4033 – DNSSEC
• Real Decreto 311/2022 – Esquema Nacional de Seguridad
• NIST SP 800-177 Rev. 1 – Trustworthy Email
• Google – Directrices para remitentes de correo · Yahoo – Buenas prácticas para remitentes · Microsoft – Requisitos de Outlook para remitentes

Artículo relacionado: Garantizar la integridad y confidencialidad en correos electrónicos (2022). Los ejemplos de configuración son genéricos y no reflejan los valores reales del dominio. Las medidas descritas deben adaptarse al análisis de riesgos de cada organización.