A lot of stuff has been flying around about DMARC. After discussing it with some of the folks that had a hand in creating it, I wrote a post to try and explain it in terms of what my clients may be thinking. It’s over here on the IBM Unica blog.

Hope it helps! The full text is also available after the fold.

Recently, a new standard was published, called DMARC. It has caused a lot of discussion and excitement, and people have been asking whether or not they need it.

In short, DMARC is an expansion on the existing DKIM and SPF specifications, designed to increase the effectiveness of anti-phishing programs. It standardizes the use of SPF and DKIM, allowing senders to experience a more consistent result of their authentication programs from ISPs that use DMARC, as mailbox providers will have a reliable set of guidelines on what to do with mail that fails authentication – bounce it, or spamfolder it.

Furthermore, DMARC allows a domain owner to request aggregated and anonymized data from ISPs about email that claims to be from their domain…and creates a way for mailbox providers to supply that data. This data provides some crucial insight into the severity of a given domain’s phishing problem, enabling its administrators to make decisions based on real data rather than informed guesswork. It also allows an entity to have insight into whether or not there is legitimate mail being sent without authentication from somewhere in its organization, which is valuable information.

DMARC allows its users to publish a policy that creates a single point of reference for receivers when deciding what to do about unsigned or badly signed mail. Until now, senders had to contact each ISP in turn and make an agreement as to what would be done in specific cases. DMARC allows the senders to specify their desires in a publishable policy, thus negating the necessity of the non-scaling “call the ISPs and organize what happens with each domain” dance.

This anti-phishing technique greatly simplifies a complex problem, removing a lot of the uncertainty for both senders and receivers, as well as for end-users, who will get exposed to less quantities of dangerous email because the ISPs have a much clearer directive regarding what to do with email that fails DKIM or SPF authentication.

Mike Adkins, one of the contributors in the creation of this new framework, wrote an excellent overview of DMARC, which you can find on the Facebook Engineering Blog.

Do you need it? It depends on what you’re expecting it to do. If you expect it to allow your mail to bypass spam filters – that is not what it will do, so if you’re looking for better inbox placement only, you don’t need it. All it does is give a greater level of confidence that the email is actually from where it claims to be from. If you have a phishing problem, want to tell receivers what to do with mail that claims to come from your domain, that is either not signed or is badly signed, or want feedback on how your authentication programs are working, you need it.

How do you set it up?

Implementation of DMARC is very similar to setting up SPF.  It consists of adding a TXT type DNS record for the domain that you use in the “From” field of your messages (not the Mail From or envelope from address).  So for example, if your messages come from “support@greenapple.com”, you would create a TXT type DNS entry for the following domain: 

_dmarc.greenapple.com

Here is an example DMARC entry:

_dmarc.greenapple.com  TXT  “v=DMARC1; p=none; rua=mailto:spoofreports@greenapple.com ruf=mailto:spoofreports@greenapple.com”

This entry would tell the receiver:  “for every message that fails authentication, don’t reject it, but do send reports of the spoofing to spoofreports@greenapple.com.”

If you want receivers to reject your mail, then you would use the policy attribute ‘p=reject’.

If you want receivers to not necessarily reject spoofed mail, but treat it with more suspicion, then you would use the policy attribute ‘p=quarantine’.

All three policy attribute values (none, reject, quarantine) result in reports getting sent to the addresses you specify with the “rua” and “ruf” attributes.  These reports will be sent in a new format AFRF, which is similar to ARF, so that you can build automated handling around it.

Many thanks to the people who put so much time and effort into making email safer!