Oct 8, 2018

Trust but verify: Untangling the web of third-party senders & DMARC

Trust but verify

DMARC presents a host of hurdles for companies implementing it themselves. If you can navigate the first step of the enforcement process (parsing XML data from aggregate reports; translating IP addresses to sender names; and correctly categorizing malicious senders, approved senders, and shadow IT), which is no small feat, you can move on to the next step of the DMARC process — configuring SPF and DKIM for each sender.

Unfortunately, many senders are behind the times when it comes to getting SPF and DKIM configurations right, and it’s up to your team to understand what is really necessary.

You would think that all you need to do is to contact your vendor and ask them what SPF and DKIM information you need to add to your DNS and be done with it. Unfortunately, it is not always that easy. Each email sender tends to handle email authentication differently, and some senders aren’t even familiar with the latest processes.

Two main scenarios could complicate your DMARC process when working with third-party senders:

1. The sender doesn’t understand the additional requirements that DMARC places on SPF and DKIM.

Before DMARC came along, alignment (the return path and/or DKIM domain matching the From domain) was not a requirement. And even though DMARC is over six years old, it’s not as widespread as it should be. As a result, senders who have not kept up with the times may give you SPF or DKIM information that is incorrect.

There are a couple of ways this could happen: Their system does not support DMARC-compliant emails, or the person you are speaking to at your vendor does not have the most up-to-date information. In some cases, senior technical groups may be aware of DMARC’s requirements, but this may not have made its way to the frontline support teams.

There may also be cases where the sender has never had to send DMARC-compliant emails and does not know what is involved. While most vendors are now familiar with SPF, they might not have experience implementing it in combination with DMARC.

2. Out-of-date methods and configurations

The evolution of email authentication has made older standards like SenderID and DomainKey (which is different from DKIM) obsolete, but some vendors still direct you to configure them.

It’s a red flag if your senders mention these configurations in reference to DMARC. These standards do not impactDMARC, which means they are useless in getting your emails authenticated and delivered under a DMARC enforcement policy. While it’s not harmful to implement these standards, they don’t reflect the modern era of email authentication.

In some cases, vendors’ verification systems themselves may be out of date, which could lead you to believe you have a problem, then spend a lot of time dissecting it, only to determine there was no issue at all.

These issues seem minor but can quickly exhaust your resources and derail your DMARC progress.

So what can you do?

To limit the risk associated with these issues, you’ll need a subject-matter expert to guide the vendors on the following topics:

  • DMARC alignment
  • DKIM domains
  • Return-path and email headers

You’ll also need to set up mechanisms to check each vendor’s work. If there are errors, you can catch them by monitoring the authentication status in your aggregate (rua) reports, or by testing emails from the sender and analyzing the header information.

Alternatively, you could work with an email authentication partner that will handle all of this on your behalf.

If you’re interested in finding out more about how Valimail can help manage third-party sender configurations, contact us today.

Subscribe to our newsletter