Spam filters are usually your best friend since more than 50% of e-mail in 2017 was spam.

Sometimes however the spam filters that are meant to protect us will turn against us. Sometimes there are valid reason for them to do so, especially if you recently sent one (or more) mass mailing that was not well received by the audience you sent it to.

You might however not be the only one sending mail using your domain. Spammers can use different techniques to abuse the authority your domain has built to their advantage. It is for this exact reason that you should be configuring your domain and mail servers correctly.

Luckily the people of the internet have developed techniques to counter these spammers, allowing you to take back control of your e-mail sending ability.

I’m going to walk you through the essentials for your domain, that is SPF and DKIM. After that I’ll be moving on to the tools you can use to define policies and monitoring for your domain using DMARC.

The basics

I’d like to make sure that the sections below make sense for most people, so I’ll be explaining some of the basics that make e-mail work. If you are familiar with the basics of e-mail and DNS you can skip right ahead to the next section.

Having gotten that out of the way, let’s dive in.

DNS

Domain-name (DNS) servers are the pieces of software that glue the internet we use everyday together. The textbook definition of DNS defines it as the service that translates a user-readable domain name such as evens.eu to its numeric, machine-readable address. DNS however can do a lot more and can even be used as a database for information, this information can be stored under a domain for which you are the owner (which is called Authoritative).

For the explanation below we are interested in 3 types of records that can be stored on a domain-name server that is under your control.

Below I’ll be using the dig command to retrieve some keys from DNS that are relevant for my domain. You can run these on your own computer if you are comfortable with a shell, alternatively you can use Google’s online dig or the DNS Lookup tool by whois.

The format of the dig output is as follows:

1

<domain>		<ttl>	IN	<type>	<record information>

This should be self explanatory for most except maybe the ttl and IN parts of the record. ttl defines for how long the information is valid and can be cached without validating it with the authoritative server. IN stands for Internet and indicates that we are working with internet addresses.

The A-record, or possibly the AAAA-record, is the glue we mentioned earlier and links a domain-name to its IPv4 address, for A-records, and its IPv6 address for AAAA-records.

1
2
3

$ dig -t A evens.eu
;; ANSWER SECTION:
evens.eu.		119	IN	A	178.21.112.148

The MX-record defines the mail exchange for the domain under which the key is published. This record points to the A-record that defines the address of the server that holds your e-mail. The records below show there are two mail exchanges that can handle e-mail for `@evens.euaddresses. The numbers that are added before the servers (`50` and10`) are numbers used to determine mail server priority.

1
2
3
4

$ dig -t MX evens.eu
;; ANSWER SECTION:
evens.eu.		119	IN	MX	50 evens.eu.
evens.eu.		119	IN	MX	10 smtp.evens.eu.

The TXT-record is going to be most of interest to us since this is where we will be storing the configuration for our domain. TXT-records allow you to store arbitrary text, in our case the text will be the configuration that keeps our domain safe.

1
2
3

$ dig -t MX evens.eu
;; ANSWER SECTION:
evens.eu.		113	IN	TXT	"v=spf1 a:uit.telenet.be mx:evens.eu -all"

DNS configuration is stored in a DNS server, but you will usually configure DNS entries in the administration dashboard of your hosting provider or domain registrar.

SMTP server

Whenever an e-mail is sent or received, it is done through the Simple Mail Transfer Protocol, or SMTP in short. The SMTP server that is responsible for delivery of e-mail addressed to you is defined in the MX-record of your e-mail domain. So if the domain evens.eu can receive mail there should be a MX-record that points to the mail server for evens.eu, smtp.evens.eu for example.

If you have configured your e-mail client correctly the same SMTP server is responsible to accept mail you send and ensure that it gets delivered to the recipients’ SMTP server. Because of this setup your SMTP server will see every mail you attempt to send, which is essential for SPF or DKIM to work.

Domain essentials

Currently there are two methods in wide use to protect your domain from unauthorized use. These are SPF which essentially defines a list of server that are allowed to send mail on your behalf. The other is DKIM which imprints a seal of approval into your e-mail in the form of a digital signature.

SPF: Sender Policy Framework

To understand the problem that SPF solves you need to understand that at its core email, the Simple Mail Transfer Protocol, does not have a way of checking whether the person sending the e-mail is who they say they are because the From header of a message can easily be spoofed.

SPF as mentioned earlier is a list of e-mail servers you use, mail servers receiving a mail will extract the sending domain from the sending e-mail address and look for an SPF record at the sender domain. If the server from which this message was received is not on the SPF list, the message will be marked as spam.

Now, what does an SPF record look like? An SPF record is published as a TXT-record in your domains DNS, with content that looks similar to the one shown below.

1

v=spf1 mx:evens.eu -all

There are two components to an SPF record

v=spf1

v=spf1 indicates that this is an SPF record using SPF version 1.

mx:evens.eu -all

mx.evens.eu -all is the actual list of e-mail servers that can send e-mails on behalf of my domain. My record specifies that the server listed in the MX record of evens.eu can send mail for evens.eu.

all specifies how to treat mail servers not on the SPF list and should always be specified last as it will always match a server.

The items in the list can be prefixed with one of four qualifier of which + is considered default if the prefix is omitted.

• + (Pass) will accept any mail server, even when not on the list.
• - (Fail) indicate that the server should not deliver the message to the user.
• ~ (SoftFail) indicate that the server should notify the user that the message is most likely spam.
• ? indicates that there is no information available about the server validity and that the mail server should accept the message.

There are different mechanisms that can be used to specify valid servers, these are listed in the mechanisms section on openspf.org.

Looking to generate your own? Use an SPF Generator online.

DKIM: DomainKeys Identified Mail

While SPF is based on a whitelist of valid sending servers for your domain, DKIM uses public-key cryptography to digitally sign your message before sending it of to its destination. The digital signature is generated using a private key which allows any receiving mail server to check the validity of the signature using the public key published in your domain’s DNS server. This public key ensures that the message was not tampered with while it was in transit to its destination and that it originated at a server authorized to send e-mails on behalf of the sending domain.

Generating your keys

In order to set up your mail server with DKIM signing you’ll need a valid private/public key pair.

You can find the script I use to generate my DKIM key pairs at this gist. This script will also generate an entry for your bind zone file if you run your own DNS server.

These commands will allow you to generate a private and public key on your own computer, the file ending with .key is your private key and should be kept in a safe place. The file that ends with .pub is the public key. We will be publishing the public key in a TXT record in DNS.

1
2
3
4
5

# Generate a private key
openssl genrsa -out dkim-evens.eu.key 2048

# Generate a public key derived from your private key
openssl rsa -in dkim-evens.eu.key -out dkim-evens.eu.pub -pubout -outform PEM

Configuring DNS

Public keys are required to be defined in DNS at a specific location in order for SMTP servers to verify the signatures. This location is dictated by both the sender domain and the selector that is configured in your mail server.

There should exist a TXT-record for the selector mail in DNS at mail._domainkey.evens.eu when you are sending e-mail for the evens.eu domain.

For those interested in an example, the mail selector for evens.eu looks like this, where the value following the p= parameter is the public key for this selector.

1
2
3
4
5
6
7
8
9
10

$ dig -t TXT mail._domainkey.evens.eu
;; ANSWER SECTION:
mail._domainkey.evens.eu. 116	IN	TXT	"v=DKIM1; t=y; k=rsa; p=" 
"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA33N+noMqwHiJQhYALo+o" 
"o4BNfOh58Jnn5EzdZsi9mx8aGVHBjuhlcka9JvWAzapYTXS36v8/yOhNXhyk/xwD" 
"0HvtpHEFBhPbQuxLGL9rNSXfVP4lAL3nDJJ2f+tr14MesXQvgLiA8QAqAJF+ugQK" 
"qA9KESD1nIqAzxl5t1voNawvckzdNBkiQ+G9T/V1eP21dfklKt8QVz1SMUGveQL/" 
"d4vj/S54viqMrvbxuYUnkGQDZr0gEXWzDlE05ZdJ7/FOnNG9V+ur2WS/T8o5Q/rw" 
"wzE6XcTJYlzW5fFlNaFDweuOZ0DPb2ErKx2FPEOsxkez4jYvIj82+vLPKqG4W3vk" 
"OQIDAQAB"

DKIM alignment

Once everything is set up and working you’ll find a header like the one below at the top of e-mails you sent. The header named DKIM-Signature is the digital signature that ensures that your e-mail was not changed while in transit. The DKIM signature contains a section specifying for which domain this signature is valid, for the signature below that is d=evens.eu. An e-mail is considered to be DKIM aligned when the sender domain matches that of the signature.

For DKIM to be effective we need our e-mail to be DKIM aligned, an e-mail which is not DKIM aligned contains a signature for a different domain than that of the sender. Such signatures don’t provide us any additional knowledge that helps us fight spam since there is no relation between either of these domains. A misaligned DKIM signature, valid or not, does not provide any authentication that is useful to a mailserver trying to determine if the sender is allowed to use the specified domain.

1
2
3
4
5

From: info@evens.eu
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=evens.eu; s=mail;
    h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From;
    bh=/id6JMFhkWrJk/m5coI7si1asGFCZTNU4ecgucr/M20=;
    b=kkeUfwuWXZPLizvoQVD...fQLTB39G9Hy+Q==;

An e-mail with a misaligned DKIM signature will have a set of headers like the next example, where the sender domain is evens.eu and the signature domain is example.org.

1
2
3
4
5

From: info@evens.eu
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=example.org; s=mail;
    h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From;
    bh=/id6JMFhkWrJk/m5coI7si1asGFCZTNU4ecgucr/M20=;
    b=kkeUfwuWXZPLizvoQVD...fQLTB39G9Hy+Q==;

Policy and monitoring

When you’ve come to the point where you have both DKIM and SPF configured you’ll want to monitor delivery of your e-mail and guard your domain’s reputation.

This is where DMARC comes into play, it allows you to set up reporting and defines actions to be taken when an invalid e-mail is received.

DMARC: Domain-based Message Authentication, Reporting & Conformance

A DMARC record is configured as a TXT record at _dmarc.evens.eu where evens.eu is the domain you are trying to protect. Similarly to SPF and DKIM the contents is a text string which represents the DMARC policy you would like to enforce for your domain.

1
2
3
4

dig -t TXT _dmarc.evens.eu
;; ANSWER SECTION:
_dmarc.evens.eu.	59	IN	TXT
	"v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@evens.eu"

• v=DMARC1 indicates that this TXT record configures DMARC, specifically version 1
• p=reject sets the policy for e-mail that fail either SPF or DKIM validation. Here it is configured to reject any invalid mail. Valid options are quarantine to move messages to a spam folder or mark them as spam, and none which simply allows messages to pass.
• pct=100 configures the percentage of invalid messages to apply the policy to. You can set this to pct=0 if you only want to monitor the health of your domain, this will disable any policy configured.
• rua=mailto:dmarc@evens.eu specifies where to send aggregated reports to. This is an e-mail address set up to handle DMARC reports from the different providers and parse them. dmarcian is a useful tool to manage these reports and convert them into nice readable graphs, alternatively you could use Postmark DMARC monitor.

Other tags are available to further configure dmarc which you can check out in RFC 7489.

Technical checklist

While we’ve covered the essentials required to protect your domains reputation there are still plenty of other precautions you should be taking to protect your domain and e-mail in general. Below are some bad practices that i’ve seen in the wild while helping small companies out.

Internet Service Provider SMTP server

I’ve seen many mail clients configured to use the ISPs mail server, usually because outbound SMTP traffic on port 25 is blocked to prevent spam from being sent using their network. There are however multiple problems with this setup.

• DKIM will not work. Your mail server needs to establish your identity using your private key, which your ISPs mail server should not have access to.
• SPF will be less effective. Listing your ISPs mail server in an SPF record will allow any customer of said ISP to send e-mail on behalf of your domain and pass the SPF check.
• Your e-mails are at the mercy of your ISPs mail reputation, which can be made to fluctuate when home users get affected by spam bots or other malware.
• You should not be using unencrypted SMTP traffic and are far better off using the secure TLS variants which usually run on ports accessible from any network.

Most mail providers have guides on setting up your mail client, check these to ensure you are using a secure connection (both for SMTP (outgoing) and POP3/IMAP (incoming) mail).

Open Relay

This is a section should be able to skip when paying someone else to run your e-mail server (like an e-mail / hosting provider). But if you happen to run your own e-mail server this is one of those issues that should be remedied immediately.

An open relay is a mail server that can be used to send e-mail even if the sender e-mail is unknown to the server. In practice this means that your server can be used to bounce spam off, quickly ruining the reputation of your server and IP causing any legitimate mail it sends to be sent to the spam folder.

Checking if you have an open relay is really easy and quick using the great MX Toolbox

TLS

TLS is the successor to SSL and you might know it from the lock icon in your webbrowser. The same technology is used to protect your e-mails while in transit, or at least it should be used.

Ensure that your mail server is configured to use TLS to communicate with other SMTP servers and your computer. Google is pretty harsh on mail servers that don’t understand or use TLS, and it is in your own best interest to ensure that your e-mail arrives without being tampered with or without anyone else reading along. Imagine a hacker reading those password reset e-mails!

Verifying if TLS support is enabled can be checked with MX Toolbox similar to the Open Relay check.

Conclusion

Well… this post turned out to be a bit longer than I initially had planned it to be, and it only discusses setting up your domain for personal e-mails. Bringing mass mailings, newsletters and more into the mix would add even more here so I’ll keep that for a separate post.

If you made it this far the following advise will probably speak for itself, but if all of this seemed overwhelming you are probably better off looking for someone who can keep these things in check for you.

Should you feel ready to get started setting up your domain, here are some more tools that help you check your configuration and check blacklists, reputation, message spamminess and protection.

Considering the size of this post there is a very real chance that I’ve made an error, please let me know if you spot one. I’m always happy to learn something new or correct any assumption I have about these tools.

Tools

• MX Toolbox, this website has been referenced multiple times throughout this post as it is a wonderful collection of tools to verify your server.
• Dmarcian, awesome tool to convert those DMARC reports into usable graphs.
• Postmark DMARC monitor, converts DMARC reports into a weekly e-mail containing the reports in a nice aggregated overview.
• Google Apps checker, if you use Google Apps as your e-mail provider this tool will verify that everything is configured as it should be.
• Google Postmaster Tools, if you are sending large amounts of e-mail you might want to sign up for the free Google Postmaster tool which will report on reputation and reported spam for your domains.
• ReturnPath’s SenderScore, will allow you to check your domain and IP reputation.
• mail-tester.com, allows you to test individual e-mail for signs of spam or badly configured servers.

References

• dmarc.org
• openspf.org
• dkim.org