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:firstname.lastname@example.org\; ruf=mailto:email@example.com,mailto:firstname.lastname@example.org”
Chase.com DMARC record:
“v=DMARC1\; p=reject\; pct=100\; rua=mailto:email@example.com\; ruf=mailto:firstname.lastname@example.org\;”
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.
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?