DMARC: Cómo Proteger Tu Reputación de Email
Pájaro
13 abr 2016
Correo electrónico
1 min read
Puntos clave
DMARC ayuda a proteger tu dominio de phishing, suplantación de identidad y uso no autorizado de correos electrónicos publicando tus prácticas de autenticación y solicitando un manejo específico para mensajes fallidos.
Funciona junto con SPF y DKIM para asegurar la alineación del dominio y prevenir que los correos fraudulentos dañen la reputación de tu remitente.
Políticas fuertes de DMARC respaldan una mayor confianza, mayor compromiso y preparan tu dominio para el futuro a medida que el ecosistema cambia hacia modelos de reputación basados en dominios.
Las verificaciones de validación de DMARC dependen de la alineación del dominio entre el dominio De, el dominio Return-Path (SPF) y el dominio de firma DKIM.
Configurar DMARC requiere recibir informes, entender datos agregados vs. forenses, y configurar herramientas para analizarlos.
Comienzas con una política segura p=none para monitorear el tráfico antes de avanzar a quarantine o reject.
Publicar un registro DMARC implica crear una entrada DNS TXT en _dmarc.yourdomain.com con políticas, direcciones de reportes y parámetros opcionales como el porcentaje de implementación.
Los buzones de informes adecuados (agregados + forenses) y las herramientas de análisis son esenciales para monitorear el cumplimiento, detectar suplantación de identidad y asegurar que la alineación sea correcta.
DMARC solo requiere uno de los siguientes para pasar: SPF alineado o DKIM alineado.
Implementar DMARC fortalece la seguridad del correo electrónico y desempeña un papel clave en la integridad de la marca, la confianza y la capacidad de entrega a largo plazo.
Destacados de Q&A
¿Qué es DMARC y por qué importa?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) es una política publicada en DNS que protege tu dominio del spoofing y phishing al implementar la alineación del dominio y permitir visibilidad a través de informes.
¿Es DMARC un protocolo de autenticación?
No. DMARC no es la autenticación en sí misma: se basa en SPF y DKIM para autenticar el correo y utiliza políticas + informes para controlar cómo los servidores receptores manejan los fallos.
¿Qué verifica DMARC?
Verifica:
Autenticación SPF + alineación
Autenticación DKIM + alineación
Un remitente solo necesita uno de estos para que DMARC tenga éxito.
¿Qué es “domain alignment”?
Es el requisito que el dominio visible De coincida (estricto) o comparta el mismo dominio organizacional (relajado) con el dominio Return-Path del SPF o el dominio de firma DKIM.
¿Por qué DMARC mejora la entregabilidad?
Porque los proveedores de buzón confían más en dominios autenticados y alineados. DMARC evita que los mensajes falsificados erosionen tu reputación y mejora la colocación en Inbox para el correo legítimo.
¿Cuál es la diferencia entre los informes DMARC aggregate y forensic?
Informes agregados (RUA): Resúmenes XML de los resultados de autenticación a través de todo el tráfico.
Informes forenses (RUF): Muestras individuales de mensajes fallidos para un análisis más profundo.
¿Qué buzones de correo necesito antes de publicar DMARC?
Deberías crear dos direcciones, como:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Esto mantiene los flujos de informes separados y más fáciles de analizar.
¿Con qué política DMARC debería empezar?
Siempre comienza con p=none. Supervisa la actividad de autenticación sin afectar la entrega, permitiéndote identificar de manera segura problemas de alineación e intentos de suplantación.
¿Cuáles son las políticas DMARC disponibles?
none: monitor sólo
quarantine: enviar mensajes fallidos a spam
reject: bloquear mensajes fallidos completamente
¿Dónde publico un registro DMARC?
En tu DNS en:
_dmarc.yourdomain.com
Debe ser un registro TXT que especifique tu política, versión y puntos finales de informes.
¿Cómo se ve un registro básico de DMARC?
Ejemplo:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
¿Qué sucede si DMARC falla?
El servidor receptor aplica la política solicitada (ninguna, cuarentena, rechazo), aunque el manejo final depende del proveedor. Una política estricta puede reducir significativamente los intentos de phishing que utilizan su dominio.
En esta publicación, te contaremos todo lo que necesitas saber sobre cómo aprovechar DMARC para proteger tu reputación de correo electrónico y te daremos consejos sobre cómo configurarlo para tus dominios.
Un Effective Tool to Fight Mail Fraudulento
A menudo mencionado junto con los protocolos de autenticación de correo electrónico SPF y DKIM, DMARC, o autenticación de mensajes basada en el dominio, informes y conformidad, no es en sí mismo un protocolo de autenticación. En su lugar, el propósito de DMARC es permitirnos, los propietarios de dominios, proteger nuestra reputación de correo electrónico mediante:
Anunciar prácticas de autenticación de correo electrónico,
Solicitar tratamiento para el correo que no supera las verificaciones de autenticación, y
Solicitar informes sobre el correo que afirma ser de su dominio.
DMARC puede ser una herramienta eficaz para utilizar en nuestra lucha contra el correo fraudulento que apunta a nuestro nombre de dominio (por ejemplo, phishing y suplantación), y que puede fomentar una mayor confianza entre nuestros destinatarios en nuestro correo. Para organizaciones que requieren cifrado de extremo a extremo más allá de la autenticación, implementar S/MIME con métodos eficientes de recopilación de claves públicas de destinatarios proporciona capas adicionales de seguridad. Esta mayor confianza debería, a su vez, llevar a un mayor compromiso con nuestro correo, y el correo que se abre y genera clics impulsa ventas y un ROI más alto para nuestras campañas de correo electrónico.
Además de proteger nuestro dominio, predecimos que implementar DMARC ahora será una excelente manera de "preparar para el futuro" nuestro dominio. Aquí en Bird, creemos que a medida que la industria se mueva hacia IPv6, es casi seguro que se moverá de un modelo de reputación basado en IP a un modelo de reputación basado en el dominio. La reputación basada en dominios requerirá autenticación basada en dominios, y DMARC, en concierto con DKIM y SPF, ayudará a los dominios a establecer una reputación basada en dominios mucho antes de que sea absolutamente necesaria.
En esta publicación, te contaremos todo lo que necesitas saber sobre cómo aprovechar DMARC para proteger tu reputación de correo electrónico y te daremos consejos sobre cómo configurarlo para tus dominios.
A menudo mencionado junto con los protocolos de autenticación de correo electrónico SPF y DKIM, DMARC, o autenticación de mensajes basada en el dominio, informes y conformidad, no es en sí mismo un protocolo de autenticación. En su lugar, el propósito de DMARC es permitirnos, los propietarios de dominios, proteger nuestra reputación de correo electrónico mediante:
Anunciar prácticas de autenticación de correo electrónico,
Solicitar tratamiento para el correo que no supera las verificaciones de autenticación, y
Solicitar informes sobre el correo que afirma ser de su dominio.
DMARC puede ser una herramienta eficaz para utilizar en nuestra lucha contra el correo fraudulento que apunta a nuestro nombre de dominio (por ejemplo, phishing y suplantación), y que puede fomentar una mayor confianza entre nuestros destinatarios en nuestro correo. Para organizaciones que requieren cifrado de extremo a extremo más allá de la autenticación, implementar S/MIME con métodos eficientes de recopilación de claves públicas de destinatarios proporciona capas adicionales de seguridad. Esta mayor confianza debería, a su vez, llevar a un mayor compromiso con nuestro correo, y el correo que se abre y genera clics impulsa ventas y un ROI más alto para nuestras campañas de correo electrónico.
Además de proteger nuestro dominio, predecimos que implementar DMARC ahora será una excelente manera de "preparar para el futuro" nuestro dominio. Aquí en Bird, creemos que a medida que la industria se mueva hacia IPv6, es casi seguro que se moverá de un modelo de reputación basado en IP a un modelo de reputación basado en el dominio. La reputación basada en dominios requerirá autenticación basada en dominios, y DMARC, en concierto con DKIM y SPF, ayudará a los dominios a establecer una reputación basada en dominios mucho antes de que sea absolutamente necesaria.
En esta publicación, te contaremos todo lo que necesitas saber sobre cómo aprovechar DMARC para proteger tu reputación de correo electrónico y te daremos consejos sobre cómo configurarlo para tus dominios.
A menudo mencionado junto con los protocolos de autenticación de correo electrónico SPF y DKIM, DMARC, o autenticación de mensajes basada en el dominio, informes y conformidad, no es en sí mismo un protocolo de autenticación. En su lugar, el propósito de DMARC es permitirnos, los propietarios de dominios, proteger nuestra reputación de correo electrónico mediante:
Anunciar prácticas de autenticación de correo electrónico,
Solicitar tratamiento para el correo que no supera las verificaciones de autenticación, y
Solicitar informes sobre el correo que afirma ser de su dominio.
DMARC puede ser una herramienta eficaz para utilizar en nuestra lucha contra el correo fraudulento que apunta a nuestro nombre de dominio (por ejemplo, phishing y suplantación), y que puede fomentar una mayor confianza entre nuestros destinatarios en nuestro correo. Para organizaciones que requieren cifrado de extremo a extremo más allá de la autenticación, implementar S/MIME con métodos eficientes de recopilación de claves públicas de destinatarios proporciona capas adicionales de seguridad. Esta mayor confianza debería, a su vez, llevar a un mayor compromiso con nuestro correo, y el correo que se abre y genera clics impulsa ventas y un ROI más alto para nuestras campañas de correo electrónico.
Además de proteger nuestro dominio, predecimos que implementar DMARC ahora será una excelente manera de "preparar para el futuro" nuestro dominio. Aquí en Bird, creemos que a medida que la industria se mueva hacia IPv6, es casi seguro que se moverá de un modelo de reputación basado en IP a un modelo de reputación basado en el dominio. La reputación basada en dominios requerirá autenticación basada en dominios, y DMARC, en concierto con DKIM y SPF, ayudará a los dominios a establecer una reputación basada en dominios mucho antes de que sea absolutamente necesaria.
En esta publicación, te contaremos todo lo que necesitas saber sobre cómo aprovechar DMARC para proteger tu reputación de correo electrónico y te daremos consejos sobre cómo configurarlo para tus dominios.
Términos to Know
Antes de configurar DMARC para su dominio, queremos asegurarnos de que estamos hablando el mismo idioma. Comencemos definiendo algunos términos que utilizaremos a lo largo de este documento.
RFC5322.From Domain
El RFC5322.FromDomain es la parte del dominio de la dirección de correo electrónico que generalmente ve un destinatario de nuestro correo al leerlo. En el siguiente ejemplo, el RFC5322.From domain es “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM es un protocolo de autenticación que permite a un dominio hacerse responsable de un mensaje de manera que pueda ser validada por el receptor del mensaje; esto se hace mediante el uso de firmas criptográficas insertadas en los encabezados del mensaje al salir de su punto de origen. Estas firmas son esencialmente instantáneas de cómo se veía el mensaje en ese momento, y el receptor puede utilizar estas instantáneas para verificar si el mensaje ha llegado sin cambios a su destino. El proceso de producir e insertar estas instantáneas se llama firma DKIM, y el dominio que se hace responsable del mensaje al firmarlo inserta su nombre en el encabezado en una etiqueta de clave-valor como “d=signingDomain”, por lo que se le conoce como el DKIM d= domain.
Return-Path Domain
El dominio de ruta de retorno, a veces llamado RFC5321.From Domain o el dominio Mail From, es el dominio al que se dirigen los rebotados; también es el dominio en el que se realizan las verificaciones SPF durante la transacción de correo electrónico. Este dominio generalmente no es visto por el destinatario, a menos que el destinatario sea lo suficientemente hábil como para mirar todos los encabezados en un mensaje dado.
Por defecto, todo el correo enviado a través de bird.com tendrá birdmail.com como su dominio de ruta de retorno, como en el siguiente ejemplo:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Sin embargo, para que DMARC funcione para su dominio, querrá aprovechar un dominio de rebote personalizado, uno que termine en el mismo dominio que su dominio de envío, por ejemplo, bounces.yourdomain.com al usar yourdomain.com como su dominio de envío.
Organizational Domain
El término “Organizational Domain” se refiere al dominio que fue enviado a un registrador para crear la presencia del dominio en internet. Para Bird, nuestros dominios organizacionales son bird.com y birdmail.com.
Domain Alignment
El último término a entender respecto a DMARC es “Domain Alignment”, y viene en dos variantes: “relajado” y “estricto”.
Relaxed Domain Alignment
Se dice que dos dominios tienen una alineación de dominio relajada cuando sus dominios organizacionales son los mismos. Por ejemplo, a.mail.bird.com y b.foo.bird.com tienen alineación de dominio relajada por su común dominio organizacional, bird.com.
Strict Domain Alignment
Se dice que dos dominios están en alineación de dominio estricta si y solo si son idénticos. Por lo tanto, foo.bird.com y foo.bird.com están en alineación estricta, ya que los dos dominios son idénticos. Por otro lado, foo.bird.com y bar.foo.bird.com solo están en alineación relajada.
DMARC Domain Alignment Requirements
Para que las verificaciones de validación de DMARC pasen, DMARC requiere que haya una alineación de dominio de la siguiente manera:
Para SPF, el RFC5322.From domain y el dominio Return-Path deben estar alineados
Para DKIM, el RFC5322.From domain y el DKIM d= domain deben estar alineados
La alineación puede ser relajada o estricta, según la política publicada del dominio de envío.
Antes de configurar DMARC para su dominio, queremos asegurarnos de que estamos hablando el mismo idioma. Comencemos definiendo algunos términos que utilizaremos a lo largo de este documento.
RFC5322.From Domain
El RFC5322.FromDomain es la parte del dominio de la dirección de correo electrónico que generalmente ve un destinatario de nuestro correo al leerlo. En el siguiente ejemplo, el RFC5322.From domain es “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM es un protocolo de autenticación que permite a un dominio hacerse responsable de un mensaje de manera que pueda ser validada por el receptor del mensaje; esto se hace mediante el uso de firmas criptográficas insertadas en los encabezados del mensaje al salir de su punto de origen. Estas firmas son esencialmente instantáneas de cómo se veía el mensaje en ese momento, y el receptor puede utilizar estas instantáneas para verificar si el mensaje ha llegado sin cambios a su destino. El proceso de producir e insertar estas instantáneas se llama firma DKIM, y el dominio que se hace responsable del mensaje al firmarlo inserta su nombre en el encabezado en una etiqueta de clave-valor como “d=signingDomain”, por lo que se le conoce como el DKIM d= domain.
Return-Path Domain
El dominio de ruta de retorno, a veces llamado RFC5321.From Domain o el dominio Mail From, es el dominio al que se dirigen los rebotados; también es el dominio en el que se realizan las verificaciones SPF durante la transacción de correo electrónico. Este dominio generalmente no es visto por el destinatario, a menos que el destinatario sea lo suficientemente hábil como para mirar todos los encabezados en un mensaje dado.
Por defecto, todo el correo enviado a través de bird.com tendrá birdmail.com como su dominio de ruta de retorno, como en el siguiente ejemplo:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Sin embargo, para que DMARC funcione para su dominio, querrá aprovechar un dominio de rebote personalizado, uno que termine en el mismo dominio que su dominio de envío, por ejemplo, bounces.yourdomain.com al usar yourdomain.com como su dominio de envío.
Organizational Domain
El término “Organizational Domain” se refiere al dominio que fue enviado a un registrador para crear la presencia del dominio en internet. Para Bird, nuestros dominios organizacionales son bird.com y birdmail.com.
Domain Alignment
El último término a entender respecto a DMARC es “Domain Alignment”, y viene en dos variantes: “relajado” y “estricto”.
Relaxed Domain Alignment
Se dice que dos dominios tienen una alineación de dominio relajada cuando sus dominios organizacionales son los mismos. Por ejemplo, a.mail.bird.com y b.foo.bird.com tienen alineación de dominio relajada por su común dominio organizacional, bird.com.
Strict Domain Alignment
Se dice que dos dominios están en alineación de dominio estricta si y solo si son idénticos. Por lo tanto, foo.bird.com y foo.bird.com están en alineación estricta, ya que los dos dominios son idénticos. Por otro lado, foo.bird.com y bar.foo.bird.com solo están en alineación relajada.
DMARC Domain Alignment Requirements
Para que las verificaciones de validación de DMARC pasen, DMARC requiere que haya una alineación de dominio de la siguiente manera:
Para SPF, el RFC5322.From domain y el dominio Return-Path deben estar alineados
Para DKIM, el RFC5322.From domain y el DKIM d= domain deben estar alineados
La alineación puede ser relajada o estricta, según la política publicada del dominio de envío.
Antes de configurar DMARC para su dominio, queremos asegurarnos de que estamos hablando el mismo idioma. Comencemos definiendo algunos términos que utilizaremos a lo largo de este documento.
RFC5322.From Domain
El RFC5322.FromDomain es la parte del dominio de la dirección de correo electrónico que generalmente ve un destinatario de nuestro correo al leerlo. En el siguiente ejemplo, el RFC5322.From domain es “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM es un protocolo de autenticación que permite a un dominio hacerse responsable de un mensaje de manera que pueda ser validada por el receptor del mensaje; esto se hace mediante el uso de firmas criptográficas insertadas en los encabezados del mensaje al salir de su punto de origen. Estas firmas son esencialmente instantáneas de cómo se veía el mensaje en ese momento, y el receptor puede utilizar estas instantáneas para verificar si el mensaje ha llegado sin cambios a su destino. El proceso de producir e insertar estas instantáneas se llama firma DKIM, y el dominio que se hace responsable del mensaje al firmarlo inserta su nombre en el encabezado en una etiqueta de clave-valor como “d=signingDomain”, por lo que se le conoce como el DKIM d= domain.
Return-Path Domain
El dominio de ruta de retorno, a veces llamado RFC5321.From Domain o el dominio Mail From, es el dominio al que se dirigen los rebotados; también es el dominio en el que se realizan las verificaciones SPF durante la transacción de correo electrónico. Este dominio generalmente no es visto por el destinatario, a menos que el destinatario sea lo suficientemente hábil como para mirar todos los encabezados en un mensaje dado.
Por defecto, todo el correo enviado a través de bird.com tendrá birdmail.com como su dominio de ruta de retorno, como en el siguiente ejemplo:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Sin embargo, para que DMARC funcione para su dominio, querrá aprovechar un dominio de rebote personalizado, uno que termine en el mismo dominio que su dominio de envío, por ejemplo, bounces.yourdomain.com al usar yourdomain.com como su dominio de envío.
Organizational Domain
El término “Organizational Domain” se refiere al dominio que fue enviado a un registrador para crear la presencia del dominio en internet. Para Bird, nuestros dominios organizacionales son bird.com y birdmail.com.
Domain Alignment
El último término a entender respecto a DMARC es “Domain Alignment”, y viene en dos variantes: “relajado” y “estricto”.
Relaxed Domain Alignment
Se dice que dos dominios tienen una alineación de dominio relajada cuando sus dominios organizacionales son los mismos. Por ejemplo, a.mail.bird.com y b.foo.bird.com tienen alineación de dominio relajada por su común dominio organizacional, bird.com.
Strict Domain Alignment
Se dice que dos dominios están en alineación de dominio estricta si y solo si son idénticos. Por lo tanto, foo.bird.com y foo.bird.com están en alineación estricta, ya que los dos dominios son idénticos. Por otro lado, foo.bird.com y bar.foo.bird.com solo están en alineación relajada.
DMARC Domain Alignment Requirements
Para que las verificaciones de validación de DMARC pasen, DMARC requiere que haya una alineación de dominio de la siguiente manera:
Para SPF, el RFC5322.From domain y el dominio Return-Path deben estar alineados
Para DKIM, el RFC5322.From domain y el DKIM d= domain deben estar alineados
La alineación puede ser relajada o estricta, según la política publicada del dominio de envío.
Cómo DMARC Works para Proteger Tu Email Reputation
Cuando hablamos de un proveedor de buzón de correo u otro dominio "verificando DMARC", o "validando DMARC", o "aplicando política DMARC", lo que queremos decir es que el dominio que recibe un mensaje está realizando los siguientes pasos:
Identificar el dominio RFC5322.From del mensaje
Buscar la política DMARC de ese dominio en DNS
Realizar validación de firma DKIM
Realizar validación SPF
Verificar alineación de dominio
Aplicar política DMARC
Para que un mensaje pase la validación DMARC, el mensaje solo debe pasar una de las dos comprobaciones de autenticación y alineación. Entonces, un mensaje pasará la validación DMARC si cualquiera de los siguientes es verdadero:
El mensaje pasa las verificaciones SPF y el dominio RFC5322.From y el dominio de Return-Path están alineados, o
El mensaje pasa la validación DKIM y el dominio RFC5322.From y el dominio DKIM d= están alineados, o
Ambos de los anteriores son verdaderos
Cuando hablamos de un proveedor de buzón de correo u otro dominio "verificando DMARC", o "validando DMARC", o "aplicando política DMARC", lo que queremos decir es que el dominio que recibe un mensaje está realizando los siguientes pasos:
Identificar el dominio RFC5322.From del mensaje
Buscar la política DMARC de ese dominio en DNS
Realizar validación de firma DKIM
Realizar validación SPF
Verificar alineación de dominio
Aplicar política DMARC
Para que un mensaje pase la validación DMARC, el mensaje solo debe pasar una de las dos comprobaciones de autenticación y alineación. Entonces, un mensaje pasará la validación DMARC si cualquiera de los siguientes es verdadero:
El mensaje pasa las verificaciones SPF y el dominio RFC5322.From y el dominio de Return-Path están alineados, o
El mensaje pasa la validación DKIM y el dominio RFC5322.From y el dominio DKIM d= están alineados, o
Ambos de los anteriores son verdaderos
Cuando hablamos de un proveedor de buzón de correo u otro dominio "verificando DMARC", o "validando DMARC", o "aplicando política DMARC", lo que queremos decir es que el dominio que recibe un mensaje está realizando los siguientes pasos:
Identificar el dominio RFC5322.From del mensaje
Buscar la política DMARC de ese dominio en DNS
Realizar validación de firma DKIM
Realizar validación SPF
Verificar alineación de dominio
Aplicar política DMARC
Para que un mensaje pase la validación DMARC, el mensaje solo debe pasar una de las dos comprobaciones de autenticación y alineación. Entonces, un mensaje pasará la validación DMARC si cualquiera de los siguientes es verdadero:
El mensaje pasa las verificaciones SPF y el dominio RFC5322.From y el dominio de Return-Path están alineados, o
El mensaje pasa la validación DKIM y el dominio RFC5322.From y el dominio DKIM d= están alineados, o
Ambos de los anteriores son verdaderos
Hacer que DMARC funcione para tu dominio
Ahora que hemos explicado la mecánica de DMARC, hablemos sobre cómo hacer que DMARC funcione para nosotros, lo cual implica los siguientes tres pasos:
Hacer preparativos para recibir informes DMARC
Decidir qué política de DMARC usar para tu dominio
Publicar tu registro DMARC
Cubriremos cada uno de estos en detalle a continuación, pero te diremos directamente que el paso 1 anterior consumirá aproximadamente el 95% de tu tiempo de preparación.
Ahora que hemos explicado la mecánica de DMARC, hablemos sobre cómo hacer que DMARC funcione para nosotros, lo cual implica los siguientes tres pasos:
Hacer preparativos para recibir informes DMARC
Decidir qué política de DMARC usar para tu dominio
Publicar tu registro DMARC
Cubriremos cada uno de estos en detalle a continuación, pero te diremos directamente que el paso 1 anterior consumirá aproximadamente el 95% de tu tiempo de preparación.
Ahora que hemos explicado la mecánica de DMARC, hablemos sobre cómo hacer que DMARC funcione para nosotros, lo cual implica los siguientes tres pasos:
Hacer preparativos para recibir informes DMARC
Decidir qué política de DMARC usar para tu dominio
Publicar tu registro DMARC
Cubriremos cada uno de estos en detalle a continuación, pero te diremos directamente que el paso 1 anterior consumirá aproximadamente el 95% de tu tiempo de preparación.
Preparando para recibir informes DMARC
Cualquier dominio que publique una política DMARC debe primero prepararse para recibir informes sobre su dominio. Estos informes serán generados por cualquier dominio que realice la validación de DMARC y vea correos que dicen ser de nuestro dominio, y se nos enviarán al menos diariamente. Los informes vendrán en dos formatos:
Informes agregados, que son documentos XML que muestran datos estadísticos de cuánto correo fue visto por el informante desde cada fuente, cuáles fueron los resultados de autenticación y cómo los mensajes fueron tratados por el informante. Los informes agregados están diseñados para ser analizados por máquinas, con sus datos almacenados en algún lugar para permitir el análisis del tráfico general, auditoría de los flujos de mensajes de nuestro dominio y quizás la identificación de tendencias en fuentes de correo electrónico no autenticado, potencialmente fraudulento.
Informes forenses, que son copias individuales de mensajes que fallaron la autenticación, cada uno incluido en un mensaje de correo electrónico completo usando un formato llamado AFRF. Se supone que los informes forenses contienen encabezados completos y cuerpos de mensajes, pero muchos informantes eliminan o redactan alguna información por preocupaciones de privacidad. No obstante, el informe forense aún puede ser útil tanto para solucionar problemas de autenticación de nuestro dominio como para identificar, a partir de URIs en los cuerpos de los mensajes, dominios maliciosos y sitios web utilizados para defraudar a los clientes del propietario de nuestro dominio.
La preparación para recibir estos informes implica primero crear dos buzones en nuestro dominio para manejar estos informes, como agg_reports@ourdomain.com y afrf_reports@ourdomain.com. Tenga en cuenta que esos nombres de buzones son completamente arbitrarios y no hay requisitos para el nombramiento de la parte local del buzón; somos libres de elegir cualquier nombre que deseemos, pero mantener los dos separados para un procesamiento más fácil.
Una vez que se seleccionan y crean los nombres de los buzones en nuestro dominio, lo siguiente que se debe hacer aquí es poner herramientas en su lugar para leer estos buzones y hacer uso de los datos, especialmente de los informes de datos agregados, que nuevamente están diseñados para ser analizados por máquinas, más que leídos por un humano. Los informes forenses, por otro lado, pueden ser manejables simplemente leyéndolos nosotros mismos, pero nuestra capacidad para hacerlo dependerá tanto de la comprensión de nuestro cliente de correo de cómo mostrar mensajes en el formato AFRF como del volumen de informes que recibamos.
Aunque es posible que nosotros mismos escribamos herramientas para procesar informes DMARC, hasta que Bird proporcione tales servicios para los clientes de bird.com (algo que estamos considerando, pero no prometiendo aún), recomendamos que hagamos uso de herramientas que ya están disponibles para la tarea.
Cualquier dominio que publique una política DMARC debe primero prepararse para recibir informes sobre su dominio. Estos informes serán generados por cualquier dominio que realice la validación de DMARC y vea correos que dicen ser de nuestro dominio, y se nos enviarán al menos diariamente. Los informes vendrán en dos formatos:
Informes agregados, que son documentos XML que muestran datos estadísticos de cuánto correo fue visto por el informante desde cada fuente, cuáles fueron los resultados de autenticación y cómo los mensajes fueron tratados por el informante. Los informes agregados están diseñados para ser analizados por máquinas, con sus datos almacenados en algún lugar para permitir el análisis del tráfico general, auditoría de los flujos de mensajes de nuestro dominio y quizás la identificación de tendencias en fuentes de correo electrónico no autenticado, potencialmente fraudulento.
Informes forenses, que son copias individuales de mensajes que fallaron la autenticación, cada uno incluido en un mensaje de correo electrónico completo usando un formato llamado AFRF. Se supone que los informes forenses contienen encabezados completos y cuerpos de mensajes, pero muchos informantes eliminan o redactan alguna información por preocupaciones de privacidad. No obstante, el informe forense aún puede ser útil tanto para solucionar problemas de autenticación de nuestro dominio como para identificar, a partir de URIs en los cuerpos de los mensajes, dominios maliciosos y sitios web utilizados para defraudar a los clientes del propietario de nuestro dominio.
La preparación para recibir estos informes implica primero crear dos buzones en nuestro dominio para manejar estos informes, como agg_reports@ourdomain.com y afrf_reports@ourdomain.com. Tenga en cuenta que esos nombres de buzones son completamente arbitrarios y no hay requisitos para el nombramiento de la parte local del buzón; somos libres de elegir cualquier nombre que deseemos, pero mantener los dos separados para un procesamiento más fácil.
Una vez que se seleccionan y crean los nombres de los buzones en nuestro dominio, lo siguiente que se debe hacer aquí es poner herramientas en su lugar para leer estos buzones y hacer uso de los datos, especialmente de los informes de datos agregados, que nuevamente están diseñados para ser analizados por máquinas, más que leídos por un humano. Los informes forenses, por otro lado, pueden ser manejables simplemente leyéndolos nosotros mismos, pero nuestra capacidad para hacerlo dependerá tanto de la comprensión de nuestro cliente de correo de cómo mostrar mensajes en el formato AFRF como del volumen de informes que recibamos.
Aunque es posible que nosotros mismos escribamos herramientas para procesar informes DMARC, hasta que Bird proporcione tales servicios para los clientes de bird.com (algo que estamos considerando, pero no prometiendo aún), recomendamos que hagamos uso de herramientas que ya están disponibles para la tarea.
Cualquier dominio que publique una política DMARC debe primero prepararse para recibir informes sobre su dominio. Estos informes serán generados por cualquier dominio que realice la validación de DMARC y vea correos que dicen ser de nuestro dominio, y se nos enviarán al menos diariamente. Los informes vendrán en dos formatos:
Informes agregados, que son documentos XML que muestran datos estadísticos de cuánto correo fue visto por el informante desde cada fuente, cuáles fueron los resultados de autenticación y cómo los mensajes fueron tratados por el informante. Los informes agregados están diseñados para ser analizados por máquinas, con sus datos almacenados en algún lugar para permitir el análisis del tráfico general, auditoría de los flujos de mensajes de nuestro dominio y quizás la identificación de tendencias en fuentes de correo electrónico no autenticado, potencialmente fraudulento.
Informes forenses, que son copias individuales de mensajes que fallaron la autenticación, cada uno incluido en un mensaje de correo electrónico completo usando un formato llamado AFRF. Se supone que los informes forenses contienen encabezados completos y cuerpos de mensajes, pero muchos informantes eliminan o redactan alguna información por preocupaciones de privacidad. No obstante, el informe forense aún puede ser útil tanto para solucionar problemas de autenticación de nuestro dominio como para identificar, a partir de URIs en los cuerpos de los mensajes, dominios maliciosos y sitios web utilizados para defraudar a los clientes del propietario de nuestro dominio.
La preparación para recibir estos informes implica primero crear dos buzones en nuestro dominio para manejar estos informes, como agg_reports@ourdomain.com y afrf_reports@ourdomain.com. Tenga en cuenta que esos nombres de buzones son completamente arbitrarios y no hay requisitos para el nombramiento de la parte local del buzón; somos libres de elegir cualquier nombre que deseemos, pero mantener los dos separados para un procesamiento más fácil.
Una vez que se seleccionan y crean los nombres de los buzones en nuestro dominio, lo siguiente que se debe hacer aquí es poner herramientas en su lugar para leer estos buzones y hacer uso de los datos, especialmente de los informes de datos agregados, que nuevamente están diseñados para ser analizados por máquinas, más que leídos por un humano. Los informes forenses, por otro lado, pueden ser manejables simplemente leyéndolos nosotros mismos, pero nuestra capacidad para hacerlo dependerá tanto de la comprensión de nuestro cliente de correo de cómo mostrar mensajes en el formato AFRF como del volumen de informes que recibamos.
Aunque es posible que nosotros mismos escribamos herramientas para procesar informes DMARC, hasta que Bird proporcione tales servicios para los clientes de bird.com (algo que estamos considerando, pero no prometiendo aún), recomendamos que hagamos uso de herramientas que ya están disponibles para la tarea.
Which DMARC Policy to Use
La especificación DMARC proporciona tres opciones para que los propietarios de dominios especifiquen su tratamiento preferido para el correo que no pasa las verificaciones de validación DMARC. Son:
none, lo que significa tratar el correo de la misma manera que se trataría independentemente de las verificaciones de validación DMARC
quarantine, lo que significa aceptar el correo pero colocarlo en algún lugar que no sea la Bandeja de entrada del destinatario (típicamente la carpeta de spam)
reject, lo que significa rechazar el mensaje completamente
Es importante tener en cuenta que el propietario del dominio solo puede solicitar dicho tratamiento en su registro DMARC; corresponde al destinatario del mensaje decidir si honra o no la política solicitada. Algunos lo harán, mientras que otros pueden ser un poco más indulgentes al aplicar la política, como solo enviar el correo a la carpeta de spam cuando la política del dominio sea reject.
Recomendamos a todos nuestros clientes que lancen con una política de none, simplemente para estar seguros. Aunque confiamos en nuestra capacidad para autenticar correctamente su correo a través de la firma DKIM, aún es mejor tomarse un tiempo para examinar los informes sobre su dominio antes de ser más agresivo con su política DMARC.
La especificación DMARC proporciona tres opciones para que los propietarios de dominios especifiquen su tratamiento preferido para el correo que no pasa las verificaciones de validación DMARC. Son:
none, lo que significa tratar el correo de la misma manera que se trataría independentemente de las verificaciones de validación DMARC
quarantine, lo que significa aceptar el correo pero colocarlo en algún lugar que no sea la Bandeja de entrada del destinatario (típicamente la carpeta de spam)
reject, lo que significa rechazar el mensaje completamente
Es importante tener en cuenta que el propietario del dominio solo puede solicitar dicho tratamiento en su registro DMARC; corresponde al destinatario del mensaje decidir si honra o no la política solicitada. Algunos lo harán, mientras que otros pueden ser un poco más indulgentes al aplicar la política, como solo enviar el correo a la carpeta de spam cuando la política del dominio sea reject.
Recomendamos a todos nuestros clientes que lancen con una política de none, simplemente para estar seguros. Aunque confiamos en nuestra capacidad para autenticar correctamente su correo a través de la firma DKIM, aún es mejor tomarse un tiempo para examinar los informes sobre su dominio antes de ser más agresivo con su política DMARC.
La especificación DMARC proporciona tres opciones para que los propietarios de dominios especifiquen su tratamiento preferido para el correo que no pasa las verificaciones de validación DMARC. Son:
none, lo que significa tratar el correo de la misma manera que se trataría independentemente de las verificaciones de validación DMARC
quarantine, lo que significa aceptar el correo pero colocarlo en algún lugar que no sea la Bandeja de entrada del destinatario (típicamente la carpeta de spam)
reject, lo que significa rechazar el mensaje completamente
Es importante tener en cuenta que el propietario del dominio solo puede solicitar dicho tratamiento en su registro DMARC; corresponde al destinatario del mensaje decidir si honra o no la política solicitada. Algunos lo harán, mientras que otros pueden ser un poco más indulgentes al aplicar la política, como solo enviar el correo a la carpeta de spam cuando la política del dominio sea reject.
Recomendamos a todos nuestros clientes que lancen con una política de none, simplemente para estar seguros. Aunque confiamos en nuestra capacidad para autenticar correctamente su correo a través de la firma DKIM, aún es mejor tomarse un tiempo para examinar los informes sobre su dominio antes de ser más agresivo con su política DMARC.
Publicar Your DMARC Policy
La política DMARC de un dominio se anuncia publicando un registro DNS TXT en un lugar específico en el espacio de nombres DNS, a saber, “_dmarc.domainname.tld” (note el guion bajo inicial). Un registro de política DMARC básico para nuestro dominio de ejemplo anterior, joesbaitshop.com, podría verse algo así:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Desglosando este registro, tenemos:
v=DMARC1 especifica la versión DMARC (1 es la única opción ahora mismo)
p=none especifica el tratamiento preferido, o la política DMARC
rua=mailto:agg_reports@joesbait.com es el buzón al que deben enviarse los informes agregados
ruf=mailto:afrf_reports@joesbait.com es el buzón al que deben enviarse los informes forenses
pct=100 es el porcentaje de correo al que el propietario del dominio le gustaría aplicar su política. Los dominios que recién comienzan con DMARC, especialmente aquellos que probablemente generen un alto volumen de informes, pueden querer comenzar con un número mucho menor aquí para ver cómo sus procesos de manejo de informes resisten la carga.
Hay otras opciones de configuración disponibles para que un propietario de dominio las use en su registro de política DMARC también, pero los consejos que hemos proporcionado deberían ser un buen comienzo.
La política DMARC de un dominio se anuncia publicando un registro DNS TXT en un lugar específico en el espacio de nombres DNS, a saber, “_dmarc.domainname.tld” (note el guion bajo inicial). Un registro de política DMARC básico para nuestro dominio de ejemplo anterior, joesbaitshop.com, podría verse algo así:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Desglosando este registro, tenemos:
v=DMARC1 especifica la versión DMARC (1 es la única opción ahora mismo)
p=none especifica el tratamiento preferido, o la política DMARC
rua=mailto:agg_reports@joesbait.com es el buzón al que deben enviarse los informes agregados
ruf=mailto:afrf_reports@joesbait.com es el buzón al que deben enviarse los informes forenses
pct=100 es el porcentaje de correo al que el propietario del dominio le gustaría aplicar su política. Los dominios que recién comienzan con DMARC, especialmente aquellos que probablemente generen un alto volumen de informes, pueden querer comenzar con un número mucho menor aquí para ver cómo sus procesos de manejo de informes resisten la carga.
Hay otras opciones de configuración disponibles para que un propietario de dominio las use en su registro de política DMARC también, pero los consejos que hemos proporcionado deberían ser un buen comienzo.
La política DMARC de un dominio se anuncia publicando un registro DNS TXT en un lugar específico en el espacio de nombres DNS, a saber, “_dmarc.domainname.tld” (note el guion bajo inicial). Un registro de política DMARC básico para nuestro dominio de ejemplo anterior, joesbaitshop.com, podría verse algo así:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Desglosando este registro, tenemos:
v=DMARC1 especifica la versión DMARC (1 es la única opción ahora mismo)
p=none especifica el tratamiento preferido, o la política DMARC
rua=mailto:agg_reports@joesbait.com es el buzón al que deben enviarse los informes agregados
ruf=mailto:afrf_reports@joesbait.com es el buzón al que deben enviarse los informes forenses
pct=100 es el porcentaje de correo al que el propietario del dominio le gustaría aplicar su política. Los dominios que recién comienzan con DMARC, especialmente aquellos que probablemente generen un alto volumen de informes, pueden querer comenzar con un número mucho menor aquí para ver cómo sus procesos de manejo de informes resisten la carga.
Hay otras opciones de configuración disponibles para que un propietario de dominio las use en su registro de política DMARC también, pero los consejos que hemos proporcionado deberían ser un buen comienzo.
Resumen
¡Hay mucho que desempaquetar en la información anterior! Esperamos que encuentres útil el manual para crear un registro de política DMARC. También esperamos que nuestra explicación sobre por qué DMARC es importante te ayude a aclarar por qué deberías empezar a usar esta herramienta importante para proteger la reputación de tu correo electrónico.
Por supuesto, este no es un documento completo o autorizado sobre el tema. Si deseas profundizar más o necesitas más ayuda, un gran lugar para comenzar es el FAQ oficial de DMARC. Y, no hace falta decir que el equipo de soporte de Bird está listo para ayudarte a configurar tu cuenta de Bird para DMARC también.
¡Gracias por leer y comienza a proteger tus dominios con DMARC hoy!
¡Hay mucho que desempaquetar en la información anterior! Esperamos que encuentres útil el manual para crear un registro de política DMARC. También esperamos que nuestra explicación sobre por qué DMARC es importante te ayude a aclarar por qué deberías empezar a usar esta herramienta importante para proteger la reputación de tu correo electrónico.
Por supuesto, este no es un documento completo o autorizado sobre el tema. Si deseas profundizar más o necesitas más ayuda, un gran lugar para comenzar es el FAQ oficial de DMARC. Y, no hace falta decir que el equipo de soporte de Bird está listo para ayudarte a configurar tu cuenta de Bird para DMARC también.
¡Gracias por leer y comienza a proteger tus dominios con DMARC hoy!
¡Hay mucho que desempaquetar en la información anterior! Esperamos que encuentres útil el manual para crear un registro de política DMARC. También esperamos que nuestra explicación sobre por qué DMARC es importante te ayude a aclarar por qué deberías empezar a usar esta herramienta importante para proteger la reputación de tu correo electrónico.
Por supuesto, este no es un documento completo o autorizado sobre el tema. Si deseas profundizar más o necesitas más ayuda, un gran lugar para comenzar es el FAQ oficial de DMARC. Y, no hace falta decir que el equipo de soporte de Bird está listo para ayudarte a configurar tu cuenta de Bird para DMARC también.
¡Gracias por leer y comienza a proteger tus dominios con DMARC hoy!
