-
-
Notifications
You must be signed in to change notification settings - Fork 23
Home
Welcome to the mail-dmarc wiki!
DMARC is used by email senders and email 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.
2013.04: google.com.
At present, google.com is the most commonly forged DMARC protected domain. Based on my log files, 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.