At Groupon we are a global company sending email in 47 countries worldwide. Our mission is to connect our customers with our merchant partners through price and discovery using email as one of the communication channels. Given the global reach and strength of our brand “bad actors” have attempted to misuse our brand and email domains through phishing activity to trick unsuspecting users into providing sensitive personal information. As such we began the work to implement Domain-based Message Authentication, Reporting & Conformance policies, or DMARC for short, globally to combat these “bad actors.”
DMARC is a policy-reporting layer built on top of standard email authentication protocols known as Sender Policy Framework (SPF) & Domain Keys Identified Mail (DKIM). At a high level SPF allows receiving email servers to check whether email from a domain is sent using approved infrastructure or IPs. DKIM applies similar concepts at the domain level but uses a private/public key pair to validate pre-defined portions of the email message from the domain in question. From an execution level SPF and DKIM both rely on DNS lookups to function correctly.
At Groupon SPF and DKIM are standard authentication protocols used in every country we operate. As such we took the next step to implement DMARC around the world in an effort to fight phishing and create a feedback loop for how our email domains are utilized in the wild. DMARC operates through a DNS record where we are able to tell participating email providers like Gmail, Hotmail, and Yahoo to take specific policy actions (none, quarantine, reject) for email failing SPF & DKIM.
When declaring a policy of “none”, defined as “p=none” in the below example, we are instructing the participating email providers to take no action with messages failing authentication. Even though no action is taken we still receive reports on how email is passing or failing authentication from those providers. The reports are sent to the email addresses defined below in the “rua=” and “ruf=” sections. The “rua” option refers to an aggregate report of failures. It can be thought of as a high level aggregate failure report. The “ruf” option is the more detailed reporting path, providing significantly more and detailed forensic reports for every failure. At Groupon we work with Agari, an email security company, to compile this data into human readable reports, which support our DMARC work globally. Overall, the “p=none” step is key in our DMARC rollout process as we use this data to create a baseline for authentication performance and ensure we are in a position to not block legitimate email when we choose to enforce a “quarantine” or “reject” policy.
v=DMARC1; p=none; fo=1; rua=mailto:email@example.com; ruf=mailto:firstname.lastname@example.org; rf=afrf; pct=100
After a complete and thorough audit at the “p=none” stage we move to publishing a “quarantine policy”, defined as “p=quarantine” in the below example. When declaring a quarantine policy we are instructing email providers to send any email failing SPF & DKIM to spam, which quarantines the email outside the users’ inboxes. It is at this stage that we take advantage of the “pct” feature. This gives us the ability to inform email providers about the percentage of email failing authentication to quarantine. At Groupon we found that anything less than 50% does not provide a significant enough sample size to analyze the data for when to move to publishing a “reject policy.”
v=DMARC1; p=quarantine; fo=1; rua=mailto:email@example.com; ruf=mailto:firstname.lastname@example.org; rf=afrf; pct=50
Once any remaining issues have been corrected at the quarantine stage we publish a “reject policy”, which is represented as “p=reject” in the below example. Publishing a “reject policy” instructs any participating email providers to block all email failing authentication from reaching the inbox or spam folder. As a practice at Groupon when we reach this stage we leave the “pct” option set to 100, which instructs participating email providers to block 100% of all email failing authentication. This is done to take full advantage of the anti-phishing benefits DMARC provides and is possible due to the work completed to ensure no legitimate email is blocked by accident.
Throughout the DMARC process we have alerts set to trigger if any failures on legitimate email exceed our internal thresholds. These alerts take center stage when we reach the “reject” phase. If our pre-defined thresholds are met, it initiates a rollback of DMARC policies from “quarantine” or “reject” to “none” in the effected region to ensure email is not inadvertently blocked.
v=DMARC1; p=reject; fo=1; rua=mailto:email@example.com; ruf=mailto:firstname.lastname@example.org; rf=afrf; pct=100
We follow the process of moving incrementally from a policy of “none” to “quarantine” and eventually “reject” to make changes in a controlled fashion. A staged rollout allows us to adjust the process as needed by responding to what the data highlights as our action items at each phase. This provides the opportunity to complete our due diligence while minimizing the overall risk of blocking legitimate email to our subscribers. I am happy to report that we are enforcing DMARC policies in 45 countries with 43 countries publishing a “reject policy.”
The implications of being able to globally reject phishing emails that are targeting our subscribers and brand are enormous. Recently in Brazil we tracked a phishing campaign offering discount iPhones in an attempt to steal credit card information. (screenshot below)
Due to our use of DMARC and the stellar implementation by my team in South America we were already publishing a “reject policy” for our mailing domain in Brazil, r.grouponmail.com.br. As a result we were able to proactively block around 50,000 phishing emails targeting Gmail, Hotmail, and Yahoo! addresses, which added another layer of protection for our subscribers. (data below)
We will continue to roll out DMARC through the remaining countries to ensure our subscribers are able to benefit from the anti-phishing protection they deserve. Once the process is completed all Groupon email operations will be covered by DMARC. For Game of Thrones fans, DMARC can be thought of as a member of the Night’s Watch, silently standing guard on The Wall. DMARC protects the Groupon realm from phishing attempts and keeps our subscribers and brand safe in the process.