A Little History

The internet’s creators didn’t really worry about security back when they were developing this fantastic new technology. Why think about safety when there were only a few hundred people in the world

with access to tools like FTP, Usenet, email, and Gopher. But as we know, email soon became the internet’s first killer app, the one that everyone needed to have, and before long, we had spam.

The first spam message was sent in 1978 – not by email, but as a posting in a Usenet group. In those early days, spam was simply unwanted advertising in a system that was seemingly free to most users. Spam quickly moved to email and rapidly became a huge problem.

Some 30 years later, in 2010, spam email had grown to nearly 85% of all email crossing the Internet. To make matters worse, the nature of spam changed. It morphed into a way to spread scams and malware, or to conduct phishing attacks against recipients and their employers. Spammers often attacked companies with email sent via their own insecure email servers.

Solutions: Sender Policy Framework

Around 2002, tech leaders started to discuss ways to address the Spam problem. The result was a set of new standards for email servers to help prevent spam. The first of these was the sender policy framework (SPF).

The following description is greatly simplified, but it should provide an overall understanding of how SPF works. By default, the simple mail transfer protocol (SMTP), which sends and receives your email , accepts mail from any sender claiming to be from any source and then sends it to the desired recipient. This prevents the recipient from being able to identify the email’s source and allows the sender to pretend to be another entity.

The idea behind sender policy framework (SPF) is to allow the domain owner to identify those servers allowed to send mail on its behalf. This magic happens by adding a line to the email server’s domain name system (DNS) record. It converts a name like mymail.example.com to an internet protocol (IP) address, a set of numbers like 1.2.3.4 (IPv4). The line added to the DNS record includes a list of the mail servers allowed to send mail on the behalf of the domain, in this case example.com.

When a message arrives at an email server, it can use DNS to retrieve the SPF record based on the envelope-from part of the message. From there, it’s easy to check a message to ensure it came from an authorized sender and reject it if it didn’t.

Domain Keys Identified Mail

But how do you know where the mail really came from? Domain keys identified mail (DKIM) uses digital signatures to determine where the mail is from and that key portions haven’t been changed since it left.

The sending server creates a digital signature using a private key. The email headers identify what elements within the message are included within the signature. Anyone with the public key, which, like an SPF, is stored in a line added to the DNS record, can validate the signature using that key. When the email arrives, the receiving server makes a DNS query to retrieve the public key and validate the signature.

Including the sender’s full email address in the signing process is a common practice. This positively identifies the message’s actual sender, not just the domain.

Domain-based Message Authentication and Reporting Conformance

What DKIM doesn’t do is tell us what to do with mail that fails the signature validation. That’s the job for domain-based message authentication and reporting conformance (DMARC).

This process lets us tell the receiving server what to do when a message fails the SPF or DKIM tests. The choices are:

• Reject: Discard and report.
• Quarantine: Store the message apart from others for later recovery and review, then report it.
• None: Take no action, but report the message.

DMARC instructs the receiving server to consider if the message will pass if SPF and DKIM are both true or if either one is true. The DMARC record also provides information that tells the sending server how the domain owner would like it to report. This allows a sending server that hosts many domains to act accordingly for each domain.

When enabled, reporting periodically sends emails to a configured address that monitors email failures. Other instructions include sending rejection emails as a response to the original sender.

How does all this get set up? By DNS, of course. The instructions are stored in a DMARC text record in DNS just as they are for SPF and DKIM and read by making a DNS call to retrieve the records needed.

What’s Next?

First thing, check to see if you’re already protected from spam. Experienced users can turn to tools like dig (on Linux) or nslookup (both windows and Linux) to query DNS and look for the TXT tags with SPF, DKIM, or DMARC. Less experienced folks might search for “test dmarc” on a favorite search engine and use a helpful site near the top of the results. Dmarcian.com worked well for me. You can also check for SPF and DKIM while you’re there.

If these show that you aren’t using DMARC, DKIM and SPF, it’s a good idea for you to investigate why not and get this fixed. It shouldn’t take long, but that will depend on your network’s size and complexity.

Is that all? No, you should also check your partners, to ensure their networks are safe and won’t be endangering yours. Encourage them to adopt this security technology too.

Are you done yet? Not really! When you’re checking email security, make sure your servers and email clients are configured to use the current implicit secure network ports for client server email connections. The current standards in RFC-8314 are port 995 for POP3S, 993 for IMAPS, and both 465 and 587 for SMTP. Also, make certain your SMTP server requires authentication to send mail. It’s best to require multi-factor authentication (MFA) for logins.

Is that all now? Yes, that’s all folks!