Generador de Registros DMARC DNS y Validador de Sintaxis

Generador de Registros DMARC DNS y Validador de Sintaxis

Genere y valide registros DNS TXT DMARC conformes a RFC 7489 con políticas de aplicación (none/quarantine/reject), reportes agregados rua/ruf y etiquetas de alineación.

Preajustes:
Enforcement Percentage (pct=)100%
Domain: example.comPolicy: rejectPct: 100%
Security Health ScoreGrado de seguridad A+ (100/100)

Maximum defense against spoofing, BEC attacks, and phishing impersonation.

100/100
DMARC DNS TXT Value
v=DMARC1; p=reject; rua=mailto:[email protected]!10m
BIND 9 / RFC 1035 Master Zone Syntax
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]!10m"
DNS Management Table
Host / Name_dmarc(or _dmarc.example.com)
Record TypeTXT
TTL3600 (or Auto)
Length: 60 charsUDP DNS: < 255 B (Single String)
RFC 7489 Valid
Estado de la políticap=reject (100%)
Fuentes de informes1 RUA / 0 RUF
Modos de alineaciónDKIM: Relaxed | SPF: Relaxed

Sintaxis compatible con RFC 7489

Formatea instantáneamente etiquetas v=DMARC1 válidas con estricto orden de etiquetas y validación.

Constructor local en el navegador

Todo el cálculo de políticas y la ejecución del analizador ocurren en el cliente sin telemetría.

Motor de exportación multiplataforma

Genere registros de zona BIND, configuraciones de Cloudflare/Route53, consultas dig CLI y autorizaciones externas RFC 7489 Sección 7.1.

Referencia técnica y guía de arquitectura

Generador de Registros de Política DMARC DNS y Validador de Sintaxis — Guía de referencia

Genere y valide registros DNS TXT DMARC conformes a RFC 7489 con políticas de aplicación (none/quarantine/reject), reportes agregados rua/ruf y etiquetas de alineación.

Parámetros clave y controles

v (Versión del protocolo)Enum ("DMARC1")

Identifica el registro como una especificación de política DMARC. Debe ubicarse como la primera etiqueta en mayúsculas, seguida de punto y coma.

Por defecto: DMARC1
p (Política para el receptor)Enum ("none" | "quarantine" | "reject")

Política de cumplimiento aplicada por los servidores de correo cuando un mensaje falla tanto la autenticación SPF como DKIM. 'none' solo monitorea sin bloquear; 'quarantine' desvía a la carpeta de spam; 'reject' rechaza la entrega en la capa SMTP.

Por defecto: none
sp (Política de subdominios)Enum ("none" | "quarantine" | "reject")

Anula la directiva 'p' específicamente para todos los subdominios. Configurar 'sp=reject' protege eficazmente contra la suplantación de identidad en subdominios inactivos o no autorizados.

Por defecto: Heredada (igual que p)
rua (URIs de informes agregados)Lista de URIs (mailto:address)

Lista separada por comas de URIs mailto: que reciben informes diarios en XML con estadísticas agregadas de autenticación, IPs de origen y volúmenes.

Por defecto: Ninguno
ruf (URIs de informes forenses/fallos)Lista de URIs (mailto:address)

Lista separada por comas de URIs mailto: para recibir notificaciones forenses inmediatas en formato RFC 6591 AFRF ante fallos específicos de autenticación.

Por defecto: Ninguno
pct (Porcentaje de aplicación de la directiva)Integer (0 - 100)

Porcentaje de mensajes fallidos a los que se les aplica la política 'p' o 'sp'. Facilita un despliegue gradual (ej. 25% -> 50% -> 100%) antes de forzar el rechazo total.

Por defecto: 100
adkim / aspf (Modos de alineación)Enum ("r" | "s")

Define el rigor de coincidencia de dominios para DKIM y SPF. 'r' (relajado) permite coincidencias a nivel de dominio organizativo raíz (subdomain.example.com con example.com); 's' (estricto) exige coincidencia exacta de FQDN.

Por defecto: r (relajado)

Consejos profesionales y mejores prácticas

Comience con 'p=none' durante 2 a 4

Comience con 'p=none' durante 2 a 4 semanas para analizar los informes agregados XML (rua) e identificar proveedores legítimos (SendGrid, Microsoft 365, Mailchimp). Cuando más del 99% del correo válido supere SPF y DKIM, avance a 'p=quarantine; pct=25', aumente al 100% y finalmente pase a 'p=reject'.

Si su dominio es 'example.com' y la

Si su dominio es 'example.com' y la dirección 'rua' apunta a 'mailto:[email protected]', el RFC 7489 Sección 7.1 exige que el dominio destino publique un registro TXT en 'example.com._report._dmarc.thirdparty.com' con valor 'v=DMARC1;'. Sin esto, los servidores receptores descartarán los envíos por seguridad anti-DDoS.

Los atacantes suelen suplantar

Los atacantes suelen suplantar subdominios no registrados (ej. facturacion.example.com) en vez del dominio raíz. Establecer 'v=DMARC1; p=none; sp=reject; rua=mailto:...' mantiene intacta la entregabilidad de su correo principal mientras neutraliza el phishing en subdominios.

Cuando un mensaje pasa por listas de

Cuando un mensaje pasa por listas de correo o servicios de reenvío automático, la IP del remitente de sobre cambia y rompe SPF. En cambio, las firmas criptográficas DKIM permanecen intactas, garantizando que el mensaje supere DMARC sin ser rechazado erróneamente.

Errores comunes y solución de problemas

No se reciben informes agregados rua desde proveedores clave (Google, Microsoft, Yahoo)

Compruebe que el valor rua comience con el prefijo 'mailto:' (ej. 'mailto:[email protected]'). Si utiliza un dominio de recolección de terceros, verifique que exista el registro de consentimiento TXT en el dominio destino y que el buzón no tenga la cuota llena.

Los correos legítimos enviados desde CRM o plataformas de marketing se van a spam tras activar quarantine o reject

Revise los archivos XML en busca de desalineación en DKIM o SPF. Asegúrese de que el proveedor firme con una clave DKIM personalizada cuyo dominio coincida con el encabezado From: visible (RFC 5322), y cree los registros CNAME necesarios para el Return-Path personalizado.

Los comprobadores de DNS informan 'Registro DMARC no encontrado' o 'Múltiples registros detectados'

El registro DMARC debe publicarse estrictamente como tipo TXT en el subdominio '_dmarc.midominio.com' (nunca en la raíz '@'). Además, solo debe existir un único registro que comience con 'v=DMARC1'; publicar más de uno invalida toda la política según la RFC 7489.

Preguntas frecuentes (FAQ)

¿Cuál es la relación técnica entre SPF, DKIM y DMARC?▼

SPF (RFC 7208) valida la IP del servidor emisor frente al remitente del sobre (MAIL FROM). DKIM (RFC 6376) firma digitalmente las cabeceras y el cuerpo para garantizar autenticidad. DMARC (RFC 7489) vincula ambos protocolos con la dirección 'From:' visible (RFC 5322), exige alineación de dominios, define la acción ante fallos y proporciona informes agregados.

¿Es obligatorio que un correo supere tanto SPF como DKIM para validar DMARC?▼

No. De acuerdo con el RFC 7489, un correo aprueba DMARC si se cumple la alineación de SPF O la alineación de DKIM. Basta con que uno de los dos sea válido, aunque se aconseja implementar ambos para contar con redundancia ante reenvíos.

¿Cuál es la diferencia entre los modos de alineación relajado ('r') y estricto ('s')?▼

En modo relajado ('r', predeterminado), el dominio de la firma DKIM o del Return-Path de SPF solo necesita compartir el mismo dominio organizativo raíz con el From: (ej. mail.example.com con example.com). En modo estricto ('s'), los FQDN deben coincidir de forma idéntica carácter por carácter.

¿Por qué las listas de distribución y los reenvíos automáticos causan fallos en DMARC?▼

Los servidores de reenvío modifican la IP emisora (rompiendo SPF) y con frecuencia agregan textos al pie o modifican el asunto (destruyendo el hash de DKIM). Para mitigar este problema, los proveedores implementan el estándar ARC (Authenticated Received Chain, RFC 8617), que preserva la evaluación de autenticidad original.

¿Qué diferencia existe entre los reportes agregados rua y los reportes forenses ruf?▼

rua recopila informes diarios en XML con estadísticas generales de volumen, direcciones IP y porcentajes de autenticación sin divulgar contenido. ruf envía notificaciones inmediatas con copia de los mensajes que fallaron. Debido a normativas de privacidad como el RGPD, los grandes proveedores han discontinuado la generación de reportes ruf.

Herramientas y utilidades relacionadas

Todas las herramientas →
Guía de Desarrollo del Generador de Registros DNS CAA (Certification Authority Authorization)Seguridad

Genere registros DNS CAA conformes a la RFC 8659 para restringir la emisión de certificados SSL/TLS únicamente a autoridades de confianza (Let's Encrypt, DigiCert, Sectigo).

Abrir herramienta→
Guía de Desarrollo: Generador de Registros DNS DKIM TXT y SelectoresSeguridad

Cree registros DNS DKIM TXT compatibles con RFC 6376 con selector, formato de clave pública (v=DKIM1; k=rsa; p=...), división de 255 caracteres y verificación.

Abrir herramienta→
Guía para Desarrolladores del Generador de Políticas MTA-STS y Registros DNS TLS-RPTSeguridad

Referencia técnica integral y mejores prácticas para generar archivos de directivas RFC 8461 MTA-STS, registros DNS TXT _mta-sts y registros de informes RFC 8460 TLS-RPT.

Abrir herramienta→
Decodificador e Inspector de Seguridad de Tokens JWTSeguridad

Utilidad para desarrolladores que decodifica tokens JWT del lado del cliente, inspecciona claims RFC 7519 y OIDC, audita tiempos de expiración y verifica firmas HMAC localmente.

Abrir herramienta→
Generador Criptográfico de Contraseñas y Frases de PasoSeguridad

Genere contraseñas seguras de alta entropía, frases de paso memorables (Diceware), códigos PIN y tokens de API mediante la API Web Crypto CSPRNG según NIST SP 800-63B.

Abrir herramienta→
Generador de Huellas y Hash CriptográficoSeguridad

Calcule al instante valores hash SHA-256, SHA-512, MD5, SHA-1, SHA-3, Keccak y CRC32 localmente en su navegador mediante la API Web Crypto 100% segura.

Abrir herramienta→