DMARC Record Checker es para una parte de la infraestructura de correo electrónico que suena abstracta hasta que el correo real comienza a desaparecer, a terminar en spam o a ser falsificado por personas a las que no invitaste a tu marca. Usted ingresa un nombre de dominio, el verificador busca el registro TXT en _dmarc.yourdomain.com , analiza la política y muestra lo que ese dominio realmente les dice a los sistemas receptores de correo que hagan. Eso incluye la política principal como none , cuarentena o rechazar , las reglas de alineación para SPF y DKIM, las direcciones del informe en rua y ruf , la etiqueta de porcentaje pct , el intervalo de informe ri y otros detalles que las personas tienden a descubrir solo después de que algo costoso ya salió mal.

Para alguien que escucha el término por primera vez, las letras son maravillosamente literales. DMARC significa Autenticación, informes y conformidad de mensajes basados ​​en dominio . Esas palabras no fueron elegidas por los poetas, y eso es parte de su encanto. Basado en dominio significa que el sistema está vinculado al dominio de envío visible. Autenticación de mensajes significa que depende de comprobaciones técnicas como SPF y DKIM. Informar significa que los receptores pueden enviar comentarios sobre lo que están viendo. Conformidad significa que el dominio del remitente puede publicar una política que indique cómo se debe tratar el correo no autenticado o no alineado. Leído despacio, las siglas son casi un completo manual de usuario con sobretodo burocrático.

Esa parte visible del dominio importa más de lo que mucha gente cree. SPF y DKIM ya existían antes de DMARC. SPF permite que un dominio publique qué sistemas pueden enviarle correo. DKIM permite al firmante adjuntar una firma criptográfica que se puede verificar con una clave pública en DNS. Útil, sí. Suficientes por sí solos, no siempre. El problema más profundo fue la alineación. Un mensaje podría pasar SPF o DKIM en algún lugar de la tubería y aún mostrar un dominio De diferente visible para la persona que lo lee. Esa brecha era terreno fértil para la suplantación de identidad, el phishing, el abuso de marcas y un carnaval general de ambigüedad técnica. DMARC llegó para reducir esa brecha. Plantea una pregunta más disciplinada: ¿los identificadores autenticados se alinean con el dominio que se muestra al destinatario humano?

Por eso DMARC no es simplemente “un registro DNS más”. Es una capa de política que se encuentra por encima del SPF y DKIM. La descripción general de DMARC lo explica como un mecanismo que ayuda a los receptores a determinar si un mensaje se alinea con lo que saben sobre el supuesto remitente y, si no es así, la política publicada les dice cómo el propietario del dominio desea que se maneje dicho correo. En términos prácticos, DMARC toma la autenticación de correo electrónico y agrega consecuencias. Un dominio puede comenzar con cautela con p=none , que es el modo de monitoreo. Puede pasar a cuarentena , lo que solicita a los destinatarios que traten el correo defectuoso con sospecha. Puede pasar a rechazar , que es la versión adulta de decir: "Si falla la alineación lo suficiente, no lo dejes entrar".

La historia detrás de esto es la historia habitual de Internet: confiar primero, reparar después, estandarizar después de que el daño se vuelva lo suficientemente costoso. El correo electrónico se creó en una era que tenía mucha más fe en la honestidad del remitente de la que la realidad moderna ha ganado. La suplantación de identidad se volvió fácil, el phishing se volvió rentable y la suplantación de marcas se convirtió en un ejercicio industrial constante. SPF y DKIM resolvieron parte del rompecabezas, pero las organizaciones aún necesitaban una manera de decir, en una política clara, cómo se debe evaluar el dominio visible De y qué comentarios deben recibir. Esa necesidad produjo DMARC, publicado en RFC 7489. El lenguaje de los estándares tiende a parecer restringido, pero el motivo subyacente es obvio: si Internet insiste en permitir el intercambio global de mensajes a una escala absurda, será mejor que haya una manera de decir quién está realmente detrás de un mensaje y qué debería suceder cuando esa afirmación colapse.

Hay una pequeña comedia administrativa oculta en el propio nombre del host DNS. Los registros DMARC se publican en _dmarc . Ni en el dominio simple, ni en alguna nube mística de “configuraciones de seguridad”, ni en la memoria emocional del último administrador de sistemas que juró haberlo configurado hace años. Se espera que la política esté en una etiqueta dedicada, como _dmarc.example.com . Esa ubicación fija existe porque los redactores de estándares prefieren sistemas reproducibles a búsquedas del tesoro. Un servidor receptor no debería necesitar intuición, profecía o acceso al chat de su equipo para encontrar su registro de políticas.

La gramática del disco también es menos indulgente de lo que preferiría la cultura informal de copiar y pegar. RFC 7489 requiere que el registro comience con v=DMARC1 y la etiqueta p es obligatoria y debe aparecer justo después de la etiqueta de versión. Si se publican varios registros DMARC en la misma ubicación, el resultado no es una "seguridad adicional". Es un fracaso. El RFC dice que el destinatario del correo debe ignorar la política descubierta en esa ubicación si aparece más de un registro DMARC. Esta es una de esas raras áreas en las que el protocolo responde a una configuración excesiva creativa con una negativa inexpresiva a seguir el juego.

Luego vienen las etiquetas que la gente sigue encontrando en los paneles de administración de DNS y pretendiendo entenderlas únicamente desde la memoria muscular. p es la política principal. sp puede definir una política separada para subdominios. adkim y aspf controlan el rigor de la alineación para DKIM y SPF. La alineación relajada es más indulgente. La alineación estricta es más exacta. pct permite que un dominio aplique una política solo a un porcentaje del correo fallido, lo cual es útil para la implementación por etapas y también extremadamente útil para dudas indefinidas. ri sugiere con qué frecuencia se deben enviar informes agregados. calle contiene destinos de informes agregados. ruf contiene destinos de informes de fallas. para refina cuando se solicitan informes de fallas. rf nombra formatos de informes de fallas. Nada de eso es decorativo. Cada etiqueta existe porque alguien, en algún lugar, fue quemado lo suficiente por la ambigüedad como para exigir un campo para esa cosa.

Los informes son donde DMARC se convierte en mucho más que un sello de aprobación/rechazo. Los informes agregados, generalmente enviados a las direcciones enumeradas en rua , permiten al propietario de un dominio ver quién en Internet envía correo utilizando ese dominio y cómo lo evalúan los receptores. Los borradores y la descripción general de DMARC dejan en claro que los informes son fundamentales para la implementación, porque permiten al propietario del dominio descubrir tanto el uso no autorizado como los flujos de correo legítimos que aún necesitan una autenticación adecuada. En palabras sencillas, los informes le indican si la ecología del correo de su dominio es saludable o si la mitad de su correo "legítimo" circula sin firmar, desalineado o lanzado por plataformas de terceros olvidadas que todos asumieron que alguien más había documentado.

Esta última categoría merece su propia ala de museo. Muchas organizaciones imaginan que DMARC es un conmutador único. Publicar registro. Siéntete seguro. Ponga "correo electrónico protegido" en una diapositiva. La implementación real suele ser más complicada. La plataforma de marketing firma con un dominio DKIM. CRM utiliza otro camino. El software de venta de entradas envía desde un subdominio que nadie recuerda. Las facturas financieras pasan por un relevo administrado por un proveedor cuya guía de configuración fue escrita en un tono de peligrosa confianza. Alguien agrega p=none para mayor visibilidad, promete un paso gradual hacia su aplicación y luego la política permanece ahí durante dieciocho meses como una nota diplomática sobre la que nadie tiene intención de actuar. Mientras tanto, la organización sigue hablando de una “fuerte postura de seguridad del correo electrónico” con la solemne certeza normalmente reservada a las declaraciones de misión y al arte de oficina mal elegido.

Es por eso que un verdadero verificador DMARC no debería detenerse en "registro encontrado". Encontrar un registro es trivial. Las preguntas serias son más agudas. ¿Existe exactamente un registro DMARC? ¿Es válida la sintaxis? ¿Tiene sentido la política? ¿El dominio está atrapado para siempre en modo de monitoreo? ¿Están configurados los informes agregados? ¿Los informes de fallas están configurados de manera sensata? ¿Las configuraciones de alineación estricta son intencionales o accidentales? ¿Están realmente autorizadas las direcciones de informes externos? RFC 7489 incluye un mecanismo para la verificación de destino externo utilizando un registro DNS dedicado en _report._dmarc , porque de lo contrario los dominios podrían dirigir a los receptores a difundir informes a terceros sin consentimiento. Esa pequeña elección de diseño le dice todo sobre Internet: incluso la dirección de informe necesita una estructura de permisos porque alguien, en algún lugar, abusaría absolutamente de la versión más simple.

La parte más reveladora de DMARC puede ser la palabra conformidad . Suena rígido, casi eclesiástico, pero dice algo importante. DMARC no se trata simplemente de publicar artefactos de identidad. Se trata de decidir si un mensaje se ajusta a las expectativas de autenticación declaradas por el propietario del dominio. Esa es una afirmación más fuerte que "tenemos SPF en alguna parte" o "existe una firma DKIM en alguna esquina de los encabezados". La conformidad pregunta si el mensaje realmente se alinea con el dominio visible para el destinatario. Convierte controles técnicos dispersos en juicios de política. Es precisamente por eso que DMARC es importante en la defensa contra el phishing y la protección de marcas, y también por qué las implementaciones débiles crean una falsa sensación de rectitud sin ofrecer mucha resistencia real.

Entonces, ¿qué debería enseñar un verificador de registros DMARC serio? Debería enseñar que un nombre de dominio es la identidad visible, DNS es la capa de publicación, SPF y DKIM son ingredientes de autenticación y DMARC es el marco de políticas que hace que esos ingredientes respondan a la identidad visible del remitente. Debería enseñar que p=none no se aplica, que los registros DMARC duplicados no son "extra minuciosos", que las direcciones de los informes son importantes, que las configuraciones de alineación cambian el comportamiento y que la autenticación de correo electrónico es una de esas disciplinas técnicas para adultos donde pequeñas cadenas en DNS pueden determinar silenciosamente si las facturas, los restablecimientos de contraseñas, los avisos legales y el correo ejecutivo se entregan, se ponen en cuarentena o se descartan.

Al final, esa es la razón por la que vale la pena comprobar cuidadosamente DMARC. Es uno de los pocos lugares donde un breve registro DNS puede expresar la seriedad corporativa de manera más honesta que una página de retórica política. O el dominio publica una política de autenticación coherente con informes procesables y alineación defendible, o no lo hace. DNS es maravillosamente poco sentimental en ese sentido. No califica según la intención. No importa con qué frecuencia el equipo dijo "realmente deberíamos reforzar la seguridad del correo electrónico el próximo trimestre". Sólo sirve para el registro que existe.