The Old Horse named SMTP
Email is old. The first message sent across a computer network was sent in 1971. The current email protocol, SMTP, was codified under RFC 788 in 1981 and while it has been updated over the past 42 years (Man, I’m old), the core functionality in SMTP hasn’t changed much at all. Unfortunately, SMTP (like most early Internet protocols) was not built with security in mind at all. Early implementations allowed people to send messages as whoever they wanted to whoever they wanted with whatever content they wanted. There also wasn’t a lot you could do with email. The original RFC defines exactly 13 commands. 4 of them are still in common use; MAIL FROM, RCPT TO, DATA, and QUIT. If you’re a command line geek that likes using a raw SMTP server, you might also use VRFY. You poor, poor admin, you. We don’t really use HELO to open a server connection anymore, since it was replaced with EHLO when the ESMTP specification extended (That’s the E in the acronym) SMTP functionality.
Very little has changed since ESMTP was released in 2008, and while there have been attempts to replace SMTP (Hello there, MAPI), none have succeeded because SMTP is so ubiquitous. Security has improved in some ways. STARTTLS was added in 2002 to allow opportunistic TLS encryption. The AUTH command enabled user login. But that’s the majority of the security built into SMTP. Rather than bake a new cake that no one wants to eat, mail security now relies on email security systems that add SMTP preprocessing, connection filtering, blacklisting, whitelisting, and a huge list of other features designed to filter malware, block spam, and prevent phishing attacks. One of the core functions mail security systems utilize is a concept called “Sender Reputation.”
Sender Reputation and You!
Sender Reputation is a scoring systems that mail security systems use to determine if messages from a specific domain are valid or if they are spam or a phishing attack. It uses a weighted scoring system that accounts for a number of different factors that are common in email-based attacks. For instance, a sender’s reputation is impacted by whether the sending server has been added to a blacklist service like Spamhaus and Spamcop. Thinks like the IP source history of messages for a specific domain, reverse DNS lookups, and a fistful of other factors also play into a domain’s sender reputation. Unfortunately, many of the factors used in mail security rely on historical data that is outside the control of an organization and can result in false positive mail blocks that have a huge impact on an organizations ability to communicate. This is where SPF, DKIM, and DMARC come in.
What Are SPF, DKIM, and DMARC?
These three protocols have a huge impact on sender reputation because they help mail security systems verify that a message is coming from an authorized and authentic source. Each one plays a different role in preventing unauthorized use of a domain in email messages. Here’s what each one does (Note, I will not be explaining how these systems work in this article, just what they do):
SPF stands for Sender Policy Framework and is an email authorization tool. SPF was originally developed to combat domain spoofing, where an attacker uses their own email server to send messages using a sender domain they don’t own. It relies on a TXT record in DNS that includes a list of servers and instructs security systems to take specific actions with servers that aren’t included in the record. There was once an attempt to add a new DNS record type specifically for SPF, but it, well, failed to take off.
Email security systems will check for an SPF record on a domain by performing a TXT record lookup on the sender’s email domain. It then compares the sending server against the list of authorized servers in the record. Part of the SPF record allows organizations to control what happens to email that comes from servers that aren’t authorized, but mail security systems can ignore those instructions or apply more strict controls. Some security systems allow direct control over SPF failures and passes. Most, however, will follow the instructions set in the SPF record.
Domain Keys Identified Mail is an email authentication system that uses PKI based signatures to verify the sender of an email. The explanation of how this works is a little involved and can be difficult to understand without some knowledge of how PKI works, but the gist is that DKIM allows a recipient organization’s mail security platform to validate the source of and content of a message and act accordingly.
The PKI aspect of DKIM is managed with DNS TXT records called “Selectors” that hold a copy of a public key. The public key is used to decrypt an encrypted hash value that is included with the message. The recipient will then calculate a hash value for set portions of a message and compare it with the decrypted one. If the values match, it acts as proof that the message hasn’t been altered in transit. Since the private key is used to encrypt the hash value and no other organization has access to the private key, DKIM validation also lets the recipient know that the source is accurate.As a result, implementing DKIM provides a huge boost to sender reputation when it is properly configured and functioning.
There are a number of tools that can validate DKIM records, but the only one I’ve found so far that will detect and show DKIM records on the domain is available as a free tool from PowerDMARC. Note: This is not an advertisement, paid or unpaid, for PowerDMARC. I have not used anything of theirs other than the DKIM checker, so am not able to recommend anything they sell.
DMARC is a policy enforcement and reporting tool that uses SPF and DKIM to create a much more useful solution. It uses a DNS TXT record just like SPF and DKIM. The record instructs recipient servers to quarantine or block message that fail SPF, DKIM, and domain header alignment. A third policy option of “none” allows a sending domain to instruct recipients to assess SPF and DKIM policy alignment but take no action if they fail. DMARC actions are enforced absolutely and can’t be bypassed by recipients (or at least it shouldn’t if your mail security solution allows you to define DMARC functions).
In addition to enforcing policy for an email domain, DMARC allows administrators to collect reporting data that can be used for various purposes. For instance, setting DMARC policy enforcement to “none” and collecting aggregate and forensic report data, admins can find out what mail servers are using their email domain. Admins can then use that information to discovery whether they have properly accounted for all approved email sources for their domain. This is extremely useful in larger organizations that have numerous applications that send email (SalesForce, Mandrill, etc). It’s pretty important to do this when implementing DMARC because setting the action to quarantine or block failures without properly accounting for all valid mail sources seriously impacts business functions that rely on email.
Full implementation of SPF, DKIM, and DMARC has an enormous impact on sender reputation. So much so that passing all three checks will often ignore heuristic and keyword assessments of incoming messages. As such, implementing all three is critical for any business that relies on automated messaging tools for advertisements, newsletters, and other messages that could otherwise be flagged as spam.
For instance, GMail’s security algorithm often blocks messages that don’t have a valid PTR record that matches the sender domain assigned to their email server IP. Configuring SPF sometimes causes GMail security to allow messages through with PTR record lookup failures. Implementing all three all but guarantees such emails will be allowed to pass through and be properly delivered. So if you want to make sure your emails are received, implement SPF, DKIM, and DMARC.