Email protection using SPF, DKIM, DMARC and other methods

Has been a while since the emails are one of the most common way of communication and in many cases is the only way for official notification. But think for a moment, what may happens when someone sends an important email to your client using your domain name and even without using your email server? Or what will happen when someone sends you and email masked as your bank domain? That is not so easy because all major email providers have a very effective anti-spam technique.

How about your company?

You have to prevent these or other issues from happening on your company. Below are listed 15 security measures to implement on IT infrastructure and email delivery process. Consider this a checklist.

1 - Reverse DNS (PTR)

One of the basic security procedure that email servers do during negotiation is the check for reverse DNS (Domain Name System). Also, called PTR (Pointer records) resolves an IP address to a fully-qualified domain name (FQDN), basically the opposite of DNS. This is the same for multiple IPs and can be configured by the owner of IP address or your ISP (Internet service provider). This will increase IP reputation and make that even more trustworthy.

To check the PTR of an IP address in Linux use one of the following commands:

dig -x X.Y.Z.G

dig -x X.Y.Z.G | grep PTR

host X.Y.Z.G
The result will will be similar as the following: 21503 IN PTR is a special domain and IPv4 address are represented as a concatenated sequence of four numbers separated by dots.

2 - Dedicated public IP for email server(s)

Sharing email server's public IP address with the whole network (Other computers in company) will expose all already existing problems (or unpredictable problems) to the email delivery process. This is dangerous even if you have blocked SMTP ports for other computers. IP reputation can decrease mostly from abuse on SMTP ports (mostly from malware or spyware) but it is not limited on that.

3 - Sender Policy Framework - SPF

SPF mechanism is designed to detect email spoofing by checking the authorized hosts for specific domain. Each authorized sending host for specific domain is listed in it's DNS in form of TXT record.

A typical SPF in TXT record for domain looks like:

"v=spf1 ip4:X.Y.Z.G/24 ip4:X.Y.Z.G a -all"
You can add one IP, multiple IPs and also a whole subnet on this record.

Again, you can use dig to check this record:

dig -t txt

dig -t txt | grep TXT
The result looks like: 300 IN TXT "v=spf1 ip4:X.Y.Z.G/24 ip4:X.Y.Z.G a -all"
On the record above "v=" defines the version of SPF. The are some mechanisms to determine if a domain is eligible to send mail from actual host.

  • ALL - Matches always.
  • A - Check if the sender is an address record (A or AAAA) of the domain.
  • IP4 - Check if the sender is in a given IPv4 address range.
  • IP6 - Check if the sender is in a given IPv6 address range.
  • MX - Check if the sender is the same as any of MX records. Example: 300 IN TXT "v=spf1 mx a -all"
  • EXISTS - Will match any address resolved by domain.
  • INCLUDE - References the policy of another domain.
A mechanism can be combined with one of qualifiers:

  • + for a PASS result.
  • ? for a neutral result (like no policy).
  • ~ (tilde) for softfail, a debugging aid between neutral and fail. Messages with softfail are accepted but tagged.
  • - (minus) for fail (mail should be rejected).
A domain with available SPF record has less probability to be blacklisted or to used as a spoofed address for spam.

4 - DomainKeys Identified Mail - DKIM

Like SPF even this method is designed to detect email spoofing. DKIM provides to the receivers the necessary information to distinguish legitimate email from potentially spam. A public-key must be published to validate domain name identity associated with message through cryptographic authentication. Modern mail servers have builtin features to generate a public/private key pair required for this process. Then you have to create a TXT record in your DNS under "_domainkey" record.

Example of DKIM record:
The label "mail" (called selector or prefix) on DKIM Record is just an example, you just have to be sure the server is using the same prefix on it's DKIM configuration.

Content of DKIM record:

v=DKIM1; k=rsa; p={Public Key}
The server will add to message header a DKIM-Signature using his internal private key and the body will hashed. The recipient server have to match these two values (the value published on TXT Record and the value on DKIM-Signature inside message header) to prove that the mail was signed by the indicated domain and has not been modified with in transit.

5 - Domain-based Message Authentication, Reporting and Conformance - DMARC

DMARC is an extra policy that's indicate that emails generated from this domain are protected by SPF and/or DKIM and tells a receiver how to behave if the authentication methods doesn't passes (on both SPF or DKIM).

The content of this policy will be placed on the below TXT Record "". An DMARC record looks like:

v=DMARC1; p=none; sp=quarantine; pct=100;
The definition of keywords used on DKIM are:

  • v - The version.
  • p - The policy (none, quarantine, reject).
  • sp - (optional) Subdomain policy (none, quarantine, reject).
  • pct - (optional, default value is 100) The percent of emails to check (0 and 100).
  • rua - (optional) The URI to send aggregate reports to.
  • adkim - (optional, default value is r) Alignment mode for DKIM ( r = relaxed mode, s = strict mode).
  • aspf - (optional, default value is r) Alignment mode for SPF ( r = relaxed mode, s = strict mode).
  • fo - (optional, default value is 0) Failure reporting options ( 0 = Generate an DMARC failure report if all authentication mechanisms are not "passed", 1 = Generate an DMARC failure report if any authentication mechanism is not "passed", d = Generate an DKIM failure report if the message failed DKIM evaluation, s = Generate an SPF failure report if the message failed SPF evaluation ).
  • ri - (optional, default value is 86400) Request interval between aggregate reports.

6 - Antivirus for email server and for all network

As many hard we try to secure the email server it only takes a spyware in one of the clients computers (capable of reading email client configuration) to use your email infrastructure as a spam source.

7 - Antispam

Usually antispam service is integrated (module) with email server itself. This will protect your company from many untrusted or dangerous emails.

8 - SSL connection outside company

Email servers have builtin SSL and TLS encryption for SMTP/IMAP communication. You have to activate these immediately. If you are providing to your staff a web interface for emails (web email client) redirect all requests to SSL by default. Also, use SSL/TLS IMAP/POP and SMTP for all clients. Do not let anything to chance.

9 - Disable open relay

Open relay is a contributing factor to the volume of spam in around the internet. This will cause huge damage to IP and domain reputation.

10 - Limit number of sending per hour or day

If your email server has this configuration then is better to enable it. 400-500 email per day is more than enough. This will protect a little bit your IPs and domain reputation in case of user or spyware abuse.

11 - Periodically blacklist check

Do not consider this task unnecessary. Checking periodically the IP reputation is not a time-consuming and in many cases will help you preceded the worst scenario. There are many free web tools to do that for you.

12 - Update software

Whatever environment you are using you always have to update your operating system and email servers. There is not a perfect software and each day are discovered many security holes or bugs that may cause a very dangerous situation. This is the same even for email servers.

13 - Avoid naked domain for email marketing

First of all you shouldn't use your email server for email marketing unless this is your business scope. Create a subdomain and use that for email marketing, promotions or other notifications. This will save your domain reputation if many users mark these emails as a spam.

14 - Strong password

Just one insignificant email account with password can be enough not only to destroy IP (or IPs) reputation but also the whole domain.

15 - Weekly backup

There is no need even to mention this step but this list will not be complete without this undisputed task. Weekly backup is enough for every kind of business.