DMARC at Groupon

at December 17th, 2014

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:example@example.com; ruf=mailto:example@example.com; 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:example@example.com; ruf=mailto:example@example.com; 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:example@example.com; ruf=mailto:example@example.com; 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)

phishing_example

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)

Data

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.


6 thoughts on “DMARC at Groupon

  1. A good thing! It is still challenging to educate users about 'how to identify legitimate email sent by brand'. For example a user can send email with a different sender(e.g grouponholidayoffers.com) not with groupon.com I think groupon has different senders for each country/region, it becomes more tricky! A special friendly campaign(that tells the customer which sender to trust!) can be helpful if shown to the users e.g via email(landing pages), inside message center and other sections of the site.

    by Alam on December 19, 2014 at 3:47 am
  2. Great point! That is why we default to starting with a DMARC record of "p=none" on all domains. At a minimum this provides the data needed to understand how domains are used in the wild.

    by Ryan Boyd on December 19, 2014 at 11:17 am
  3. How do I report a phishing email? Tom

    by Tom Beckman on March 24, 2015 at 5:33 pm
  4. @Tom, you can send information regarding phishing to security@groupon.com. Thanks!

    by Kyle O on May 5, 2015 at 3:57 pm
  5. Hi guys, Good thing you have DMARC e-mail validation in place. However it does look like it's not working correct. I'm trying to sent a dmarc failure report to dmarc_ruf@groupon.com (as defined in your dmarc domain record). But it comes back as e-mail adres does not exist. Please fix the dmarc entry.

    by Edgar Krebbers on April 27, 2016 at 7:38 am
  6. @Edgar - Thanks for the comment. Our DMARC information is pointed at our vendor, Agari. We use their tools to parse the failure reports into actionable data and other insights. Thanks!

    by Ryan Boyd on May 2, 2016 at 1:43 pm

Leave a Reply

Your email address will not be published. Required fields are marked *