Hispanopedia WikiDMARC ( Autenticación, Informes y Conformidad de Mensajes Basados en Dominio ) es un protocolo de autenticación de correo electrónico . Está diseñado para que los propietarios de dominios de correo electrónico puedan protegerlos del uso no autorizado, comúnmente conocido como suplantación de identidad por correo electrónico . El objetivo principal de implementar DMARC es proteger un dominio contra ataques de compromiso de correo electrónico empresarial , correos electrónicos de phishing y estafas por correo electrónico .
Una vez publicada la entrada DNS DMARC , cualquier servidor de correo receptor puede autenticar el correo entrante según las instrucciones publicadas por el propietario del dominio en dicha entrada DNS. Si el correo supera la autenticación, se entregará y será de confianza. Si no supera la verificación, dependiendo de las instrucciones contenidas en el registro DMARC, el correo podría entregarse, ponerse en cuarentena o rechazarse.
DMARC amplía dos mecanismos de autenticación de correo electrónico existentes: Sender Policy Framework (SPF) y DomainKeys Identified Mail (DKIM). Permite al administrador de un dominio publicar una política en sus registros DNS para especificar cómo verificar el From:campo que se muestra a los usuarios finales y cómo el receptor debe gestionar los errores. Además, proporciona un mecanismo de informes para las acciones realizadas conforme a dichas políticas.
DMARC se define en el documento publicado por el Grupo de Trabajo de Ingeniería de Internet RFC 9989 , [ 1 ] de mayo de 2026, como "Vía de estándares". [ 2 ]
Descripción general
Una política DMARC permite que el dominio del remitente indique que sus mensajes de correo electrónico están protegidos por SPF y/o DKIM, e indica al receptor qué hacer si ninguno de estos métodos de autenticación funciona, como rechazar el mensaje o ponerlo en cuarentena. La política también puede especificar cómo el receptor puede informar al dominio del remitente sobre los mensajes que se autentican correctamente o que no. [ 3 ]
Estas políticas se publican en el Sistema de Nombres de Dominio (DNS) público como registros de texto TXT .
DMARC no determina directamente si un correo electrónico es spam o fraudulento. En cambio, DMARC puede requerir que un mensaje no solo pase la validación DKIM o SPF, sino que también pase la alineación . Según DMARC, un mensaje puede fallar incluso si pasa SPF o DKIM pero falla la alineación. [ 4 ]
Configurar DMARC puede mejorar la entregabilidad de los mensajes de remitentes legítimos. [ 5 ]
Alineación
DMARC funciona comprobando que el dominio en el From:campo del mensaje (también llamado "RFC5322.From" [ 2 ] ) esté "alineado" con otros nombres de dominio autenticados. Si las comprobaciones de alineación SPF (especificada mediante el aspfcampo) o DKIM (especificada mediante el adkimcampo) se superan, entonces la prueba de alineación DMARC se supera.
La alineación puede especificarse como estricta o flexible. Para una alineación estricta, los nombres de dominio deben ser idénticos. Para una alineación flexible, el dominio organizacional de nivel superior debe coincidir. El dominio organizacional solía encontrarse consultando una lista de sufijos DNS públicos. La próxima especificación, en cambio, especifica un recorrido de árbol a través de los dominios principales. Así, por ejemplo, "abcdexample.com.au" y "example.com.au" tienen el mismo dominio organizacional, porque _dmarc.example.com.au es el único registro DMARC definido entre todos los subdominios involucrados, incluido _dmarc.au. Dado que esto permite a los propietarios de dominios definir roles de dominio, se considera más preciso que la lista de sufijos públicos . [ 6 ]
Al igual que SPF y DKIM, DMARC utiliza el concepto de propietario de dominio, es decir, la entidad o entidades autorizadas para realizar cambios en un dominio DNS determinado.
SPF verifica que la dirección IP del servidor remitente esté autorizada por el propietario del dominio que aparece en el MAIL FROMcomando SMTP. (La dirección de correo electrónico en MAIL FROM también se denomina dirección de rebote , remitente del sobre o RFC5321.MailFrom). Además de requerir que la verificación SPF sea exitosa, DMARC verifica que RFC5321.MailFrom se alinee con 5322.From. [ 2 ]
DKIM permite firmar criptográficamente partes de un mensaje de correo electrónico, y la firma debe cubrir el campo "De". Dentro del encabezado de correo DKIM-Signature, las etiquetas d=(dominio) y s=(selector) especifican dónde recuperar la clave pública para la firma en el DNS. Una firma válida demuestra que el firmante es el propietario del dominio y que el campo "De" no se ha modificado desde que se aplicó la firma. Puede haber varias firmas DKIM en un mensaje de correo electrónico; DMARC requiere una firma válida donde el dominio en la d=etiqueta coincida con el dominio del remitente indicado en el From:campo de encabezado.
registro DNS
Los registros DMARC se publican en DNS con una etiqueta de subdominio _dmarc, por ejemplo _dmarc.example.com. Compárelo con SPF en example.comy DKIM en selector._domainkey.example.com.
El contenido del registro de recursos TXT consta de name=valueetiquetas, separadas por punto y coma, similares a SPF y DKIM.
Las etiquetas disponibles son: [ 7 ]
- adkim , modo de alineación DKIM (predeterminado
rpara relajado, alternativamentespara estricto) - aspf , modo de alineación SPF (predeterminado
rpara relajado, alternativamentespara estricto) - fo , opciones de informe de fallos (predeterminado
0, alternativamente1,dos) - p , política (ver más abajo),
- pct , porcentaje de correos electrónicos "malos" sobre los que se aplicará la política (predeterminado
100) - rf , formato para informes de fallos específicos de mensajes
- ri , intervalo solicitado entre informes agregados
- rua , URI a la que enviar informes agregados
- ruf , URI a la que enviar informes de fallos/forenses
- sp , política de subdominio (por defecto igual que
p), - v , versión,
Por ejemplo:
"v=DMARC1;p=ninguno;sp=cuarentena;pct=100;rua=mailto:dmarcreports@example.com;"En este ejemplo, la entidad que controla el dominio DNS example.com pretende monitorizar las tasas de fallos de SPF y/o DKIM y no espera que se envíen correos electrónicos desde subdominios de example.com. Cabe destacar que un subdominio puede publicar su propio registro DMARC; los destinatarios deben consultarlo antes de recurrir al registro del dominio de la organización.
Adopción paso a paso
El protocolo prevé varios estados de transición para permitir a los administradores de correo electrónico pasar gradualmente de no implementar DMARC en absoluto a una configuración inflexible. [ 8 ] [ 9 ] [ 10 ] El concepto de adopción gradual presupone que el objetivo de DMARC es la configuración más estricta, lo cual no se cumple en todos los dominios. Independientemente de la intención, estos mecanismos permiten una mayor flexibilidad.
Política
En primer lugar, existen tres políticas:
- Esta es la política básica. Los receptores no requieren ningún trato especial, pero permite que un dominio reciba informes de retroalimentación.
- La cuarentena exige a los receptores que traten con recelo los mensajes que no superen la verificación DMARC. Los distintos receptores disponen de diferentes métodos para implementarlo, como marcar los mensajes o enviarlos a la carpeta de correo no deseado.
- La opción "rechazar" solicita a los receptores que rechacen directamente los mensajes que no superen la comprobación DMARC.
La política publicada puede mitigarse aplicándola solo a un porcentaje de los mensajes que no superan la verificación DMARC. Se solicita a los receptores que seleccionen el porcentaje de mensajes especificado mediante un sencillo algoritmo de muestreo de Bernoulli . El resto de los mensajes deben someterse a la política menos restrictiva; es decir, ninguna si p=quarantine, cuarentena si p=reject. Si no se especifica, pct toma por defecto el 100 % de los mensajes. Este caso p=quarantine; pct=0;se utiliza para obligar a los administradores de listas de correo a reescribir el campo From:, ya que algunos no lo hacen cuando p=none. [ 11 ]
Finalmente, la política de subdominios sp=y la política sin dominio recientemente añadida, np=[ 12 ] permiten ajustar la política para subdominios específicos.
Informes
DMARC es capaz de generar dos tipos de informes distintos. Los informes agregados se envían a la dirección especificada después de la etiqueta rua. Los informes forenses se envían por correo electrónico a la dirección que sigue a la rufetiqueta. Estas direcciones de correo electrónico deben especificarse en formato URI mailto (por ejemplo, mailto:worker@example.net ). Se admiten varias direcciones de informe, cada una de las cuales debe estar en formato URI completo, separada por una coma. [ 13 ]
Las direcciones de correo electrónico objetivo pueden pertenecer a dominios externos. En ese caso, el dominio objetivo debe configurar un registro DMARC para indicar que acepta recibirlas; de lo contrario, sería posible explotar la notificación para amplificar el spam . Por ejemplo, supongamos que receiver.examplerecibe un mensaje de correo electrónico From: someone@sender.exampley desea denunciarlo. Si encuentra ruf=mailto:some-id@thirdparty.example, busca un registro DNS de confirmación en el espacio de nombres administrado por el objetivo, como este:
sender.example._report._dmarc.thirdparty.example EN TXT "v=DMARC1;"Informes agregados
Los informes agregados se envían como archivos XML , normalmente una vez al día. El asunto menciona el "Dominio del informe", que indica el nombre de dominio DNS sobre el que se generó el informe, y el "Remitente", que es la entidad que emite el informe. La carga útil se encuentra en un archivo adjunto con un nombre de archivo largo que consta de elementos separados por signos de exclamación, como el receptor que emite el informe, las épocas de inicio y fin del período informado como marcas de tiempo de estilo Unix, un identificador único opcional y una extensión que depende de la posible compresión (antes era .zip). [ 14 ]
Por ejemplo: example.com!example.org!1475712000!1475798400.xml.gz.
El contenido XML consta de una cabecera que contiene la política en la que se basa el informe y los metadatos del mismo, seguida de varios registros. Los registros se pueden almacenar en una base de datos como una relación y visualizarse en formato tabular. El esquema XML se define en el Apéndice C de las especificaciones [ 15 ] y se muestra un ejemplo de registro sin procesar en dmarc.org [ 16 ] . Aquí nos centramos en un ejemplo relacional, que transmite mejor la naturaleza de los datos. Los registros DMARC también se pueden transformar directamente en HTML aplicando una hoja de estilo XSL .
Las filas se agrupan por IP de origen y resultados de autenticación, pasando solo el recuento de cada grupo. Las columnas de resultados más a la izquierda, etiquetadas como SPF y DKIM, muestran los resultados de DMARC, ya sea aprobado o reprobado, teniendo en cuenta la alineación. Las de la derecha, con etiquetas similares, muestran el nombre del dominio que afirma participar en el envío del mensaje y (entre paréntesis) el estado de autenticación de esa afirmación según el protocolo original, SPF o DKIM, independientemente de la alineación del identificador. En el lado derecho, SPF puede aparecer como máximo dos veces, una para la Return-Path:prueba y otra para la HELOprueba; DKIM puede aparecer una vez por cada firma presente en el mensaje. En el ejemplo, la primera fila representa el flujo de correo principal de example.org, y la segunda fila es un fallo de DKIM, como una rotura de firma debido a una alteración menor en tránsito. La tercera y cuarta filas muestran modos de fallo típicos de un reenviador y una lista de correo, respectivamente. La autenticación DMARC falló solo para la última fila; Podría haber afectado al estado del mensaje si example.org hubiera especificado una política estricta.
La disposición refleja la política publicada que se aplicó realmente a los mensajes: ninguna , cuarentena o rechazo . Además, aunque no se muestra en la tabla, DMARC permite la anulación de la política. La especificación ya contempla algunas razones por las que un receptor puede aplicar una política diferente a la solicitada:
- reenviado
- mientras se mantiene la misma dirección de rebote, normalmente no rompe DKIM,
- muestreado
- porque un remitente puede optar por aplicar la política solo a un porcentaje de mensajes,
- reenviador de confianza
- El mensaje llegó de una fuente conocida localmente.
- lista de correo
- El receptor determinó heurísticamente que el mensaje provenía de una lista de correo,
- política local
- Obviamente, los receptores son libres de aplicar la política que deseen, simplemente es bueno que los remitentes lo sepan.
- otro
- Si ninguna de las opciones anteriores aplica, un campo de comentarios permite agregar más información.
Informes de fallos
Los informes de fallos, también conocidos como informes forenses, se generan en tiempo real y consisten en copias, posiblemente censuradas, de mensajes individuales que no superaron las pruebas SPF, DKIM o ambas, según el valor especificado en la foetiqueta. Su formato, una extensión del formato de informes de abuso , se asemeja al de los rebotes habituales, ya que contienen un encabezado "message/rfc822" o "text/rfc822-headers".
Los informes forenses también contienen lo siguiente:
- Dirección IP de origen (remitente del mensaje)
- Puerto de origen (según RFC 6692)
- Desde la dirección de correo electrónico
- Dirección de correo electrónico del destinatario
- línea de asunto del correo electrónico
- Resultados de la autenticación SPF y DKIM
- Hora recibida
- Encabezados de mensajes de correo electrónico que incluyen el host remitente, el ID del mensaje de correo electrónico, la firma DKIM y cualquier otra información de encabezado personalizada. [ 17 ]
Compatibilidad
Transitarios
Existen varios tipos diferentes de reenvío de correo electrónico , algunos de los cuales pueden romper SPF. [ 18 ] Esta es una de las razones por las que el reenvío de correo electrónico puede afectar los resultados de la autenticación DMARC. [ 19 ]
Listas de correo
Las listas de correo son una causa frecuente de rupturas legítimas de la firma DKIM del dominio del autor original, por ejemplo, al agregar un prefijo al encabezado del asunto. Existen varias soluciones alternativas, [ 20 ] [ 21 ] y los paquetes de software para listas de correo están trabajando en soluciones. [ 22 ]
Desactivar todas las modificaciones de mensajes
Esta solución alternativa mantiene el flujo de trabajo estándar de las listas de correo y es adoptada por varios operadores de listas de correo importantes, pero impide que la lista agregue pies de página y prefijos de asunto. [ 23 ] Esto requiere una configuración cuidadosa del software de correo para garantizar que los encabezados firmados no se reordenen ni se modifiquen. Un servidor de correo electrónico mal configurado puede incluir el ID de la lista en su DKIM de los mensajes enviados a una lista de correo, y entonces el operador de la lista se ve obligado a rechazarlo o a reescribir el campo From:.
From:reescritura
Una de las soluciones alternativas más populares y menos intrusivas consiste en reescribir el From:campo de encabezado. La dirección del autor original se puede agregar al Reply-To:campo. [ 24 ] La reescritura puede abarcar desde simplemente agregar .INVALID[ nota 1 ] al nombre de dominio, hasta asignar un ID de usuario temporal donde se utiliza una versión modificada de la dirección del usuario, o se utiliza un ID opaco, lo que mantiene privada la dirección de correo electrónico "real" del usuario para la lista. Además, se puede cambiar el nombre para mostrar para que muestre tanto al autor como a la lista (o al operador de la lista). [ 25 ] Estos ejemplos darían como resultado, respectivamente, uno de los siguientes:
De: John Doe <user@example.com.INVALID> De: John Doe <user@example.com.dmarc.fail> De: John Doe <243576@mailinglist.example.org> De: John Doe vía MailingList <list@mailinglist.example.org> Responder a: John Doe <user@example.com>La última línea Reply-To:debe diseñarse para dar cabida a la funcionalidad de respuesta al autor, en cuyo caso la funcionalidad de respuesta a la lista queda cubierta por el cambio anterior en el From:campo de encabezado. De esta forma, se invierte el significado original de esos campos.
Modificar el autor no es justo en general y puede romper la relación esperada entre el significado y la apariencia de ese dato. También interrumpe su uso automatizado. Hay comunidades que utilizan listas de correo para coordinar su trabajo y emplean herramientas que utilizan este From:campo para atribuir la autoría a los archivos adjuntos. [ 26 ]
Otras soluciones alternativas
El encapsulado del mensaje funciona bien para quienes usan un cliente de correo electrónico que lo entienda. No hacer ningún cambio es quizás la solución más obvia, salvo que parecen ser obligatorios por ley en algunos países, y que perder la autenticación SPF de forma rutinaria puede hacer que la autenticación general sea más frágil. [ 27 ]
Campo del remitente
Modificar el From:campo de encabezado para cumplir con la alineación DKIM puede provocar que el mensaje incumpla con la sección 3.6.2 de la RFC 5322 : «El campo "De:" especifica el/los autor/es del mensaje, es decir, el/los buzón/es de correo de la/s persona/s o sistema/s responsable/s de la redacción del mensaje». El buzón se refiere a la dirección de correo electrónico del autor. El Sender:encabezado está disponible para indicar que un correo electrónico se envió en nombre de otra parte, pero DMARC solo verifica la política para el dominio "De" e ignora el dominio "Remitente". [ nota 2 ]
Tanto ADSP como DMARC [ 4 ] rechazan el uso del campo Sender por razones no técnicas, ya que muchos agentes de usuario no lo muestran al destinatario.
Historia
Se ha mantenido un borrador de especificación DMARC desde el 30 de enero de 2012. [ 28 ]
En octubre de 2013, se lanzó GNU Mailmanp=reject 2.1.16 con opciones para manejar publicaciones de un dominio con la política DMARC de . [ 22 ] El cambio intentó anticipar los problemas de interoperabilidad esperados en caso de que se aplicaran políticas restrictivas a dominios con usuarios humanos (a diferencia de los dominios de correo puramente transaccionales).
En abril de 2014, Yahoo cambió su política DMARC a p=reject, lo que provocó un comportamiento inadecuado en varias listas de correo. [ 29 ] [ 30 ] Unos días después, AOL también cambió su política DMARC a p=reject. [ 31 ] Estos cambios provocaron una cantidad significativa de interrupciones, y estos proveedores de correo han sido acusados de trasladar los costos de sus propios fallos de seguridad a terceros. [ 32 ] A partir de 2020, las preguntas frecuentes en la wiki oficial de DMARC contienen varias sugerencias para que las listas de correo manejen mensajes de un dominio con una política DMARC estricta, [ 33 ] de las cuales la más implementada es que la lista de correo cambie el encabezado "From" a una dirección en su propio dominio.
En agosto de 2014 se formó un grupo de trabajo del IETF para abordar los problemas de DMARC, comenzando por las preocupaciones sobre la interoperabilidad y posiblemente continuando con una especificación y documentación estándar revisadas. [ 34 ] Mientras tanto, la especificación DMARC existente había alcanzado un estado editorial acordado e implementado por muchos. Se publicó en marzo de 2015 en el flujo de envío independiente en la categoría "Informativa" (no estándar) como RFC 7489. [ 35 ]
En marzo de 2017, la Comisión Federal de Comercio publicó un estudio sobre el uso de DMARC por parte de las empresas. [ 36 ] De 569 empresas, el estudio encontró que aproximadamente un tercio implementó alguna configuración de DMARC, menos del 10% usó DMARC para instruir a los servidores a rechazar mensajes no autenticados y la mayoría había implementado SPF.
En mayo de 2026 se publicó una versión actualizada del RFC 9989.
Colaboradores
Los colaboradores de la especificación DMARC incluyen: [ 37 ] [ 38 ]
- Receptores: AOL , Comcast , Google ( Gmail ), Mail.Ru , Microsoft ( Outlook.com , Hotmail ), [ 39 ] Netease (163.com, 126.com, 188.com, yeah.net), XS4ALL , Yahoo , Yandex
- Remitentes: American Greetings , Bank of America , Facebook , Fidelity Investments , JPMorganChase , LinkedIn , [ 40 ] PayPal , Twitter [ 41 ]
- Intermediarios y proveedores: [ 42 ] Agari (Fundador/CEO Patrick R. Peterson), [ 42 ] Cloudmark, [ 42 ] Red Sift , [ 42 ] ReturnPath , [ 42 ] Trusted Domain Project , [ 42 ] ProDMARC , [ 42 ]
Servicios comerciales
Entre los servicios populares que realizan análisis DMARC y/o validación de registros se incluyen Red Sift, Valimail, dmarcian , DMARC Advisor , EasyDmarc y Cloudflare . [ 43 ]
Véase también
- Cadena de recepción autenticada (ARC)
- Prácticas de firma de dominio del autor
- Indicadores de marca para la identificación de mensajes (BIMI)
- Correo identificado por DomainKeys (DKIM)
- Autenticación de correo electrónico
- Correo electrónico certificado
- Servidores de correo con DMARC
- Marco de políticas del remitente (SPF)
Notas
Referencias
- ↑ RFC 9989
- 1 2 3 T. Herr; J. Levine (20 de mayo de 2026). Autenticación, informes y conformidad de mensajes basados en dominio (DMARC) . IETF . doi : 10.17487/RFC9989 . RFC 9989 .
- ↑ Terry Zink (27 de septiembre de 2016). "Cómo migramos microsoft.com al registro DMARC ap=quarantine" . Blog de MSDN .
Si eso suena a mucho trabajo, es porque lo fue.
- 1 2 Kucherawy, M. ; Zwicky, E. (15 de julio de 2013). "Autenticación, informes y conformidad de mensajes basados en dominio (DMARC) [ borrador 01 ] " . IETF. Apéndice A.3, Campo de encabezado del remitente . Recuperado el 24 de mayo de 2016 .
- ↑ "Directrices para remitentes masivos – Ayuda de Gmail" . support.google.com . Consultado el 24 de abril de 2015 .
- ↑ Dave Crocker (24 de noviembre de 2020). "Hacer un paseo por los árboles en lugar de una búsqueda en PSL" . dmarc-ietf (Lista de correo).
- ↑ RFC 9989 . IETF . sec. 4.7. doi : 10.17487/RFC9989 .
- ↑ "Tutorial: Implementación recomendada de DMARC" . google.com .
- ↑ "Guía de implementación: Protección de dominios de correo electrónico" . cyber.gc.ca . 12 de agosto de 2021.
- ↑ "Guía del usuario de Cisco Domain Protection" (PDF) . cisco.com . 25 de mayo de 2021.
- ^ Jonathan Kamens (9 de octubre de 2018). ""p=ninguno" frente a "p=cuarentena; pct=0"" (Lista de correo).
- ↑ Scott Kitterman (26 de julio de 2021). Tim Wicinski (ed.). Extensión experimental de autenticación, informes y conformidad de mensajes basada en dominios (DMARC) para dominios de sufijo públicos . IETF . doi : 10.17487/RFC9091 . RFC 9091 .
- ↑ "RUA vs RUF: Explicación de los diferentes tipos de informes DMARC" . Progist.net . 14 de diciembre de 2023. Consultado el 14 de diciembre de 2023 .
- ↑ "¿Cuál es la razón para elegir ZIP para los informes agregados?" . DMARC.org . 2012 . Consultado el 3 de abril de 2019 .
Una vez que GZIP se registre como un tipo de aplicación MIME con IANA, el grupo DMARC considerará su inclusión en el borrador
- ↑ Murray S. Kucherawy ; Elizabeth Zwicky, eds. (marzo de 2015). "Esquema XML DMARC" . Autenticación, informes y conformidad de mensajes basados en dominio (DMARC) . IETF . sec. C. doi : 10.17487/RFC7489 . RFC 7489. Consultado el 3 de marzo de 2019 .
- ↑ "Necesito implementar informes agregados, ¿cómo son?" . DMARC.org . Consultado el 26 de mayo de 2016 .
- ↑ "La guía definitiva para la presentación de informes DMARC en 2022" . 23 de agosto de 2019.
- ↑ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (septiembre de 2016). "Alias" . Problemas de interoperabilidad entre la autenticación, la notificación y la conformidad de mensajes basados en dominio (DMARC) y los flujos de correo electrónico indirectos . IETF . sec. 3.2.1. doi : 10.17487/RFC7960 . RFC 7960. Consultado el 14 de marzo de 2017 .
- ↑ "¿Cómo afecta el reenvío de correo electrónico a los resultados de la autenticación DMARC?" . progist.net . 6 de enero de 2023.
- ↑ Grupo de Investigación Anti-Spam . "Mitigación de los daños causados por DMARC al correo de terceros" .
- ↑ wiki de dmarc.org
- 1 2 Mark Sapiro (16 de octubre de 2013). "Mailman y DMARC" . list.org . Consultado el 13 de agosto de 2015 .
- ↑ "Próximos cambios para lists.debian.org" . lists.debian.org .
- ↑ Al Iverson (9 de abril de 2014). "Spam Resource: ¿Administras una lista de correo electrónico para discusiones? Aquí te explicamos cómo lidiar con DMARC" . spamresource.com . Consultado el 18 de abril de 2014 .
- ↑ "Cómo Threadable resolvió el problema de DMARC" . Blog de Threadable . Consultado el 21 de mayo de 2016 .
- ↑ Theodore Ts'o (18 de diciembre de 2016). "Respuestas realistas a DMARC" . IETF-Discussion (Lista de correo) . Recuperado el 14 de marzo de 2017.
El hecho de que el campo "from" no se reescriba es IMPORTANTE porque reescribir el campo "from" rompería el comando "git am", ya que utiliza el campo "From:" para completar el campo "
from" del commit de
Git .
- ↑ John Levine (31 de mayo de 2014). "Mitigación de los daños de DMARC al correo de terceros" . wiki . ASRG . Consultado el 1 de junio de 2014 .
- ↑ "Historia" , dmarc.org
- ↑ Lucian Constantin (8 de abril de 2014). "La política anti-suplantación de correo electrónico de Yahoo rompe las listas de correo" . PC World . Consultado el 15 de abril de 2014 .
- ↑ Laura Atkins (12 de abril de 2014). "Declaración de Yahoo sobre la política DMARC" . wordtothewise.com.
- ↑ Vishwanath Subramanian (22 de abril de 2014). "AOL Mail actualiza su política DMARC para 'rechazar'" . AOL . Archivado del original el 13 de agosto de 2015 . Recuperado el 13 de agosto de 2015 .
- ↑ John Levine (13 de agosto de 2016). "DMARC e ietf.org" . IETF (Lista de correo) . Consultado el 10 de octubre de 2016 .
- ^ "Preguntas frecuentes en la wiki de DMARC" . Consultado el 15 de julio de 2020 .
- ↑ "Acción del Grupo de Trabajo: Autenticación, Informes y Conformidad de Mensajes Basados en Dominios Formados (dmarc)" . IETF-Announce (Lista de correo). 11 de agosto de 2014. Consultado el 10 de octubre de 2016 .
- ↑ "Preguntas frecuentes sobre DMARC" . dmarc.org .
- ↑ "Las empresas pueden ayudar a detener el phishing y proteger sus marcas mediante la autenticación de correo electrónico" (PDF) . Comisión Federal de Comercio. 3 de marzo de 2017.
- ↑ Kucherawy, Murray; Zwicky, Elizabeth. "Agradecimientos" . Autenticación, informes y conformidad de mensajes basados en dominio (DMARC) . IETF . sec. E. ID draft-kucherawy-dmarc-base-01.
- ↑ Colaboradores de DMARC (PDF)
- ↑ Vitaldevara, Krish (10 de diciembre de 2012). "Outlook.com aumenta la seguridad con soporte para certificados DMARC y EV" . Blog de Outlook . Microsoft . Consultado el 12 de diciembre de 2012 .
- ↑ Martin, Franck (20 de septiembre de 2012). "DMARC: una nueva herramienta para detectar correos electrónicos auténticos" . Blog de ingeniería de LinkedIn . LinkedIn . Consultado el 17 de agosto de 2013 .
- ↑ Josh Aberant (21 de febrero de 2013). "Presentación de DMARC para correos electrónicos de Twitter.com" . twitter.com . Consultado el 10 de abril de 2014 .
- 1 2 3 4 5 6 7 "Historia – dmarc.org" . dmarc.org . Consultado el 23 de septiembre de 2020 .
- ↑ Hureau, Olivier; Bayer, Jan; Duda, Andrzej; Korczyński, Maciej (2024). Richter, Philipp; Bajpai, Vaibhav; Carisimo, Esteban (eds.). «Correos electrónicos falsificados: un análisis de los problemas que dificultan una mayor implementación de DMARC» . Medición pasiva y activa . Cham: Springer Nature Suiza: 232–261 . doi : 10.1007/978-3-031-56249-5_10 . ISBN 978-3-031-56249-5.
Enlaces externos
- Sitio web oficial
- Wiki del Grupo de Investigación Anti-Spam: Cómo mitigar los daños de DMARC al correo de terceros
- Autenticación de correo electrónico
- Antispam
