Lately, the question of DANE vs DMARC has been coming up quite a bit. While both DANE and DMARC involve “authentication”, there are significantly different things meant by each. Let’s start by addressing the underlying technologies.
DANE, or RFC6698, is intended to mitigate the threat of a man-in-the-middle intercepting encrypted communications by posing as one of the end points. A common vector to compromise is poisoning DNS results so that email that is intended to be sent securely from Alice to Bob is instead sent to Mallory because she has convinced Alice’s email server that she is, in fact, the proper recipient for email intended for Bob. DANE prevents Mallory from this type of man-in-the-middle by giving Alice a method, secured using DNSSEC, to ensure that she only sends messages to Bob if the key provided by Bob’s mail exchanger matches the key he has authorized in DNS to receive mail for his domain. (See “1” in the diagram below.)
DMARC, or RFC7489, is intended to mitigate the threat of an arbitrary sender (in the example below, Sybil), mimicking Alice’s email sending domain to send completely fabricated, fraudulent traffic to Bob, claiming to originate from Alice. This type of compromise is extremely simple to perpetrate: the underlying SMTP protocol was never designed with authentication of senders in mind. Sybil, or anyone else, can simply connect to Bob’s mail server and send him email purporting to come from the sending domain of Alice, Carol, Carlos, Charlie, Chuck, Craig, Dan or Dave. DMARC prevents this type of malicious activity by giving Bob’s mail server a method to verify that the sender is in fact authorized - either via a cryptographic signature using DKIM or via an IP ACL using SPF - to send from a given identity and reject messages if authorization cannot be proven. (See “2” in the diagram below.)
In addition, DMARC can prevent the replay of modified legitimate messages. For example, if Mallory intercepts a message and maliciously replaces part of the contents - say a legitimate logon URL with a phishing URL - DMARC can prevent acceptance of the message. The same goes for Sybil if she takes a message - say a legitimate notification from her bank - and attempts to deliver a modified version of it to Bob. (See “3” in the diagram below.)
While these two technologies are clearly complementary, neither can replace the other. DANE ensures the sender that the correct recipient receives communications and that they are correctly encrypted in transit. DMARC ensures the recipient that communications truly originate from the claimed sender or an authorized third party for that sender.
If you’d like to learn more about DANE, then this DANE mailing list is really useful. And if you’re interested in learning more about DMARC, there are a couple of options. You can check out this DMARC mailing list and this DMARC discussion list.
