Third-Party DMARC Compliance: Finding Zen with Zendesk

Posted by Thomas O'Leary on

So, you want to implement DMARC (Domain-based Message Authentication Reporting and Conformance) to protect your customers and your brand from phishing attacks. Fantastic idea.

But be careful—if you implement a DMARC “reject” policy before cleaning up the authentication of your legitimate traffic, you risk blocking it along with the malicious messages.

One of the biggest challenges of this authentication process is identifying and authorizing all third parties sending email on behalf of your company. Return Path recently confronted this issue when we contracted with a new third-party sender, Zendesk.

We hired them to send customer support emails on behalf of Return Path. But because returnpath.com has a DMARC “reject” policy, we had to take steps to ensure that legitimate Zendesk emails weren’t blocked for using our domain.

Below we explore three steps you can take to authorize third-party senders and reveal how we implemented those steps with Zendesk.

Step 1: Identify your third-party senders

The most critical step you can take to protect the deliverability of your legitimate messages is to identify all third-party senders your company contracts with. Collaborate with teams across your company—especially marketing—to compile a complete list of vendors.

Step 2: Update your SPF record

As you might remember, DMARC is based on two email authentication protocols, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

To authorize all of the senders you have identified, you must update your SPF record.  You can use Return Path’s free SPF Check Tool to get visibility into your authentication status.

To add a new third party, ask the vendor to provide you with an IP range or an “include statement” to add to your SPF record. This action designates this new sender as a legitimate sender.

Step 3: Confirm your third party is signing with DKIM

Next, confirm that DKIM is being signed on the third-party traffic. While DMARC only requires that you pass and align for either DKIM or SPF, Return Path highly recommends passing and aligning for both. If one method fails, the other will provide back up.

Need a more in-depth review of how to pass DMARC? Check out this blog series.

Third-party DMARC compliance in action with Zendesk

Our Zendesk example reveals how this process works in action.

When we looked at the default message configuration for ZenDesk email traffic sent on behalf of our support team at Return Path, here’s what we found:

Header From: Return Path support@returnpathhelp.zendesk.com
MFROM: support@returnpathhelp.zendesk.com
DKIM-Signature: d=zendesk.com

As you can see, this initial set up is aligned correctly (the domain in the DKIM signature matches the domain in the Header From address) but it’s not ideal. We want our Header From domain to be returnpath.com since the email is supposed to be coming from us. Any other name in that From address would confuse our customers.

Here’s how you can change the Header From domain from zendesk.com to your company’s domain (in our case “returnpath.com”) without failing DMARC:

Screen-Shot-2016-07-13-at-11.41.16-AM-300x77

  • Within the Zendesk UI, select Admin → Channels (section) → Email → Click the “make default” option next to the support address. Doing so confirms that any emails the agent initiates will be from this email address with the correct aligned MFrom domain. In this example, it would be support@returnpath.com..
  • Enable DKIM in the Zendesk UI. Go to Admin → Channels (section) → Email → Under “Custom domain for DKIM,” check the “enable” checkbox.
  • Add a CNAME in the DNS. Return path added zendesk1._domainkey.returnpath.com to zendesk1._domainkey.zendesk.com. As a result, Zendesk will sign our emails as d=returnpath.com.

In order to verify that the email is authenticated with DKIM, the receiver will look at d=returnpath.com with the current selector. We’ve added the CNAME, which is an alias. So when the DNS lookup is happening for the public key, the system knows to lookup zendesk1._domainkey.zendesk.com, which is where you can find the public key.

This entry is not only useful for attaining alignment but also allows for automatic key rotation so that you will not have to implement a new key every time the vendor changes it for security reasons.

  • To attain SPF alignment Zendesk does something very useful. Once you update your domain’s SPF record to contain “include:mail.zendesk.com”, Zendesk’s system will automatically do the following:
    1. Change the MFROM email header to returnpath.com.
    2. Change the Header From to returnpath.com.

Zendesk doesn’t conduct an automatic lookup to check if we updated our SPF record. To force the system to check the current SPF record, go into Admin → Email → go to the support email address → under the “verifications” drop-down list, click “retry” next to the SPF check to verify the record.

If at any time the record is incorrect, Zendesk will revert back to the default settings for the email headers. After taking these steps, Return Path’s Support emails now has the following configuration:

Header From: Return Path support@returnpath.com
MFROM: support@returnpath.com
DKIM-Signature:  d=returnpath.com

As you can see, the traffic on this domain will now pass and align for both DKIM and SPF based on the returnpath.com domain. And these messages will now look like normal Return Path traffic.  Hopefully, your vendor will have the SPF alignment capability that ZenDesk does, and support the DKIM CNAME process which will enable you to pass DMARC. If you are interested in learning more about DMARC or how our Managed Service Team can help you with tricky situations like this one, contact us here.


Popular this Month

 3 Trends Impacting Email: Persistent Fraud, Part 2

3 Trends Impacting Email: Persistent Fraud, Part 2

In part one of this three-part series, I examined the evolving landscape of...

Read More

 The Top 16 Topics of 2016

The Top 16 Topics of 2016

2017 is finally here! But before we focus on the year ahead, we wanted to...

Read More

 Think Fighting Email Fraud is Someone Else’s Job? Here’s the Real Cost of Doing Nothing.

Think Fighting Email Fraud is Someone Else’s Job? Here’s the Real Cost of Doing Nothing.

Cyberattacks against your brand can be very damaging and costly to both your...

Read More

Author Image

About Thomas O'Leary

Thomas O’Leary is a Strategic Project Manager at Return Path. He works closely with our clients to help them diagnose and resolve email authentication practices, as well as providing guidance on strategic initiatives to prevent email fraud. Tom has been in the security industry for several years and joined Return Path from the largest private SIEM company in the world. When he is not busy saving the world from phishing, you can find Tom traveling around it as much as possible. Follow him on Twitter @ThomasOLeary22.

Author Archive

Stay up to date

Enter your name and email address below to subscribe to our mailing list.

Your browser is out of date.
For a better Return Path experience, click a link below to get the latest version.