There’s no filtering out the truth:
You need to protect your company’s email.
In 2013, more than 100 billion business emails were sent and received each day. Just one in five of all emails sent in 2013 were legitimate, and 92% of all illegitimate emails included links to potentially malicious content.
There are signs of improvement however; this month is the first in the last 12 years where less than half of Symantec’s clients’ emails were spam.
You can thank three email security standards (and other initiatives) for the reduction in spam: SPF, DKIM, and DMARC. Still, security risks are prevalent. I was recently told a story about a CFO who was subject to a phishing attempt. The attempt failed, but if it had succeeded, it would have cost the organization $50,000.
As for these email standards, there’s still a great deal of confusion surrounding them. I hope I can provide some clarity with this post, as well as walk you through how to implement SPF, DKIM, and DMARC.
Sender Policy Framework (RFC 4408)
Sender Policy Framework, or SPF, is the old man at the email authentication party. SPF is an open standard that specifies a method for preventing sender address forgery, according to openspf.org. It isn’t about stopping spam; it’s about controlling and stopping attempted sender forgeries.
SPF enables you to identify your domain’s legitimate mail sources and prevents unauthorized sources from sending thousands—or even millions—of illicit emails from your domain.
There are four types of email abuse commonly associated with email sender forgery:
Spam (unsolicited bulk email & unsolicited commercial email)
Fraudsters (419 scams)
Malware (adware, zero days, viruses, trojans, etc.)
Phishers (spear-phishing)
You don’t want your organization’s domain associated with any of these for obvious reasons. SPF will help to make sure your organization’s emails are actually coming from you.
DomainKeys Identified Mail (RFC 6376, replaces RFC 4871 and RFC 5672 which are now obsolete)
DKIM, or DomainKeys Identified Mail, is a TXT record published in your Domain Name System (DNS). It involves something that all IT admins should learn to love: keys—public keys to be specific.
Before we dive into DKIM, it’s important we understand what keys are and how they work. Keys, in this case, public-key cryptography, consists of a public (known to everyone) and private (often referred to as secret) keys. Public and private keys are mathematically linked to one another, making secure communication over public channels possible.
These keys are like a tamper-evident seal on a transparent envelope. You’re not necessarily hiding the message; you’re only authenticating with 100% certainty both the sender and the message.
Now, back to DKIM.
“Technically DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication,” according to dkim.org. In other words, DKIM uses keys to make sure an email sender is who they say they are.
With DKIM, public and private key pairs are generated to keep mail servers and communications authenticated. Each outgoing Simple Mail Transfer Protocol (SMTP) server needs the right private key and prefix in order to match a public DNS record that the receiving mail server then verifies.
Ever wonder why the lock icon shows up in Gmail when you get messages from eBay, Paypal, or your bank? That’s DKIM and a little bit of DMARC (which we’ll cover shortly). Below, mailed-by shows the SPF match and signed-by shows the DKIM match. DKIM and DMARC aren’t essential just yet, but like IPv6, it’s moving quickly from test-lab to better-have.
Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, helps senders and receivers work together to create more secure email communications. DMARC was created by a group of organizations to limit email-based abuse “by solving a couple of long-standing operational, deployment, and reporting issues related to email authentication protocols,” according to dmarc.org.
DMARC enables the message sender to indicate that their messages are protected with SPF and/or DKIM. A DMARC policy applies clear instructions for the message receiver to follow if an email does not pass SPF or DKIM authentication—for instance, reject or junk it.
Also, DMARC sends a report back to the sender about messages that PASS and/or FAIL DMARC evaluation.