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 aprovechar DMARC para proteger la reputación de tu correo electrónico, y te daremos consejos sobre cómo configurarlo para tus dominios.
En esta publicación, te contaremos todo lo que necesitas saber sobre aprovechar DMARC para proteger la reputación de tu correo electrónico, y te daremos consejos sobre cómo configurarlo para tus dominios.
En esta publicación, te contaremos todo lo que necesitas saber sobre aprovechar DMARC para proteger la reputación de tu correo electrónico, y te daremos consejos sobre cómo configurarlo para tus dominios.
Una Herramienta Efectiva para Combatir el Correo Fraudulento
A menudo mencionado en el mismo contexto que los protocolos de autenticación de correo electrónico SPF y DKIM, DMARC, o Autenticación, Reportes y Conformidad de Mensajes de Dominio, no es en sí mismo un protocolo de autenticación. En cambio, el propósito de DMARC es permitirnos, a los propietarios del dominio, proteger nuestra reputación de correo electrónico mediante:
Anunciando prácticas de autenticación de correo electrónico,
Solicitando tratamiento para correos que no pasan las verificaciones de autenticación, y
Solicitando informes sobre correos que afirman provenir de su dominio.
DMARC puede ser una herramienta efectiva para que la usemos en nuestra lucha contra correos fraudulentos que tienen como objetivo nuestro nombre de dominio (por ejemplo, phishing y suplantación de identidad), y que pueden promover una mayor confianza entre nuestros destinatarios para nuestro correo. Para organizaciones que requieren encriptación de extremo a extremo además de autenticación, implementar S/MIME con métodos eficientes de recolección de clave pública del destinatario proporciona capas de seguridad adicionales. Esta mayor confianza debería, en consecuencia, llevar a un mayor compromiso con nuestro correo, y el correo que se abre y genera clics fomenta ventas y mayor ROI para nuestras campañas de correo electrónico.
Aparte de proteger nuestro dominio, predecimos que implementar DMARC ahora será una excelente manera de "futuro" asegurar nuestro dominio. Aquí en Bird, creemos que a medida que la industria se mueve hacia IPv6, casi seguramente pasará de un modelo de reputación basado en IP a un modelo de reputación basado en dominio. La reputación basada en dominio requerirá autenticación basada en dominio, y DMARC, junto con DKIM y SPF, ayudará a los dominios a establecer una reputación basada en dominio mucho antes de que uno pueda ser absolutamente necesario.
En esta publicación, te contaremos todo lo que necesitas saber sobre cómo usar DMARC para proteger tu reputación de correo electrónico y te daremos consejos sobre cómo configurarlo para tus dominios.
A menudo mencionado en el mismo contexto que los protocolos de autenticación de correo electrónico SPF y DKIM, DMARC, o Autenticación, Reportes y Conformidad de Mensajes de Dominio, no es en sí mismo un protocolo de autenticación. En cambio, el propósito de DMARC es permitirnos, a los propietarios del dominio, proteger nuestra reputación de correo electrónico mediante:
Anunciando prácticas de autenticación de correo electrónico,
Solicitando tratamiento para correos que no pasan las verificaciones de autenticación, y
Solicitando informes sobre correos que afirman provenir de su dominio.
DMARC puede ser una herramienta efectiva para que la usemos en nuestra lucha contra correos fraudulentos que tienen como objetivo nuestro nombre de dominio (por ejemplo, phishing y suplantación de identidad), y que pueden promover una mayor confianza entre nuestros destinatarios para nuestro correo. Para organizaciones que requieren encriptación de extremo a extremo además de autenticación, implementar S/MIME con métodos eficientes de recolección de clave pública del destinatario proporciona capas de seguridad adicionales. Esta mayor confianza debería, en consecuencia, llevar a un mayor compromiso con nuestro correo, y el correo que se abre y genera clics fomenta ventas y mayor ROI para nuestras campañas de correo electrónico.
Aparte de proteger nuestro dominio, predecimos que implementar DMARC ahora será una excelente manera de "futuro" asegurar nuestro dominio. Aquí en Bird, creemos que a medida que la industria se mueve hacia IPv6, casi seguramente pasará de un modelo de reputación basado en IP a un modelo de reputación basado en dominio. La reputación basada en dominio requerirá autenticación basada en dominio, y DMARC, junto con DKIM y SPF, ayudará a los dominios a establecer una reputación basada en dominio mucho antes de que uno pueda ser absolutamente necesario.
En esta publicación, te contaremos todo lo que necesitas saber sobre cómo usar DMARC para proteger tu reputación de correo electrónico y te daremos consejos sobre cómo configurarlo para tus dominios.
A menudo mencionado en el mismo contexto que los protocolos de autenticación de correo electrónico SPF y DKIM, DMARC, o Autenticación, Reportes y Conformidad de Mensajes de Dominio, no es en sí mismo un protocolo de autenticación. En cambio, el propósito de DMARC es permitirnos, a los propietarios del dominio, proteger nuestra reputación de correo electrónico mediante:
Anunciando prácticas de autenticación de correo electrónico,
Solicitando tratamiento para correos que no pasan las verificaciones de autenticación, y
Solicitando informes sobre correos que afirman provenir de su dominio.
DMARC puede ser una herramienta efectiva para que la usemos en nuestra lucha contra correos fraudulentos que tienen como objetivo nuestro nombre de dominio (por ejemplo, phishing y suplantación de identidad), y que pueden promover una mayor confianza entre nuestros destinatarios para nuestro correo. Para organizaciones que requieren encriptación de extremo a extremo además de autenticación, implementar S/MIME con métodos eficientes de recolección de clave pública del destinatario proporciona capas de seguridad adicionales. Esta mayor confianza debería, en consecuencia, llevar a un mayor compromiso con nuestro correo, y el correo que se abre y genera clics fomenta ventas y mayor ROI para nuestras campañas de correo electrónico.
Aparte de proteger nuestro dominio, predecimos que implementar DMARC ahora será una excelente manera de "futuro" asegurar nuestro dominio. Aquí en Bird, creemos que a medida que la industria se mueve hacia IPv6, casi seguramente pasará de un modelo de reputación basado en IP a un modelo de reputación basado en dominio. La reputación basada en dominio requerirá autenticación basada en dominio, y DMARC, junto con DKIM y SPF, ayudará a los dominios a establecer una reputación basada en dominio mucho antes de que uno pueda ser absolutamente necesario.
En esta publicación, te contaremos todo lo que necesitas saber sobre cómo usar 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 que comencemos a configurar DMARC para su dominio, queremos asegurarnos de que estamos hablando el mismo idioma. Empecemos definiendo algunos términos que usaremos a lo largo de este documento.
Dominio RFC5322.From
El RFC5322.FromDomain es la parte del dominio de la dirección de correo electrónico que generalmente es vista por el destinatario de nuestro correo cuando está siendo leído. En el siguiente ejemplo, el dominio RFC5322.From es “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Dominio
DKIM es un protocolo de autenticación que permite que un dominio se responsabilice de un mensaje de una manera que pueda ser validada por el receptor del mensaje; esto se hace a través del uso de firmas criptográficas insertadas en los encabezados del mensaje cuando está saliendo de su punto de origen. Estas firmas son, efectivamente, instantáneas de cómo se veía el mensaje en ese momento, y el receptor puede usar estas instantáneas para ver si el mensaje ha llegado sin cambios a su destino. El proceso de producir e insertar estas instantáneas se llama firmar DKIM, y el dominio que se responsabiliza del mensaje al firmarlo inserta su nombre en el encabezado en una etiqueta de clave-valor como “d=signingDomain”, y por eso se le denomina como el dominio DKIM d=.
Dominio Return-Path
El dominio Return-Path, a veces llamado RFC5321. From Domain o el dominio Mail From, es el dominio al cual se dirigen los rebotes; también es el dominio sobre el cual se realizan las comprobaciones 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 experto 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 Return-Path, 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 terminará en el mismo dominio que su dominio de envío, por ejemplo, bounces.yourdomain.com cuando use yourdomain.com como su dominio de envío.
Dominio Organizacional
El término “Dominio Organizacional” 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.
Alineación de Dominio
El último término que debemos entender respecto a DMARC es “Alineación de Dominio,” y viene en dos variantes: “relajada” y “estricta.”
Alineación de Dominio Relajada
Se dice que dos dominios tienen alineación de dominio relajada cuando sus Dominios Organizacionales son iguales. 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.
Alineación de Dominio Estricta
Se dice que dos dominios están en alineación de dominio estricta si y solo si son idénticos. Así, 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.
Requisitos de Alineación de Dominio DMARC
Para que las comprobaciones de validación DMARC pasen, DMARC requiere que haya alineación de dominio de la siguiente manera:
Para SPF, el dominio RFC5322.From y el dominio Return-Path deben estar alineados
Para DKIM, el dominio RFC5322.From y el dominio DKIM d= deben estar alineados
La alineación puede ser relajada o estricta, en función de la política publicada del dominio de envío.
Antes de que comencemos a configurar DMARC para su dominio, queremos asegurarnos de que estamos hablando el mismo idioma. Empecemos definiendo algunos términos que usaremos a lo largo de este documento.
Dominio RFC5322.From
El RFC5322.FromDomain es la parte del dominio de la dirección de correo electrónico que generalmente es vista por el destinatario de nuestro correo cuando está siendo leído. En el siguiente ejemplo, el dominio RFC5322.From es “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Dominio
DKIM es un protocolo de autenticación que permite que un dominio se responsabilice de un mensaje de una manera que pueda ser validada por el receptor del mensaje; esto se hace a través del uso de firmas criptográficas insertadas en los encabezados del mensaje cuando está saliendo de su punto de origen. Estas firmas son, efectivamente, instantáneas de cómo se veía el mensaje en ese momento, y el receptor puede usar estas instantáneas para ver si el mensaje ha llegado sin cambios a su destino. El proceso de producir e insertar estas instantáneas se llama firmar DKIM, y el dominio que se responsabiliza del mensaje al firmarlo inserta su nombre en el encabezado en una etiqueta de clave-valor como “d=signingDomain”, y por eso se le denomina como el dominio DKIM d=.
Dominio Return-Path
El dominio Return-Path, a veces llamado RFC5321. From Domain o el dominio Mail From, es el dominio al cual se dirigen los rebotes; también es el dominio sobre el cual se realizan las comprobaciones 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 experto 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 Return-Path, 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 terminará en el mismo dominio que su dominio de envío, por ejemplo, bounces.yourdomain.com cuando use yourdomain.com como su dominio de envío.
Dominio Organizacional
El término “Dominio Organizacional” 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.
Alineación de Dominio
El último término que debemos entender respecto a DMARC es “Alineación de Dominio,” y viene en dos variantes: “relajada” y “estricta.”
Alineación de Dominio Relajada
Se dice que dos dominios tienen alineación de dominio relajada cuando sus Dominios Organizacionales son iguales. 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.
Alineación de Dominio Estricta
Se dice que dos dominios están en alineación de dominio estricta si y solo si son idénticos. Así, 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.
Requisitos de Alineación de Dominio DMARC
Para que las comprobaciones de validación DMARC pasen, DMARC requiere que haya alineación de dominio de la siguiente manera:
Para SPF, el dominio RFC5322.From y el dominio Return-Path deben estar alineados
Para DKIM, el dominio RFC5322.From y el dominio DKIM d= deben estar alineados
La alineación puede ser relajada o estricta, en función de la política publicada del dominio de envío.
Antes de que comencemos a configurar DMARC para su dominio, queremos asegurarnos de que estamos hablando el mismo idioma. Empecemos definiendo algunos términos que usaremos a lo largo de este documento.
Dominio RFC5322.From
El RFC5322.FromDomain es la parte del dominio de la dirección de correo electrónico que generalmente es vista por el destinatario de nuestro correo cuando está siendo leído. En el siguiente ejemplo, el dominio RFC5322.From es “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Dominio
DKIM es un protocolo de autenticación que permite que un dominio se responsabilice de un mensaje de una manera que pueda ser validada por el receptor del mensaje; esto se hace a través del uso de firmas criptográficas insertadas en los encabezados del mensaje cuando está saliendo de su punto de origen. Estas firmas son, efectivamente, instantáneas de cómo se veía el mensaje en ese momento, y el receptor puede usar estas instantáneas para ver si el mensaje ha llegado sin cambios a su destino. El proceso de producir e insertar estas instantáneas se llama firmar DKIM, y el dominio que se responsabiliza del mensaje al firmarlo inserta su nombre en el encabezado en una etiqueta de clave-valor como “d=signingDomain”, y por eso se le denomina como el dominio DKIM d=.
Dominio Return-Path
El dominio Return-Path, a veces llamado RFC5321. From Domain o el dominio Mail From, es el dominio al cual se dirigen los rebotes; también es el dominio sobre el cual se realizan las comprobaciones 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 experto 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 Return-Path, 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 terminará en el mismo dominio que su dominio de envío, por ejemplo, bounces.yourdomain.com cuando use yourdomain.com como su dominio de envío.
Dominio Organizacional
El término “Dominio Organizacional” 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.
Alineación de Dominio
El último término que debemos entender respecto a DMARC es “Alineación de Dominio,” y viene en dos variantes: “relajada” y “estricta.”
Alineación de Dominio Relajada
Se dice que dos dominios tienen alineación de dominio relajada cuando sus Dominios Organizacionales son iguales. 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.
Alineación de Dominio Estricta
Se dice que dos dominios están en alineación de dominio estricta si y solo si son idénticos. Así, 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.
Requisitos de Alineación de Dominio DMARC
Para que las comprobaciones de validación DMARC pasen, DMARC requiere que haya alineación de dominio de la siguiente manera:
Para SPF, el dominio RFC5322.From y el dominio Return-Path deben estar alineados
Para DKIM, el dominio RFC5322.From y el dominio DKIM d= deben estar alineados
La alineación puede ser relajada o estricta, en función de la política publicada del dominio de envío.
Cómo DMARC Works to Protect Your Email Reputation
Cuando hablamos de un proveedor de buzón o de otro dominio que “verifica DMARC”, o “valida DMARC”, o “aplica la 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
Consultar la política DMARC de ese dominio en el DNS
Realizar la validación de la Firma DKIM
Realizar la Validación SPF
Comprobar la alineación del dominio
Aplicar la política DMARC
Para que un mensaje pase la validación DMARC, el mensaje debe pasar solo una de las dos verificaciones de autenticación y alineación. Entonces, un mensaje pasará la validación DMARC si cualquiera de las siguientes condiciones es verdadera:
El mensaje pasa las verificaciones SPF y el dominio RFC5322.From y el dominio 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
Ambas condiciones anteriores son verdaderas
Resumen de Rutas de Validación DMARC
Ruta de autenticación | Dominios comparados | Alineación necesaria | Condición de paso DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relajada o estricta | SPF pasa y los dominios están alineados |
DKIM | RFC5322.From ↔ DKIM d= | Relajada o estricta | DKIM pasa y los dominios están alineados |
SPF + DKIM | Ambos anteriores | Cualquiera alineado | Una o ambas verificaciones alineadas pasan |
Cuando hablamos de un proveedor de buzón o de otro dominio que “verifica DMARC”, o “valida DMARC”, o “aplica la 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
Consultar la política DMARC de ese dominio en el DNS
Realizar la validación de la Firma DKIM
Realizar la Validación SPF
Comprobar la alineación del dominio
Aplicar la política DMARC
Para que un mensaje pase la validación DMARC, el mensaje debe pasar solo una de las dos verificaciones de autenticación y alineación. Entonces, un mensaje pasará la validación DMARC si cualquiera de las siguientes condiciones es verdadera:
El mensaje pasa las verificaciones SPF y el dominio RFC5322.From y el dominio 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
Ambas condiciones anteriores son verdaderas
Resumen de Rutas de Validación DMARC
Ruta de autenticación | Dominios comparados | Alineación necesaria | Condición de paso DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relajada o estricta | SPF pasa y los dominios están alineados |
DKIM | RFC5322.From ↔ DKIM d= | Relajada o estricta | DKIM pasa y los dominios están alineados |
SPF + DKIM | Ambos anteriores | Cualquiera alineado | Una o ambas verificaciones alineadas pasan |
Cuando hablamos de un proveedor de buzón o de otro dominio que “verifica DMARC”, o “valida DMARC”, o “aplica la 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
Consultar la política DMARC de ese dominio en el DNS
Realizar la validación de la Firma DKIM
Realizar la Validación SPF
Comprobar la alineación del dominio
Aplicar la política DMARC
Para que un mensaje pase la validación DMARC, el mensaje debe pasar solo una de las dos verificaciones de autenticación y alineación. Entonces, un mensaje pasará la validación DMARC si cualquiera de las siguientes condiciones es verdadera:
El mensaje pasa las verificaciones SPF y el dominio RFC5322.From y el dominio 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
Ambas condiciones anteriores son verdaderas
Resumen de Rutas de Validación DMARC
Ruta de autenticación | Dominios comparados | Alineación necesaria | Condición de paso DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relajada o estricta | SPF pasa y los dominios están alineados |
DKIM | RFC5322.From ↔ DKIM d= | Relajada o estricta | DKIM pasa y los dominios están alineados |
SPF + DKIM | Ambos anteriores | Cualquiera alineado | Una o ambas verificaciones alineadas pasan |
Haciendo DMARC funcionar para su 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:
Realizar preparativos para recibir informes de DMARC
Decidir qué política de DMARC usar para tu dominio
Publicar tu registro de DMARC
Cubriremos cada uno de estos en detalle a continuación, pero te diremos directamente que el paso 1 mencionado arriba 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:
Realizar preparativos para recibir informes de DMARC
Decidir qué política de DMARC usar para tu dominio
Publicar tu registro de DMARC
Cubriremos cada uno de estos en detalle a continuación, pero te diremos directamente que el paso 1 mencionado arriba 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:
Realizar preparativos para recibir informes de DMARC
Decidir qué política de DMARC usar para tu dominio
Publicar tu registro de DMARC
Cubriremos cada uno de estos en detalle a continuación, pero te diremos directamente que el paso 1 mencionado arriba consumirá aproximadamente el 95% de tu tiempo de preparación.
Preparando para recibir DMARC Reports
Cualquier dominio que publique una política DMARC debería primero prepararse para recibir informes sobre su dominio. Estos informes serán generados por cualquier dominio que realice la validación DMARC y vea correo electrónico que reclama 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 reportero desde cada fuente, cuáles fueron los resultados de autenticación y cómo fueron tratados los mensajes por el reportero. Los informes agregados están diseñados para ser analizados por máquina, con sus datos almacenados en algún lugar para permitir el análisis general de tráfico, auditoría de los flujos de mensajes de nuestro dominio y quizás 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 encerrado en un mensaje de correo electrónico completo utilizando un formato llamado AFRF. Se supone que los informes forenses contienen encabezados completos y cuerpos de mensajes, pero muchos reporteros eliminan o redactan alguna información debido a preocupaciones de privacidad. No obstante, el informe forense puede ser útil tanto para solucionar problemas de autenticación de nuestro propio dominio como para identificar, a partir de los URIs en los cuerpos de los mensajes, dominios y sitios web maliciosos utilizados para defraudar a los clientes del propietario de nuestro dominio.
La preparación para recibir estos informes implica primero crear dos buzones de correo en nuestro dominio para manejar estos informes, como agg_reports@ourdomain.com y afrf_reports@ourdomain.com. Note que esos nombres de buzón de correo son completamente arbitrarios y no hay requisitos para el nombramiento de la parte local del buzón de correo; somos libres de elegir cualquier nombre que deseemos, pero mantenerlos separados para facilitar el procesamiento.
Una vez que los nombres de los buzones de correo son seleccionados y creados en nuestro dominio, lo siguiente que hay que hacer aquí es implementar herramientas para leer estos buzones de correo y utilizar los datos, especialmente los informes de datos agregados, que nuevamente están diseñados para ser analizados por máquina, en lugar de ser leídos por un humano. Los informes forenses, por otro lado, podrían ser manejables simplemente leyéndolos nosotros mismos, pero nuestra capacidad para hacerlo dependerá tanto de la comprensión de nuestro cliente de correo acerca de cómo mostrar mensajes en el formato AFRF como del volumen de informes que recibamos.
Aunque es posible que escribamos nuestras propias herramientas para procesar informes DMARC, hasta que Bird proporcione esos servicios para los clientes de bird.com (algo que estamos considerando, pero aún no prometemos), recomendamos que utilicemos herramientas que ya están disponibles para la tarea.
Cualquier dominio que publique una política DMARC debería primero prepararse para recibir informes sobre su dominio. Estos informes serán generados por cualquier dominio que realice la validación DMARC y vea correo electrónico que reclama 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 reportero desde cada fuente, cuáles fueron los resultados de autenticación y cómo fueron tratados los mensajes por el reportero. Los informes agregados están diseñados para ser analizados por máquina, con sus datos almacenados en algún lugar para permitir el análisis general de tráfico, auditoría de los flujos de mensajes de nuestro dominio y quizás 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 encerrado en un mensaje de correo electrónico completo utilizando un formato llamado AFRF. Se supone que los informes forenses contienen encabezados completos y cuerpos de mensajes, pero muchos reporteros eliminan o redactan alguna información debido a preocupaciones de privacidad. No obstante, el informe forense puede ser útil tanto para solucionar problemas de autenticación de nuestro propio dominio como para identificar, a partir de los URIs en los cuerpos de los mensajes, dominios y sitios web maliciosos utilizados para defraudar a los clientes del propietario de nuestro dominio.
La preparación para recibir estos informes implica primero crear dos buzones de correo en nuestro dominio para manejar estos informes, como agg_reports@ourdomain.com y afrf_reports@ourdomain.com. Note que esos nombres de buzón de correo son completamente arbitrarios y no hay requisitos para el nombramiento de la parte local del buzón de correo; somos libres de elegir cualquier nombre que deseemos, pero mantenerlos separados para facilitar el procesamiento.
Una vez que los nombres de los buzones de correo son seleccionados y creados en nuestro dominio, lo siguiente que hay que hacer aquí es implementar herramientas para leer estos buzones de correo y utilizar los datos, especialmente los informes de datos agregados, que nuevamente están diseñados para ser analizados por máquina, en lugar de ser leídos por un humano. Los informes forenses, por otro lado, podrían ser manejables simplemente leyéndolos nosotros mismos, pero nuestra capacidad para hacerlo dependerá tanto de la comprensión de nuestro cliente de correo acerca de cómo mostrar mensajes en el formato AFRF como del volumen de informes que recibamos.
Aunque es posible que escribamos nuestras propias herramientas para procesar informes DMARC, hasta que Bird proporcione esos servicios para los clientes de bird.com (algo que estamos considerando, pero aún no prometemos), recomendamos que utilicemos herramientas que ya están disponibles para la tarea.
Cualquier dominio que publique una política DMARC debería primero prepararse para recibir informes sobre su dominio. Estos informes serán generados por cualquier dominio que realice la validación DMARC y vea correo electrónico que reclama 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 reportero desde cada fuente, cuáles fueron los resultados de autenticación y cómo fueron tratados los mensajes por el reportero. Los informes agregados están diseñados para ser analizados por máquina, con sus datos almacenados en algún lugar para permitir el análisis general de tráfico, auditoría de los flujos de mensajes de nuestro dominio y quizás 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 encerrado en un mensaje de correo electrónico completo utilizando un formato llamado AFRF. Se supone que los informes forenses contienen encabezados completos y cuerpos de mensajes, pero muchos reporteros eliminan o redactan alguna información debido a preocupaciones de privacidad. No obstante, el informe forense puede ser útil tanto para solucionar problemas de autenticación de nuestro propio dominio como para identificar, a partir de los URIs en los cuerpos de los mensajes, dominios y sitios web maliciosos utilizados para defraudar a los clientes del propietario de nuestro dominio.
La preparación para recibir estos informes implica primero crear dos buzones de correo en nuestro dominio para manejar estos informes, como agg_reports@ourdomain.com y afrf_reports@ourdomain.com. Note que esos nombres de buzón de correo son completamente arbitrarios y no hay requisitos para el nombramiento de la parte local del buzón de correo; somos libres de elegir cualquier nombre que deseemos, pero mantenerlos separados para facilitar el procesamiento.
Una vez que los nombres de los buzones de correo son seleccionados y creados en nuestro dominio, lo siguiente que hay que hacer aquí es implementar herramientas para leer estos buzones de correo y utilizar los datos, especialmente los informes de datos agregados, que nuevamente están diseñados para ser analizados por máquina, en lugar de ser leídos por un humano. Los informes forenses, por otro lado, podrían ser manejables simplemente leyéndolos nosotros mismos, pero nuestra capacidad para hacerlo dependerá tanto de la comprensión de nuestro cliente de correo acerca de cómo mostrar mensajes en el formato AFRF como del volumen de informes que recibamos.
Aunque es posible que escribamos nuestras propias herramientas para procesar informes DMARC, hasta que Bird proporcione esos servicios para los clientes de bird.com (algo que estamos considerando, pero aún no prometemos), recomendamos que utilicemos herramientas que ya están disponibles para la tarea.
Qué política de DMARC usar
La especificación DMARC ofrece tres opciones para que los propietarios de dominios especifiquen el tratamiento preferido para el correo que no pasa las verificaciones de validación DMARC. Son:
ninguno, lo que significa tratar el correo de la misma manera que se trataría independientemente de las verificaciones de validación DMARC
cuarentena, lo que significa aceptar el correo pero colocarlo en otro lugar que no sea la Bandeja de entrada del destinatario (generalmente la carpeta de spam)
rechazar, lo que significa rechazar el mensaje directamente
Es importante tener en cuenta que el propietario del dominio solo puede solicitar dicho tratamiento en su registro DMARC; depende del 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 poner el correo sólo en la carpeta de spam cuando la política del dominio es rechazar.
Recomendamos a todos nuestros clientes que lancen con una política de ninguno, simplemente para estar seguros. Aunque confiamos en nuestra capacidad para autenticar correctamente su correo a través de la firma DKIM, sigue siendo mejor tomarse un tiempo para examinar los informes sobre su dominio antes de volverse más agresivo con su política DMARC.
La especificación DMARC ofrece tres opciones para que los propietarios de dominios especifiquen el tratamiento preferido para el correo que no pasa las verificaciones de validación DMARC. Son:
ninguno, lo que significa tratar el correo de la misma manera que se trataría independientemente de las verificaciones de validación DMARC
cuarentena, lo que significa aceptar el correo pero colocarlo en otro lugar que no sea la Bandeja de entrada del destinatario (generalmente la carpeta de spam)
rechazar, lo que significa rechazar el mensaje directamente
Es importante tener en cuenta que el propietario del dominio solo puede solicitar dicho tratamiento en su registro DMARC; depende del 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 poner el correo sólo en la carpeta de spam cuando la política del dominio es rechazar.
Recomendamos a todos nuestros clientes que lancen con una política de ninguno, simplemente para estar seguros. Aunque confiamos en nuestra capacidad para autenticar correctamente su correo a través de la firma DKIM, sigue siendo mejor tomarse un tiempo para examinar los informes sobre su dominio antes de volverse más agresivo con su política DMARC.
La especificación DMARC ofrece tres opciones para que los propietarios de dominios especifiquen el tratamiento preferido para el correo que no pasa las verificaciones de validación DMARC. Son:
ninguno, lo que significa tratar el correo de la misma manera que se trataría independientemente de las verificaciones de validación DMARC
cuarentena, lo que significa aceptar el correo pero colocarlo en otro lugar que no sea la Bandeja de entrada del destinatario (generalmente la carpeta de spam)
rechazar, lo que significa rechazar el mensaje directamente
Es importante tener en cuenta que el propietario del dominio solo puede solicitar dicho tratamiento en su registro DMARC; depende del 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 poner el correo sólo en la carpeta de spam cuando la política del dominio es rechazar.
Recomendamos a todos nuestros clientes que lancen con una política de ninguno, simplemente para estar seguros. Aunque confiamos en nuestra capacidad para autenticar correctamente su correo a través de la firma DKIM, sigue siendo mejor tomarse un tiempo para examinar los informes sobre su dominio antes de volverse más agresivo con su política DMARC.
Publicar Your DMARC Policy
La política de DMARC de un dominio se anuncia mediante la publicación de un registro TXT de DNS en un lugar específico en el espacio de nombres DNS, a saber, “_dmarc.domainname.tld” (observe el guion bajo al principio). 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 de DMARC (1 es la única opción por ahora)
p=none especifica el tratamiento preferido, o política de 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 cual al 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 más bajo aquí para ver cómo soportan sus procesos de manejo de informes la carga.
Existen otras opciones de configuración disponibles para que un propietario de dominio use también en su registro de política DMARC, pero los consejos que hemos proporcionado deberían ser un buen comienzo.
La política de DMARC de un dominio se anuncia mediante la publicación de un registro TXT de DNS en un lugar específico en el espacio de nombres DNS, a saber, “_dmarc.domainname.tld” (observe el guion bajo al principio). 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 de DMARC (1 es la única opción por ahora)
p=none especifica el tratamiento preferido, o política de 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 cual al 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 más bajo aquí para ver cómo soportan sus procesos de manejo de informes la carga.
Existen otras opciones de configuración disponibles para que un propietario de dominio use también en su registro de política DMARC, pero los consejos que hemos proporcionado deberían ser un buen comienzo.
La política de DMARC de un dominio se anuncia mediante la publicación de un registro TXT de DNS en un lugar específico en el espacio de nombres DNS, a saber, “_dmarc.domainname.tld” (observe el guion bajo al principio). 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 de DMARC (1 es la única opción por ahora)
p=none especifica el tratamiento preferido, o política de 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 cual al 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 más bajo aquí para ver cómo soportan sus procesos de manejo de informes la carga.
Existen otras opciones de configuración disponibles para que un propietario de dominio use también en su registro de política DMARC, 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 la guía para crear un registro de política DMARC. También esperamos que nuestra explicación de por qué DMARC es importante ayude a aclarar por qué deberías comenzar a utilizar esta herramienta importante para proteger tu reputación de correo electrónico.
Por supuesto, este no es un documento completo o autoritativo 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 MessageBird está listo para ayudarte a configurar tu cuenta de MessageBird 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 la guía para crear un registro de política DMARC. También esperamos que nuestra explicación de por qué DMARC es importante ayude a aclarar por qué deberías comenzar a utilizar esta herramienta importante para proteger tu reputación de correo electrónico.
Por supuesto, este no es un documento completo o autoritativo 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 MessageBird está listo para ayudarte a configurar tu cuenta de MessageBird 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 la guía para crear un registro de política DMARC. También esperamos que nuestra explicación de por qué DMARC es importante ayude a aclarar por qué deberías comenzar a utilizar esta herramienta importante para proteger tu reputación de correo electrónico.
Por supuesto, este no es un documento completo o autoritativo 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 MessageBird está listo para ayudarte a configurar tu cuenta de MessageBird para DMARC también.
¡Gracias por leer—y comienza a proteger tus dominios con DMARC hoy!
