Remember back in the days when people declared, “We will fight spam and stop it?” It’s 2016, and spam is still a huge annoyance for the average user.

Despite all the good intentions and technical measures, we are still unable to properly filter unwanted messages and keep our mailboxes clean. The use of blocklists, such as Spamhaus and SpamCop, is efficient, but it often turns into a game of whack-a-mole.

The experience has taught us that unsolicited mail cannot be minimized using just a single tool or solution. Rather, it takes a combination of different techniques to reduce unwanted mail. Removing it all together is nearly impossible, but we can limit the burden it puts on us and on our computer cycles.

Limiting the amount of unwanted messages also has a positive influence on your overall security health. A lot of malware is still being sent via spam; keeping these messages out of your users’ mailboxes prevents further mayhem.

This article covers two techniques that can be used to limit the amount of spam messages.

SPF: Sender Policy Framework

Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. The current version of SPF is SPFv1, which protects the envelope sender address. The detailed SPF specifications can be found in RFC 7208.

SPF uses a DNS TXT record in the DNS zone file to limit the number of servers that are allowed to send email on behalf of a domain name. Basically, this is tells the receivers, “messages for my domain should only come from these servers.”

SPF is concerned with the identity of the sender of a mail message, or the “mail from” header, which is specified in the RFC 5321.

Basic and Designated Mechanisms

An SPF record consist of two blocks, called mechanisms. Basic mechanisms contribute to the framework but do not designate a specific authorization scheme; they can, for example, instruct SPF to look up external SPF records. Designated mechanisms are used to identify a set of IP addresses as being permitted or not permitted to send email.

Below is an example of an SPF record for an example domain:

IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"


This record tells us that the IPv4 addresses 192.0.2.1 and 192.0.2.129 are allowed to send email for the designated domain. With the use of “-all,” we stress that only mail that matches this pattern of IPv4 addresses is allowed.

DKIM: DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. It is a way to sign and verify email messages at the message transfer agent (MTA) level using public and private keys. The public keys are published in DNS TXT records. DKIM authenticates the source and its contents.

From a high-level point of view, the sender signs the message, both headers and content. The owner of the private key is the only one who should be able to create this signature. The receiver then extracts the signature from the headers, queries DNS for the public key and checks the validity of the signature. Because the data is stored in the DNS servers, only the rightful owners of the domain should be able to set up the public/private key pair and publish the public key.

The detailed specifications of DKIM can be found in RFC 5585.

DKIM in Action

In practice, the receiver verifies the sender information by doing a DNS query for a TXT record consisting of “selector” + _domainkey + “domain.” The selector is set in the message and defines the actual DNS query for getting the TXT RR postpended with _domainkey.

For example, the following DKIM signed message contains this signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org;

s=jthatj15xw2j; t=1465810252;

bh=mnbz6sj/NAGt4x6LkdBtuoAzQVNWxOFHr2z82XGy4cw=;

h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:Sender: Reply-To:Cc:In-Reply-To:References;

b=mmrlKuMBWi/zG0ncZFIrsh5xTN10q ...

This particular message results in a DNS query:

$ dig -t TXT jthatj15xw2j._domainkey.cert.org +short

"v=DKIM1\; g=*\; k=rsa\; t=y\;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN ...

It’s All in the DNS

Both mechanisms make heavy use of DNS, or the domain name system. DNS is a decentralized naming system for computers. DNS is at the core of our current internet; it resolves human-understandable names to computer-understandable names and vice versa.

It comes as no surprise that having a reliable, secure, well-protected and well-maintained DNS infrastructure is essential — not only for these spam protection mechanisms, but for the sake of having a proper and reliable internet presence.

In normal circumstances, the DNS records can only be changed by the domain owners. If the filtering data, be it either SPF or DKIM, is published in these DNS records, you can be relatively confident they are put there by the legitimate owner.

Not a Spam Filter

This might come as a shock, but neither SPF nor DKIM are spam filters. They merely help you (and, in fact, the servers that route email) decide if a certain message is likely to be an unwanted email message or not. Both mechanisms contribute in the process of verifying that the source of an email is not falsified. As such, SPF and DKIM can help in protecting against phishing, but it would be foolish to utilize them as your only line of defense.

Spammers can also make use of SPF and DKIM to give more value to their messages. They are able to bypass some verification steps by utilizing disposable or compromised server infrastructure. This is important: Passing an SPF or DKIM check should not prompt you to disable all the other security checks.

SPF and DKIM do not deal with the end users. Both mechanisms operate at the server level, and most users will not even notice that they are in place.

Attacks Against SPF and DKIM

Although they are designed for resilience, both mechanisms can also be attacked. SPF records themselves can be used to launch attacks. By including a reference to a victim in an SPF record, an attacker can cause receivers to launch DNS queries against the victim’s infrastructure. Because the verifiers conduct these DNS queries and not the attacker, this leaves room for attackers to hide their true source.

Similarly, actors can launch DNS lookup amplification attacks by using the “a” or “mx” SPF mechanisms. Attackers merely have to include the records of their intended victims.

By itself, DKIM does not provide protection against replay attacks on messages that already have a verified signature. This means that someone can resend a message with the original signature remaining verifiable, but with new headers inserted by the attacker. Some of these newly inserted headers will break RFC 5322 compliance, but this is of little concern to cybercriminals. As long as the mail servers process the message, their goal is achieved.

The signer can provide protection by listing the headers that are only allowed to appear once (see section 8.15 RFC 6376). This is done by adding this email header twice to the ‘h’ tag.

For example, the list of signed email headers should not be in this format:

h=From:Subject:Date:To


Instead, it is more advisable to use:

h=From:From:Subject:Subject:Date:To:To


Using SPF and DKIM to Squash Spam

Implementing SPF and DKIM is not hard: You just need a bit of planning, inventory data and, obviously, some time.

SPF requires little or no effort; the biggest issue is probably getting to know what servers you are using to send email. Proper inventory and configuration management can help you with this. You can use the Sender Policy Framework website to get additional information on the exact syntax that needs to be used together with a set of tools for testing and implementing SPF records.

DKIM requires a bit more work and planning ahead, but with the right help, it’s a hurdle that you can pass without too much of an effort. Google support pages already contain a set of information, but you should certainly point your attention towards the DKIM website for technical details and operational issues.

A Collaborative Process

Despite possible attacks on the protection mechanisms, SPF and DKIM do serve a real purpose in limiting the amount of unsolicited email that ends up in your users’ mailboxes.

It is important to look at spam filtering as a collaborative, multistage process. The solution for spam protection is not just one technology; it’s a combination of different technologies that all add up to mark a specific message coming at a specific time frame as reasonably safe — or not.