Welcome to the mail-dmarc wiki!
DMARC is a protocol for exchanging authentication information and policies among mail servers.
DMARC benefits domain owners by preventing others from impersonating them. A domain owner can reliably tell other mail servers that "it it doesn't originate from this list of servers (SPF) and it is not signed (DKIM), then reject it!" DMARC also provides domain owners with a means to receive feedback and determine that their policies are working as desired.
DMARC benefits mail server operators by providing them with an extremely reliable (as opposed to DKIM or SPF, which both have reliability issues when used independently) means to block forged emails. Is that message really from PayPal, Chase, Gmail, or Facebook? Since those organizations, and many more, publish DMARC policies, operators have a definitive means to know.
From the DMARC Draft: "DMARC operates as a policy layer atop DKIM and SPF. These technologies are the building blocks of DMARC as each is widely deployed, supported by mature tools, and is readily available to both senders and receivers. They are complementary, as each is resilient to many of the failure modes of the other."
For details on these steps, see Section 10 of the draft: Domain Owner Actions
1. Deploy DKIM & SPF 2. Ensure identifier alignment. 3. Publish a "monitor" record, ask for data reports 4. Roll policies from monitor to reject
1. install Mail::DMARC 2. process messages through DMARC a. With the [Qpsmtpd DMARC plugin](https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/dmarc) b. With a SpamAssassin rule? c. other ideas here...
DMARC is used by email senders and receivers, for different reasons:
Email senders use DMARC primarily to authenticate their identity to their clients. By publishing a DMARC policy, they can greatly diminish miscreants ability to forge their domain in emails. By preventing forged emails, they protect their brand as well as protecting their customers from phishing and other forms of email abuse.
Over the weekend that I wrote the DMARC plugin (Apr 20-21, 2013), I logged DMARC records published for these well known Email senders in a variety of industries:
Service providers: google.com, gmail.com, yahoo.com, icloud.com, me.com, mac.com, vzwshop.com, verizonwireless.com
Finance: paypal.com, chase.com, jpmchase.com, bofa.com, bankofamerica.com, aexp.com, quickbooks.com
E-commerce: amazon.com, ebay.com, itunes.com, apple.com, priceline.com, groupon.com, netflix.com
Social: facebookmail.com, twitter.com, linkedin.com, houzz.com, classmates.com, foursquare.com
Travel: delta.com, booking.com, travelzoo.com, smartertravel.com
Email receivers use DMARC primarily to block spam. Email receivers have a large arsenal of tools for identifying ham from spam (SpamAssassin, DKIM, SPF, dspam, GeoIP, p0f, DNSBL, FCrDNS, Early talker, mailbox validity, header validity, DomainKeys, virus scanners, and more). Sadly, few of these tools are 100% reliable. Certain offenses are worth disconnecting senders for (virus, blatant spam), but most are just not reliable enough to assure that if you block based on them, you won't lose legitimate mail.
DMARC is so close to 100% reliable that we can safely use it to reject invalid messages. Better still, we don't have to choose whether to reject an uncertain message, that choice is made by the domain owner the message is purportedly from. When a server implementing DMARC receives a message purportedly from google.com, we can do better than "from a Windows computer in Brazil at 3am, not very likely!" Google has published a policy that says, "if we didn't DKIM sign it, and it's not from this list of servers (SPF), then quarantine it."
I wrote this DMARC plugin because a handful of spammers in China were sending spam from my @tnpi.net domain. Despite having strict SPF records published, I was getting the bounces from well known mailers like Gmail and Yahoo. I learned of DMARC, hacked DKIM signing into my DKIM plugin, and published DMARC records. Within a day, I ceased getting bounce messages and instead get DMARC reports of the messages that Google, Yahoo, Microsoft, and AOL blocked on my behalf.
At present, google.com is the most commonly forged DMARC protected domain. Based on log files I've witnessed, nobody else comes close.
It seems that if I were at Google, and I were charged with reducing phishing and email abuse, the single greatest contribution they could make would be writing and publishing a set of milters, plugins, and patches for Sendmail, Postfix, and Qmail that implement SPF, DKIM, and DMARC in a unified sensible fashion.
Interestingly enough, several of the most popular brands are outsourcing their DMARC management (or perhaps more accurately, their "outbound email authentication") to agari.com and returnpath.net. The most technical companies (Google, Amazon) appear to be managing it themselves.
As of April 24, 2013, I have received DMARC reports from these organizations: google.com, Microsoft Corp., Yahoo! Inc., AOL, Comcast.net, linkedin.com, 163.com, and 127.com.
Mar 31, 2013 Draft: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
Mar 30, 2012 Draft: http://www.dmarc.org/draft-dmarc-base-00-02.txt