A new Cloudflare phishing report notes that most of the 1 billion brand impersonation emails the company detected “passed” SPF, DKIM, and DMARC email authentication protocols.
That statistic is a bit misleading; the emails “passed” only because of a lack of enforcement controls by the brands themselves. The essential overlooked step of enforcement of email authentication protocols is a big reason why phishing emails remain the root cause of the overwhelming majority of cyber attacks and fraud.
A real reduction in impersonated emails will only happen when customers push the financial consequences of impersonation onto their vendors. We will explore this in more detail through the following topics:
- How To Create Financial Consequences For DMARC Failure
- Why “Passing” Is Not The Same As Passing
- Bottom Line: Impersonation Is Primarily A Condition of Inconvenience
How To Create Financial Consequences For DMARC Failure
When an organization does not enforce DMARC, attackers can impersonate the brand. From the organization’s perspective, the investment of time to prevent impersonation may not deliver a return on that investment – even if it is small.
Impersonated organizations avoid consequences and thus feel no pain from victims of impersonated emails. The only change will occur when angry customers start to share the pain.
The Problem: Impersonated Organizations Avoid Consequences
Most often, the ones suffering the consequences of impersonated emails will be the hundreds or thousands of companies, nonprofits, and other organizations whose employees fall for the impersonation emails. The impersonated emails might contain annoying SPAM, but more often the phishing email will deliver more dangerous payloads that lead to stolen credentials, business email compromise (BEC) attacks, or ransomware attacks.
Victim organizations have little to no recourse to extract any compensation from the organization that is allowing their brand to be impersonated. Meanwhile, the company being impersonated has no financial incentive to change their behavior.
The Solution: The Pain of Email Impersonation Must Be Shared
The only leverage an organization may be able to apply will be to their vendors. Customers should become angry that their vendors expose them to risk and should demand that their suppliers implement and enforce SPF, DKIM, and DMARC email authentication protocols as a criteria for a business relationship.
Vendors need to make sales and will make reasonable concessions to customers to keep them from switching to competitors. At the same time, an organization is also quite likely to fall for business email compromise and phishing attacks from their vendors. After all, accounts payable clerks will open virus-laden PDF files named “overdue invoice” or “past-due statement” even if they don’t recognize the sender.
Admittedly, smaller organizations will not have leverage. However, even a medium-sized government agency or a Fortune 5000 corporation can easily make a demand for email authentication protocols as one of the conditions within their contract. The organization making the demand will have little to no cost to add such a clause to their contract and will see a huge reduction in risk from email impersonations.
Implementing all three email authentication protocols takes time, but does not cost significant money. Vendors will not be financially harmed by making these requests that simply pass the pain of impersonated emails back to them.
Emails Don’t ‘Pass’ – They Are Allowed To Bypass
Cloudflare released its inaugural Phishing Threats Report recently and cited over 1 billion instances of brand impersonations detected in SPAM, email threats, and malicious messages. Email authentication protocols such as SPF, DKIM, and DMARC are supposed to protect brands, yet Cloudflare notes that the “majority (89%) of unwanted messages ‘passed’ SPF, DKIM, or DMARC checks.”
Cloudflare can be 100% accurate that roughly 890,000,000 emails contain faked brand impersonations attempting to spoof email recipients. However, they definitely had to put “passed” in quotation marks because email authentication checks only fail spoofed emails under very specific configurations that most companies fail to implement. Instead, most impersonated emails are simply allowed to bypass authentication by the impersonated organization because of inadequate setup of all three protocols.
SPF Protocol: Spoofed Passes and Legitimate Fails
SPF stands for the Sender Policy Framework, and SPF notes if the email server is an authorized email server. An organization sets up an SPF file on their domain and lists the legitimate email servers sending email on behalf of that domain.
SPF can be spoofed through a faked header in which a malicious sender can list their own email server. Instead of matching the spoofed domain in the body of the email or listed in the “From” field displayed to the email recipient, the email server reads the hidden header, which validates the SPF for the attacker’s malicious domain. It does not have to match the “From” field in any way.
SPF can also fail for legitimate emails if the SPF file is not maintained. A legitimate email sent by a new email server on the domain will simply fail if the server is not in the SPF file. A mail service such as MailChimp may contain an SPF reference to the MailChimp email servers or the MailChimp email servers need to be added to the organization’s SPF file.
DKIM Protocol: Spoofed Passes and Legitimate Fails
DKIM is the acronym for the DomainKeys Identified Mail protocol, which enables an organization to digitally sign emails using an encrypted hash value based on public encryption keys hosted on the organization’s domain.
As with SPF, malicious senders can implement DKIM for their malicious domain and sign SPAM with their own public encryption key hosted on their own domain. An email server will not compare the encryption key or the domain in the header with the domain shown in the “From” field to check for a match.
Just as with the SPF protocol, inadequate setup of legitimate third-party email senders, such as HubSpot, or new email servers can lead to DKIM failure. DKIM can also be tricky to publish without errors and simple typos can lead to failure for all DKIM protocol checks.
Our SPF and DKIM guides contain detailed information on how to properly set up the protocols.
DMARC Protocol: Spoofed Passes and Legitimate Fails
DMARC, while a clumsy acronym, replaces the full, and more unwieldy Domain-based Message Authentication Reporting and Conformance protocol. DMARC provides a mechanism to validate the domain of the brand listed in the “From” field displayed in the body of the email against SPF and DKIM protocols listed on that domain.
There are two ways a spoofed email can “pass” DMARC.
First, when the sender uses a lookalike domain such as “Amaz0n” or “Arnazon” when pretending to be “Amazon.” The malicious sender can set up SPF, DKIM, and DMARC for their malicious and look-alike domain and legitimately pass all three checks with their fraudulent domain that is not technically an impersonation domain.
Second, and much more commonly, the DMARC protocol is often simply not set up for active enforcement by the impersonated domain. In a standard process, DMARC will be established with a “p=none” setting, which does not provide any guidance to the receiving email server or email security tool for what to do if the protocols do not match.
Often, the default will be to deliver these messages, and this likely constitutes the bulk of the 89% of the emails that “passed” SPF, DKIM, and DMARC authentication checks. This is technically not passing DMARC because the impersonation email fails the check, but when less than half of enterprise DMARC policies meet the “p=reject” or even the “p=quarantine” authentication levels for enforcement, many impersonation emails can fail and simply bypass filters anyway.
Legitimate emails can fail DMARC if the organization has not carefully and thoroughly established and recorded the legitimate sources for email using their domain. Many organizations worry that they may not have SPF or DKIM properly established for all of their internal and third-party email servers. Afraid of the possibility of rejection for their marketing emails, an impersonated organization will be conservative and simply avoid enforcing DMARC.
Also read: Why DMARC Is Failing: 3 Issues With DMARC
Standard Email Protection Isn’t Enough
Some email services can also default to allowing even “p=reject” emails to be delivered to quarantine or SPAM folders. Similarly, email security tools will also typically be set up to be overly permissive to avoid blocking critical business emails.
Security teams should adjust their settings on email servers, for email SaaS providers, and within email security tools to explicitly reject emails that fail email authentication protocols. Organizations need to take action where they can to honor DMARC ‘p=reject’ and ‘p=quarantine’ settings and at least gain some advantage from the organizations that properly enforce the email authentication protocols.
Also read: How to Improve Email Security for Enterprises & Businesses
Bottom Line: Impersonation Is Primarily A Condition of Inconvenience
Those 890,000,000 emails that impersonate brands probably would not pass properly enforced SPF, DKIM, and DMARC protocols. Loose delivery filters tend to be overly permissive and put the burden of analyzing the emails for signs of spoofing on the shoulders of the weak link: our non-technical employees.
Proper enforcement of email authentication takes time, but does not cost much money. Companies don’t want to be inconvenienced by undelivered marketing emails, so instead they allow others to suffer from attacks impersonating them.
It is time for customers to get angry and push back where they can – at vendors. Vendors currently worry about losing potential customers, but will worry much more about losing actual customers. Instead of resisting security, the sales teams will start to help motivate the entire organization to stop email impersonation.
Read next: Spear Phishing Prevention: 10 Ways to Protect Your Organization
