The financial costs of data breaches from phishing, spear phishing, and spoofing attacks on employees’ email accounts are eye-popping:
- 76% of companies that responded to Wombat’s 2018 State of the Phish survey said they experienced phishing attacks in 2017
- The average cost per lost record is $148, according to IBM Security
- Fake bills and invoices are the top way to disguise malware, Symantec said in its 2018 Internet Security Threat Report
- The average phishing attack costs a mid-sized company $1.6 million, according to PhishMe’s Enterprise Phishing Resiliency and Defense Report, and an FBI study tallied $500 million in annual losses for American businesses from phishing-related breaches
However, those numbers don’t address the damage done to brand trust, particularly in the financial services industry, when consumers receive a malicious email purportedly from a company they’ve done business with, or might do business with. If someone clicks a link in an email and a bad actor wreaks havoc on their life, the experience can leave them wary of that business, even though the company didn’t send the message.
There’s a high likelihood that someone who receives an email that looks like it came from your company will be fooled: According to a survey conducted by Intel Security, 97% of respondents worldwide couldn’t correctly identify a phishing email. And bad actors are getting more sophisticated at creating emails that, at first glance, seem legitimate.
In addition, email isn’t going away any time soon. The Financial Brand found that 70% of all consumers (and 72.1% of older Millennials) think email will still be around in a decade, more than any communication channel they were asked about, including cable TV and Facebook. There will be many future opportunities for consumers to be fooled by malicious emails.
The Damage That Bad Guys Can Do to Your Brand
You’ve likely put in the hard work to secure your company against direct attacks through training, code reviews, third-party penetration testing, infrastructure security, and more. You’re ready to deal with direct attacks on your business, but there are plenty of bad guys who aren’t interested in that: they’d rather impersonate your company and trick consumers into giving up personal information.
For example, they may send a phishing email like this one:
It probably won’t come as a surprise that the return email address in the header has been spoofed since it’s relatively easy to send an email from one address but make it look like it was sent from a different one. In addition, the account unlock link, as well as the customer service email address link, go to a malicious website that looks like Really Big Bank’s website, another trick that’s not hard to pull off. These days, many bad actors are using HTTPS in their links to make them appear more trustworthy.
If the recipient clicks one of those links and ends up having their bank account emptied, they’ll be unhappy with whoever scammed them, but there’s a good chance they’ll also direct some frustration toward Really Big Bank for allowing the impersonation to happen in the first place. If they’re a Really Big Bank customer, they might rethink their choice to have an account there, and if they’re not a customer, they’ll probably be wary of that brand in the future.
However, there are three email security standards that are free to use and relatively easy to implement. They can help stop bad actors from impersonating your company and tricking consumers into allowing their accounts to be compromised. Now more than ever, consumers will take their business elsewhere if they think a financial institution is so lax about security that it can’t be bothered to safeguard its email.
3 Steps to More Secure Email Sending
These may seem like small steps, but they can add up to a big impact on trust by helping stop bad actors from impersonating your company and alerting you to such efforts.
Step 1: Implement SPF (Sender Policy Framework)
SPF is an email authentication standard that helps protect senders and recipients from spam, spoofing, and phishing. It defines a way to validate that an email was sent from an authorized mail server and was designed to supplement the SMTP (Simple Mail Transfer Protocol) protocol that’s used to send email because SMTP doesn’t include any authentication mechanisms.
SPF also piggybacks on the well-established Domain Name System (DNS) that maps a web server name, such as really-bigbank.com, to an IP (Internet Protocol) address usable by a computer. It works like this:
- A domain administrator publishes a policy, called an SPF record, that defines which mail servers are authorized to send email from that domain. The SPF record is listed in the domain’s overall DNS records.
- When an inbound mail server receives an email, it looks up the rules for the Return-Path domain in the DNS records. The server then compares the IP address of the email sender with the authorized mail servers defined by the SPF record.
- The SPF record lists rules used by the receiving email server to decide whether to accept, reject, or otherwise flag the message.
An SPF record isn’t difficult to create: it’s simply a specially-formatted version of a DNS record created as a standard TXT file. It looks something like this:
really-bigbank.com TXT “v=spf1 include:really-biggerbank.com ~all”
Reading left to right, this record says:
- Any email that claims to be from really-bigbank.com should be validated with SPF, per the “v=spf1” prefix.
- It also specifies that the SPF records for really-biggerbank.com should also be included when validating email from really-bigbank.com. This is typically done to indicate that other domains are authorized to send email on behalf of the primary domain, such as when an organization sends messages from a subsidiary and/or splits its transactional and marketing emails between different domains. Multiple domains can be listed.
- The “~all” command tells the incoming mail server that any other servers sending email on behalf of really-bigbank.com should have their messages flagged as questionable.
SPF records can be more complicated than this example, but the basic mechanism remains the same. You can learn more about the specifics of implementing one in an explainer we created.
Implementing SPF helps keep bad actors from sending emails that look like they’re coming from your business, but you should add DKIM and DMARC for a complete email authentication solution.
Step 2: Create a DKIM (DomainKeys Identified Mail) Signature
DKIM is a technical standard that uses public key cryptography to verify that an email was sent from an authorized mail server. It adds a digital signature to the headers of an email message, allowing the incoming mail server to validate it against a public cryptographic key in the sending organization’s DNS records.
This is important because while SPF defines the mail servers that can send messages on behalf of your domain, it doesn’t offer a mechanism to verify whether the message headers or body have been altered or forged while in transit.
DKIM works like this:
- A domain administrator publishes a cryptographic public key in the domain’s overall DNS records.
- An outbound email server generates and attaches a unique DKIM signature header to each message it sends. The header includes two cryptographic hashes – one of the specified headers and one of the message body (or part of it) – as well as information about how the signature was generated.
- When an inbound mail server receives an email, it looks up the sender’s DKIM key in DNS and uses it to decrypt the signature and compare it against a freshly computed version. If the two match, the message can be assumed to be authentic and unaltered in transit.
A DKIM signature is a little more complicated to create than an SPF record, but it adds another layer of security that helps keep bad actors from impersonating your business. It looks like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=really-bigbank.com; s=sendemail; h=from:content-transfer-encoding:subject:message-id:dat e:to:mime-version; bh=ZkwViLQ8B7I9vFIen3+/FXErUuKv33PmCuZAwpem Gco=; b=kF31DkXsbP5bMGzOwivNE4fmMKX5W2/Yq0YqXD4 Og1fPT6ViqB35uLxLGGhHv2lqXBWwFhODPVPauUXxR YEpMsuisdU5TgYmbwSJYYrFLFj5ZWTZ7VGgg6/nI1ho PWbzDaL9qh
Here’s how to read those tags:
- “v=1” should always be there, since it indicates the signature specification version
- “a=” is the algorithm used to generate the signature; it should be “rhsa-sha256” unless there’s a reason to use something else
- “c=” is an optional tag that defines what kinds of minor modifications may be present in the email, such as extra white space, after it was sent, which can happen with some kinds of mail servers; this helps keep the receiving mail server from rejecting a legitimate email
- “d=” is the sending domain; that tag is used with “s=,” which is the selector record name used to locate the public key in DNS
- “h=” is a list of headers used by the signing algorithm to create the hash in the “b=” tag
- “bh=” is the message body hash
You can learn more about the specifics of implementing DKIM in an explainer we created.
Implementing SPF and DKIM help keep bad actors from sending emails that look like they’re coming from your business, but you should keep reading to learn how to add DMARC for a complete email authentication solution.
Step 3: Add DMARC to the Foundation Created by SPF and DKIM
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a technical standard that allows a company to publish a policy that defines its email authentication practices and provides instructions to inbound mail servers for enforcing them. It wraps around the SPF and DKIM authentication standards to enable a complete email sending solution.
This is important because neither SPF or DKIM alert you to malicious messages that managed to bypass both safeguards. That’s where DMARC comes into play.
Like SPF and DKIM, DMARC supplements SMTP and piggybacks on DNS. It works like this:
- A domain administrator creates a policy defining its organization’s email authentication practices and how receiving email servers should handle messages that violate it. The policy is included in the company’s DNS overall DNS records.
- When an inbound mail server receives a message, it uses DNS to look up the DMARC policy for the domain contained in the “From” header. The server evaluates the message for three key factors:
- Was the message’s DKIM signature validated?
- Did the message come from IP addresses allowed by the sending domain’s SPF record?
- Do the message headers show proper domain alignment? (For SPF, the message’s From domain and Return-Path domain must match. For DKIM, the message’s From domain and its DKIM “d=” domain must match.)
- After answering the questions in the previous step, the inbound mail server uses the sending domain’s DMARC policy to decide whether to accept, reject, or otherwise flag the message.
- After making the decision in the previous step, the inbound mail server reports the outcome to the sending domain owner.
Like an SPF record, a DMARC record is a specially-formatted version of a standard DNS TXT file. It looks like this:
_dmarc.really-bigbank.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:dmarc-aggregate@ really-bigbank.com\; ruf=mailto:dmarc-afrf@ really-bigbank.com\; pct=100"
Reading left to right, it says:
- “v=DMARC1” is the DMARC version
- “p=” is the policy that should be applied when a message fails the DMARC check:
- “none” means you want no action to be taken, which can be useful when you first implement DMARC and want to spend some time receiving and analyzing reports
- “quarantine” means to quarantine the email, which typically means that it ends up in the recipient’s junk mail folder
- “reject” means the email should be rejected
- “rua=” is the address where aggregate reports should be sent; these daily reports include information about message sources, domains used to send messages, sending IP addresses, and the number of messages sent on a specific date
- “ruf=” is the address where forensic reports should be sent; this report includes a copy of an email that failed DMARC validation as well as any SPF and DKIM failures, minus any personally identifiable information
- “pct=” is the percentage of messages that the policy should be applied to
Aggregate reports are XML documents designed to be machine-readable, so accumulated data can be easily analyzed over time. Forensic reports use a special format called AFRF and are useful for troubleshooting a domain’s authentication issues as well as identifying malicious domains and websites.
When you first implement DMARC, it can be useful to apply no policy to all messages for at least the first few days. You can use the aggregate reports to monitor the situation. Over time, you can start quarantining failed emails, first at a low percentage (5% or 10%) and then ramping that up over time.
After you spend some time quarantining 100% of emails that fail DMARC, you can switch to the reject policy and start at a low percentage again. Increase that percentage over time until you reach 100%. Use forensic reports in addition to aggregate ones to decide how quickly you should reach 100%.
The State of DMARC Implementation
Recent research shows that just half of Fortune 500 companies have deployed DMARC policies, and a whopping 99% of domains worldwide are unprotected by it. While it’s possible to use SPF and DKIM without adding on DMARC, those standards don’t help you take action against bad actors, since inbound mail servers don’t give you reports without a DMARC policy in place.
If your company hasn’t implemented SPF, DKIM, and DMARC yet, you should do so as soon as possible to not only protect your employees but also preserve brand trust among consumers.