Equifax’s email has a security hole

Nonsecure Email

Failed to implement DMARC – a common anti-fraud protection.

A quick check shows that Equifax has not implemented DMARC to guard against email fraudsters claiming to be Equifax. DMARC is a way to say to the world “any email claiming to be from my domain is authenticated with DKIM or from an IP listed in my SPF record – and if not, the message is fraudulent”

Paypal implemented this year’s ago in consultation with Yahoo and other Internet Service Providers.

The upshot? Anyone can impersonate the equifax.com domain when sending email. Not surprising considering that Equifax had failed to implement a patch available a two months before the breach occurred.

DMARC is a DNS record that uses both SPF and DKIM records to specify which delivery locations (e.g. IPs) are allowed to send email on behalf of a given domain. The below DMARC records for Paypal, Chase bank, and Equifax. Both Paypal and Chase have implemented a strict reject policy ‘p=reject’ on 100% of their mail ‘pct:100’. In effect this presents a guideline to receiving networks. It’s not a difficult authentication method to implement.

For the following lookups, I am using dig, a command available on any MAC or Linux machine. On a PC, one could use the free services offered at mxtoolbox.com to do their own lookups. All these lookups have been performed at 11:10 AM CST, 09-15-2017.

Example lookup with dig from the command line:
>> dig +short -t TXT _dmarc.paypal.com

Paypal.com DMARC record:
“v=DMARC1\; p=reject\; rua=mailto:d@rua.agari.com\; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com”

Chase.com DMARC record:
“v=DMARC1\; p=reject\; pct=100\; rua=mailto:d@rua.agari.com\; ruf=mailto:d@ruf.agari.com\;”

Equifax.com DMARC record:
None. The lookup returns no response indicating that no DMARC records has been installed. We expect equifax will implement DMARC so it should be noted that as of September 15th, 2017 at 11:10am CST, no DMARC record is found from this lookup.

How to interpret a DMARC record.

This post is not meant to be an in depth tutorial in DMARC. Please visit https://dmarc.org/ for a full explanation. The key concepts of DMARC are twofold:

p=reject  – The policy setting (options are reject/quarantine/monitor/none)

pct=100 — The percentage of mail that is to be reviewed (100 means apply the policy to 100% of mail from this domain)

How DMARC policies are implemented by a receiving mail server.

If Gmail receives a message from Paypal that originates from an IP listed in the Paypal SPF record, that message is deemed to have passed DMARC. If the IP is not part of the Papal SPF record, the message bounced per the ‘p=reject’ setting. A setting of ‘p=quarantine’ could mean mail is sent directly to spam or hidden in a server quarantine, never to be shown to any end recipient of the message.

The point here is that equifax.com has not implemented any such record. Any IP in the world is free to impersonate (aka spoof) the equifax.com domain under their current implementation. Of course fraud is still illegal, but there is no DNS record in place to forcefully protect against anyone impersonating the equifax.com domain over email. DMARC is an available option for enhanced security and it seems shocking to us that an institution like Equifax, which holds the personal information for millions of Americans, has yet to implement this level of protection.

DMARC is certainly not the only metric large ISPs like Gmail or Yahoo use to monitor fraud. An SPF record alone (which equifax.com does have in place) will still provide a list of IPs from which equifax.com mail may be sent. But without DMARC in place, there is no policy stated and the decision on how to handle the incoming mail is thus left to algorithms operated by the ISPs themselves.

To be sure, DMARC implementation is still quite sparse even among fortune 500 companies. As the Agari Global DMARC Adoption Report shows, as of August 2017, 67% of Fortune 500 companies in the US have yet to implement any DMARC policy. Equifax is not alone in this by any stretch. For many organizations, implementing DMARC can be risky and difficult. One of the dangers of moving to a p=reject policy too quickly is that if all mail streams for a given domain are not covered by DKIM and/or SPF records, one might inadvertently cause their own legitimate mail to get flagged and possibly rejected.

A word of advice to anyone reading this post about DMARC. If you intend to protect your domain against spoofing with DMARC, make sure you to contact your ESP to let them know. Passing DMARC with your ReachMail messages is possible, but not without additional DNS records being implemented on your domain. We can accommodate DMARC for ReachMail clients and we’ll walk you through how to ensure that all your mail streams are protected in safe manner. A brief explanation of DMARC settings can be found here.

Final thoughts.

We checked the DMARC records for many major financials institutions in the United States. Chase.com, citigroup.com, wellsfargo.com, bankofamerica.com all maintain strict DMARC policies. Their domains are protected against spoofing.

Of the three major credit bureaus in the US, only experian.com has implemented a DMARC record. Experian’s DMARC policy is p=none, meaning they have no policy. Setting a p=none policy may not protect the experian.com domain from spoofing, but it does allow them to receive reports so they can monitor any potential abuse. Neither equifax.com nor transunion.com have implemented any record.

All this begs the question: if these institutions are responsible for maintaining the private information for millions of Americans, should they be held to higher security standards?

Protect your reputation – and get better deliverability with DMARC

A common question we receive from marketers is “How do I get better deliverability?” We typically review a sender’s lists, offer and authentication setup to make sure the sender is sending the right offer to the right person using a valid email configuration (i.e. DKIM or SPF with the proper domain setup)

But what if your list is great, you’re sending out highly engaging email using the correct setup? One possible source of problems is what if a spammer is “spoofing” your email? Unbeknownst to you, a spammer could be forging your sender address and get a free ride on your reputation. Until very recently you’d have no idea how to find out if this is happening.

Fortunately, major senders like PayPal and major banks and receivers like Gmail, AOL and yahoo have collaborated to develop a specification called DMARC to combat this problem.

Basically – it’s a way to tell the recipient what to do with email that they receive that’s not aligned. You publish a policy on which authentication mechanism DKIM, SPF or both.

Examples are:

  • Mis-matched From and DKIM signature domains.
  • Use of sub-domain in signature or From without corresponding support in the DMARC record.

You have several choices to tell the recipient what do with misaligned email:

  • None – monitor – telling the recipient that you are not making a recommendation on what to do with any misaligned email. It’s best to start here and then gradually move to making recommendations
  • Quarantine – tells the receiver to treat the email with suspicion
  • Reject – tells the receiver to not accept any email that doesn’t pass alignment

Why wouldn’t you consider automatically telling recipients to reject non-aligned email? Keep in mind that you may be a larger organization that sends a variety of email – corporate, marketing or transactional. Plus you may have a variety of users sending out different versions – legitimately of each type of email. It’s best to get reports on the failures sent back to you so you can fix alignment. Participating receivers send back:

  • Source IP – the IP sending the email
  • Count – how many of each version received
  • Disposition – what the recipient did with the email
  • SPF – pass or fail
  • DKIM – pass or fail
  • Header from: ie. example.org

Besides getting great information on your email that’s sent another major benefit is that you’ll see enhanced email deliverability. Gmail, for example, states that email that’s not authenticated are likely to be placed in the junk folder. They recommend publishing a DMARC policy. For more detailed information check out our DMARC support article.