METODOLOGÍA XCITIONE DMARC Protect

De p=none a p=reject sin romper tu correo legítimo

Nuestra implementación sigue rigurosamente los lineamientos del NIST SP 800-177, asegurando una transición segura y validada de cada flujo transaccional.

verified_user Validación SPF
verified_user Firma DKIM
Ruta de Implementación DMARC
Progresión de política · NIST SP 800-177
verified_user p=reject alcanzado
p=none Monitoreo pct=10% Pruebas quarantine Endurecer pct=50% Escalar p=reject Blindaje total ✓
schedule
Tiempo promedio
6 sem
Para dominios simples
mail_lock
Flujos validados
100%
Antes de enforce
block
Spoofing bloqueado
99.7%
Post p=reject

Hoja de Ruta hacia la Protección Total

Un proceso metódico para mitigar riesgos sin interrumpir la operatividad del negocio.

FASE 01

Diagnóstico

Auditoría completa de remitentes externos, SaaS y sombras de TI que envían correo en su nombre.

p=none
search
FASE 02

Configuración Base

Despliegue de registros DMARC en política p=none para comenzar el análisis de reportes RUA/RUF.

p=none pct=100
settings
FASE 03

Identificación

Alineación de SPF y DKIM para todas las fuentes legítimas detectadas durante el monitoreo.

SPF + DKIM align
fingerprint
FASE 04

Endurecimiento

Transición a p=quarantine. El correo sospechoso se envía a la carpeta de spam, reduciendo el riesgo de phishing.

p=quarantine
shield
FASE 05

Política Estricta

Aplicación final de p=reject. Solo los correos 100% verificados llegan al destinatario. Blindaje total.

p=reject
verified_user

Adherencia Técnica

Arquitectura basada en los estándares más modernos de seguridad de correo electrónico.

DMARC

RFC 7489

Mecanismo de autenticación de mensajes, informes y conformidad.

SPF

RFC 7208

Marco de políticas de remitente para autorizar direcciones IP de envío.

DKIM

RFC 6376

Estándar de firmas criptográficas para asegurar la integridad del contenido.

TLS RPT

RFC 8460

Informes de errores y éxito en la negociación de canales TLS.

MTA-STS

RFC 8461

Seguridad de transporte estricta para servidores de correo.

BRANDING

BIMI

Visualización de logotipos corporativos para remitentes autenticados.

Análisis de superficie web

Reputación de la Web

Además de la reputación del correo, el verificador evalúa la superficie web del dominio con un análisis 100% pasivo (peticiones GET/HEAD y consultas DNS/TLS estándar; nunca escaneo intrusivo, fuzzing ni enumeración de rutas). Produce un puntaje sobre 100 y una calificación por letra de A+ a F.

Los 4 módulos evaluados

Módulo Peso Qué evalúa
Cabeceras HTTP de Seguridad 49 pts Content-Security-Policy (penaliza unsafe-inline/unsafe-eval), HSTS, X-Content-Type-Options, protección clickjacking (X-Frame-Options / frame-ancestors), Referrer-Policy y Permissions-Policy. Detecta además fuga de versiones de software y cabeceras obsoletas.
TLS / SSL 31 pts Versión de protocolo negociada (TLS 1.3 / 1.2), certificado válido y confiable con cobertura del dominio (CN/SAN), vigencia restante y suite de cifrado moderna (AEAD).
Redirección y Transporte 13 pts Redirección de HTTP a HTTPS con código permanente (301/308) y que la URL final permanezca en HTTPS dentro del mismo dominio registrable.
security.txt (RFC 9116) 7 pts Publicación de un canal estándar de contacto para reporte responsable de vulnerabilidades, con campos Contact y Expires vigente.
Total 100 pts

Escala de calificación

A+
95–100
A
85–94
B
70–84
C
55–69
D
40–54
E
20–39
F
0–19

Reglas de tope (cap)

Ciertas deficiencias críticas limitan la calificación máxima independientemente del puntaje numérico:

  • block Sin HSTS o sin redirección HTTP→HTTPS: la nota máxima es B.
  • dangerous Con TLS ≤ 1.1 o certificado vencido: la nota máxima es D.
info

Alcance del análisis

La Reputación de la Web es un análisis pasivo de configuraciones visibles externamente. Evalúa cómo está expuesto el dominio a internet, pero no reemplaza un análisis de vulnerabilidades ni una prueba de penetración (pentest), que requieren pruebas activas y autorizadas sobre la infraestructura. El escáner respeta límites estrictos: no sigue más de 5 redirecciones, rechaza dominios que resuelven a direcciones IP internas o privadas, y aplica un límite de peticiones por IP.

Consultas Técnicas

¿Cuánto tiempo toma llegar a p=reject?expand_more
Depende de la complejidad de la infraestructura. Para dominios simples, de 4 a 6 semanas. Para corporaciones globales, el proceso suele extenderse de 3 a 6 meses para garantizar la visibilidad total de los flujos.
¿Cómo se procesan los reportes RUA/RUF?expand_more
Nuestra plataforma ingiere archivos XML de miles de proveedores globales (Google, Microsoft, etc.), los procesa en tiempo real y los visualiza en dashboards técnicos que separan flujos legítimos de amenazas.
¿Afecta DMARC la entrega de correos internos?expand_more
Si se implementa correctamente siguiendo nuestra metodología, no. La fase de diagnóstico (p=none) permite mapear los envíos internos antes de aplicar cualquier bloqueo.
¿Qué ocurre con los proveedores SaaS como Salesforce?expand_more
Asistimos en la configuración de selectores DKIM específicos proporcionados por estos proveedores para asegurar que sus correos transaccionales mantengan la alineación DMARC.
¿Soporta la plataforma multi-dominio?expand_more
Sí, XCITIONE DMARC Protect está diseñada para gestionar jerarquías complejas de dominios y subdominios con políticas heredadas o específicas según el nivel organizacional.
¿Qué garantiza el cumplimiento de NIST?expand_more
Nuestros procesos internos y controles de seguridad están alineados con la publicación especial NIST 800-177 Rev. 1 para la seguridad del correo electrónico corporativo.

¿Listo para empezar la transición a p=reject?

Solicita una auditoría inicial de tus registros DNS y descubre quién está enviando correo en tu nombre hoy mismo.

Comenzar Diagnóstico Gratis Hablar con un Experto