As email becomes more important to the everyday infrastructure of businesses email authentication is paramount. This means that recipient email servers need to be able to verify that an email is actually from the domain it claims. Being able to determine whether an email is spoofed or legitimate can mean the difference between a successful phishing attack, a malware transmission, or important emails being delivered to a junk folder rather than the inbox.

The most common way of authenticating email is by utilizing a stack of technologies, namely Domain Keys Identified Mail (DKIM), Sender Policy Framework (SPF), and Domain-based Message Authentication, Reporting & Conformance (DMARC). Needless to say, people will generally use the acronym form of these technologies, and that's what you will see if reading further on the subjects. There are a few other things that come into play with deliverability, but for BenchmarkONE's purposes, you only need to be familiar with these.

If you check out our article about this, it offers a high-level overview of how BenchmarkONE leverages DKIM and SPF to authenticate your outbound emails. The purpose of this article is to explain them in more depth, but first, you need at least a basic understand of the Domain Name System (DNS).

Every device that connects to the internet (like servers) has an IP address. Picture this IP address as a phone number. If you call the right phone number, you'll end up at the server you want. For example, if I want to call Google, I can type 216.58.192.174 into my URL bar of my browser, and I will end up on Google's server. Go ahead and try it.

A long time ago, the guys in charge of the internet realized how unreasonable it was for people to remember an IP address to access a server, so they created the Domain Name System. Instead of remembering a number, people could just remember a customized domain name that would automatically redirect them to the intended server. This system relies on special servers, called DNS servers, that handle incoming requests and route them to the proper IP address. They are, in a nutshell, big phone books for the internet, and they're generally owned by big internet companies (think Google, GoDaddy, NASA).

These DNS servers hold all information about a domain, including what IP address should receive inbound requests, how to handle subdomains (like www, mail, mobile, etc.), or most importantly, what IP address(es) are authorized to send email from it. For example, lots of people use Microsoft Office 365 for email, but host their website elsewhere (like with GoDaddy, for example). This means their domain name's DNS records would need to direct web browsers to the GoDaddy server's IP address, but email sent from Microsoft's servers are also allowed.

So to recap, servers have IP addresses, domain names are human-readable ways to "look up" a server's IP address, and DNS servers are the phone books for the internet, which will not only look up the IP address for a domain name, but offer other information too, similar to a phone book showing a street address. This is where we can dive into the first security layer BenchmarkONE can utilize: DKIM.

DomainKey Identified Mail, or DKIM, is another layer of protection which is intended to assure the reader that the message was not changed in any way during transit. This is to avoid man-in-the-middle attacks, where someone can intercept a message, change it to either defraud, mislead, or inject something malicious, then send it back on its merry way to the unknowing recipient.

DKIM uses something called public-key cryptography, which is an asymmetrical encryption type. It sounds confusing, but it's actually pretty simple in this context because it's rather abstract, and you only need to understand the high-level overview of how it works.

The first step in DKIM is generating a key pair. This pair consists of a public key and a private key, each of which is a really long, jumbled mess of letters, numbers, and symbols. This pair of keys can be used to generate very specific, very complex "hashes," which can be mathematically traced to either key. So, with that in mind, while you can generate a hash from a key and resolve it to "match" the other key, you can't use it to actually "find" the other key. If you think this is confusing, I agree completely. Luckily, that's about all you really need to know. It uses something called the RSA algorithm, and the guy that invented it is a decorated mathematician. He did the thinking so we don't have to.

So for email authentication, the application is similar to SPF. The public key will be stored publicly in a DNS record on the sending domain. Then, the sending email server "signs" the headers of outgoing emails with a hash that's generated by the private key. Using that algorithm mentioned previously, the recipient mail server can match that signature hash to the public key that's stored in the DNS record on the domain, then confirm/pass the email, or reject/fail it. If the DKIM check fails, a warning is usually displayed to the reader that the message may be spoofed, and sometimes the message will be delivered directly to a spam/junk folder.

Sender Policy Framework, or SPF, is a way for recipient servers to determine if an email received is actually from the stated sender. For example, I can build a mail server, name it whatever I want (like benchmarkone.com, or yahoo.com), and then just start blasting emails from it. There's no restriction that would prevent me (or anyone else) from doing that. This is why it's important that recipient servers check the sender's domain to ensure the server that actually sent the message is allowed to do so. This is where SPF records come into play.

An SPF record is a DNS record that plainly states the IP addresses and domains that are allowed to send email from the parent domain name. These are public knowledge, and you can see any SPF records on a domain name by entering the domain into the top box of this page. If you enter benchmarkone.com into the box on that page, you'll see that we have an SPF record with several inclusions for Google, Sendgrid, and Dyn, which allows us to send emails from benchmarkone.com from servers belonging to those companies. If someone were to send an email from name@benchmarkone.com from a server not included in that record, it should be flagged as a possible spoof by the recipient's email system, and possibly delivered to the spam folder.

Since only the owner of a domain is able to make changes to the DNS records of that domain, SPF is an effective way to deter spoofed email being sent from "you".

Domain-based Message Authentication, Reporting & Conformance, or DMARC, though verbose, is probably the simplest thing to understand and avoid for an email sender such as yourself. All you need to do is buy a domain and use it for your outbound email when sending via a 3rd-party (like BenchmarkONE). Explaining DMARC is overly complex, but what it boils down to is this: a lot of the major companies that provide free email addresses realized that they were essentially offering spammers free accounts to use with no consequences.

The Yahoos, Hotmails, and Googles of the world decided that they were going to impose a new standard to prevent this from happening. This is why you have daily/hourly limits on how many emails you can send, or in some cases, how many unique recipients you can reach from those providers. You also cannot send unauthenticated email from those free domains. That means you'd need SPF/DKIM records that would allow any sending servers (like BenchmarkONE), which will obviously never happen. This means to use a 3rd party server like BenchmarkONE, you will need to use a domain you DO control, and anything sent from a yahoo.com, gmail.com, aol.com, etc. will fail DMARC standards and be sent to spam.

To keep it simple: use a company domain email address, not an @gmail, @yahoo, etc. when sending from BenchmarkONE.

So the three technologies in the email authentication stack each cover something different and singly inadequate, but together, you can assure that the email you received is actually from the person it claims (SPF), hasn't been altered in any way (DKIM), and isn't from a shady source that is trying to bypass standards by hiding behind a large corporation (DMARC). BenchmarkONE obviously recommends that all our customers take advantage of our free email authentication process to ensure maximum deliverability, and if you have any questions, we're happy to help.