Analizador DMARC

Te preparas para pasar de monitorización a enforcement y necesitas saber si el registro publicado resistirá la evaluación de los receptores. Marketing envía desde un CRM, producto usa un proveedor transaccional y finanzas mantiene un relay local. Antes de subir `p` de `none` a `quarantine`, DN01 muestra si el TXT en `_dmarc.example.com` es sintácticamente válido, si etiquetas duplicadas invalidarían el registro y si `pct` ya limita el enforcement. Esa única publicación DNS es lo que evalúan miles de millones de buzones; un error en `p=` o un segundo TXT DMARC puede debilitar la protección en todos los canales.

Los tickets de entregabilidad culpan a DMARC aunque SPF pase por separado. Un mensaje puede tener SPF válido y aun así fallar DMARC cuando envelope From, header From y el dominio firmante DKIM no se alinean según `aspf` y `adkim`. DN01 muestra los modos de alineación: si faltan etiquetas, asume relajado (`r`) y advierte que los receptores pueden aceptar coincidencias de dominio más amplias de lo previsto. Combina el resultado con DKIM Validator para ver selectores activos y con DNS Checker para includes SPF.

Los equipos de seguridad usan DMARC como control antisuplantación para dominios ejecutivos, portales de partners y marcas parecidas. Si `_dmarc` no existe, DN01 devuelve un diagnóstico claro — `no DMARC record found at _dmarc.<domain>` — y recomienda publicar `v=DMARC1` con política inicial. No es un fallo de la herramienta; es el estado que ven los receptores cuando el phishing puede reutilizar tu dominio sin política de rechazo publicada.

Los MSP revisan DMARC en decenas de zonas de clientes durante onboarding o renovaciones. Las consultas manuales con `dig` no escalan cuando debes comparar `sp` con `p`, verificar buzones de informes y detectar `pct` inválido en un portafolio. DN01 devuelve un informe consistente con duración, inventario de etiquetas y recomendaciones para tickets. La página SEO de resultado por dominio ofrece a stakeholders un enlace estable sobre la publicación actual.

Arquitecturas con muchos subdominios — `news.example.com`, `billing.example.com`, `eu.example.com` — dependen de `sp=` cuando las zonas hijas envían con SPF y DKIM propios. Sin `sp`, los receptores aplican `p` a subdominios, lo que sorprende a equipos que creían tener la zona aislada. DN01 muestra ambos valores y marca políticas de subdominio inválidas igual que las organizacionales. Si `sp=reject` es más estricto que `p=quarantine`, ves la asimetría de inmediato.

Los cuestionarios de compliance piden evidencia de madurez en autenticación de correo, no solo casillas marcadas. Los auditores quieren saber si hay reporting agregado (`rua`), si el enforcement es parcial (`pct` menor que 100) y si el registro es válido hoy. DN01 responde desde DNS en vivo, guarda el TXT crudo y separa errores duros (etiquetas duplicadas, políticas desconocidas) de advertencias (modo monitorización, alineación relajada).

Tras una ola de suplantación, la respuesta a incidentes suele empezar por «¿falta DMARC o está mal?». Cuando varios TXT en `_dmarc` incluyen más de un fragmento `v=DMARC1`, los receptores pueden tratar la configuración como inválida. DN01 elige el primer registro coincidente pero informa errores de etiqueta duplicada dentro de una cadena, ayudando a distinguir DNS dividido de TXT histórico inofensivo. Vuelve a comprobar tras el TTL y valida firmas con DKIM Validator antes de volver a `reject`.

Si DN01 informa que no hay registro DMARC, consulta `_dmarc.tudominio.tld` específicamente, no el TXT raíz donde vive SPF. Muchos equipos publican SPF en el apex y asumen que DMARC se hereda. Confirma el registro en todos los NS autoritativos tras migrar de proveedor DNS; delegaciones obsoletas hacen que un resolver vea `v=DMARC1` y otro NXDOMAIN.

Cuando `valid` es falso con `found` true, lee primero el array de errores. Etiquetas `p=` duplicadas, políticas desconocidas, `pct` no entero o fuera de 0–100 invalidan el registro. Elimina duplicados en el panel DNS, mantén un solo TXT con punto y coma y evita dividir DMARC en varios TXT sin concatenación correcta. Tras editar, espera el TTL y vuelve a ejecutar el analizador.

Las advertencias sobre `p=none`, `rua` ausente o alineación relajada describen exposición, no siempre fallos actuales. `p=none` monitoriza sin pedir cuarentena o rechazo. Sin `rua` no recibirás informes XML agregados. Si las advertencias mencionan alineación relajada, decide si necesitas `adkim=s` o `aspf=s` antes de `reject`.

Si el DNS en vivo no coincide con el panel del registrador, compara el campo de registro crudo con `dig +short TXT _dmarc.dominio`. Cachés, diferencias anycast e importaciones parciales engañan dashboards. DN01 consulta en el momento de la petición; guarda el TXT crudo como evidencia externa.

Si el correo legítimo falla tras endurecer la política, DMARC puede estar bien mientras SPF o DKIM no. Usa DNS Checker para includes SPF y DKIM Validator para selectores y caducidad de claves. `pct=50` hace que los fallos parezcan aleatorios; DN01 advierte cuando pct es menor que 100.

DMARC se apoya en SPF y DKIM. SPF valida la ruta del sobre; DKIM la firma criptográfica; DMARC pregunta si alguno se alinea con el dominio visible en From y qué hacer si ambos fallan. DN01 no envía correo ni evalúa mensajes individuales: inspecciona la política DNS que indica a los receptores cómo tratar tráfico desalineado. Por eso conviene combinarlo con DKIM Validator y DNS Checker.

La etiqueta `p=` es obligatoria. Las políticas deben ser `none`, `quarantine` o `reject`; cualquier otro valor se marca inválido. `none` sirve para monitorización inicial, pero DN01 advierte que no bloquea correo fallido. `quarantine` suele enviar fallos a spam; `reject` pide descartar mensajes. La escalada debe basarse en informes `rua`, no solo en fechas.

`pct` limita qué fracción de mensajes fallidos recibe la política. Valores bajo 100 implican enforcement parcial, útil en despliegues graduales pero confuso al depurar. DN01 parsea `pct` como entero y error si no es numérico o sale de 0–100. La mayoría de marcas terminan en `pct=100` con informes limpios.

Los informes agregados van a URI `rua`, normalmente `mailto:` registrados en tu procesador. DN01 lista destinos separados por comas y advierte si falta `rua`. Los informes forenses `ruf` son opcionales y sensibles; muchas organizaciones omiten `ruf`. El analizador muestra ambos si están publicados.

`adkim` y `aspf` controlan coincidencia estricta (`s`) o relajada (`r`). Si faltan, DN01 asume relajado y advierte que los receptores pueden aceptar combinaciones apex/subdominio no deseadas. Los modos estrictos son habituales antes de `reject`.

Válido en DN01 significa ausencia de errores de parseo bloqueantes en el momento de la consulta. Un registro de monitorización con `p=none` y sin `rua` puede estar found con advertencias. Trata `valid=false` como defecto DNS crítico hasta corregirlo.

`dig TXT _dmarc.example.com` muestra cadenas crudas rápido, pero la interpretación queda en el operador. Hay que recordar que `p=` duplicado invalida el registro, que `sp` gobierna subdominios y que sin `rua` no hay reporting. DN01 codifica esas reglas y devuelve recomendaciones en el mismo paso.

DNS Checker en DN01 muestra todos los TXT de la zona, útil cuando SPF, DKIM y tokens de verificación conviven con DMARC. No puntúa riesgo de política ni destaca `pct` parcial. Usa DNS Checker para contexto de zona; DMARC Analyzer para la política en `_dmarc`.

Los informes XML agregados en el buzón muestran historial de envío, pero llegan con retraso y reflejan tráfico pasado. No prueban la publicación DNS actual tras un cambio urgente. DN01 responde la pregunta de publicación en vivo en segundos.

Las consolas DMARC de proveedores ofrecen dashboards, pero auditores externos necesitan un lookup neutro del TXT visible en internet. DN01 es independiente del buzón de informes y funciona incluso sin `rua`.

Validadores TXT genéricos a veces no aplican reglas específicas de DMARC. DN01 usa el mismo parser Go que la API de producción, así SEO y API comparten validación de `p`, `sp`, `pct`, duplicados y defaults de alineación.

Los inventarios en hoja de cálculo envejecen tras una edición DNS. Una URL de resultado DN01 da a soporte y entregabilidad una instantánea actual con nombre de consulta, registro crudo y tiempo.