There are various options we can adopt to ensure email authentication. When using emails, it is essential that we should enable email authentication for our email accounts otherwise, the email reputation of your domain/IP address may fall down. There are various email authentication techniques. Setting SPF and DKIM records are important and inevitable in these methods. What do they actually do? How it will protect your domain? How to validate these records? We are going to see the SPF and DKIM records in detail in this article.

What are SPF and DKIM records?

The SPF stands for Sender Policy Framework and the DKIM is the abbreviation of Domain Keys Identified Mail. The both are DNS TXT records. It is easy to set the SPF and DKIM records from your cPanel. You can get a wonderful guide line here:

https://www.WebHostingPeople.net/tips/kb/enabling-spf-dkim-record-cpanel/

This page also describes what are SPF and DKIM records, but to continue, we need to state here what are these records.

SPF

The SPF stands for Sender Policy Framework. This TXT record in a special format, is intended to prevent sender address forgery. Have you ever received bounce back messages saying one or more emails have failed to deliver to a list of email addresses which you’ve never heard of? This type of spoofing in the place of sender is called sender address forgery. This can be prevented with the SPF record. This record indicates which mail server is authorized to send emails for a domain. When delivering the emails, the recipient email server will check whether the email is coming from the authorized server or not. If not, it will be considered SPAM.

DKIM

Coming to the DKIM, it stands for the Domain Keys Identified Mail. It also uses TXT record in a special format. The DKIM uses a private and public key pair. When this pair is generated, the public key is updated in the TXT record. When an email is sent, the email is signed with the private key. This can be validated by the receiving email server or the ISP with the public key that is already updated in the DNS TXT record. This is the working of the DKIM.

The SPF Record Syntax

In the SPF, the domains define zero or more mechanisms. These mechanisms are used to specify which a email servers are authorized to send emails for the domain. The list of available mechanisms is given below.

all | ip4 | ip6 | a | mx | ptr | exists | include

There are also modifiers. The modifiers are listed below. In the SPF, each modifier can appear only once in the record.

redirect | exp

Mechanisms

There is another term called qualifiers. The mechanisms can be prefixed with one of the four qualifiers. The below list describes available qualifiers.

“+”       Pass

“-”        Fail

“~”       SoftFail

“?”       Neutral

If the mechanism resulted in a hit, the qualifier value associated with it is used. The default qualifier is ‘+’ and it means ‘pass’. Let’s see some examples.

“v=spf1 -all”

“v=spf1 a -all”

“v=spf1 a mx -all”

“v=spf1 +a +mx -all”

The mechanisms are evaluated in the order. If no modifier or mechanisms in the record matches, the default result is neutral. Suppose the domain has no SPF record, the result is none. When the DNS processing is taking place, if there is a temporary error, you will get the result ‘TempError’. If there is some syntax error or evaluation error occurs, the result will be ‘PermError’. Formerly, it was ‘unknown’. This will be true in the case if the domain specifies an unrecognized mechanism.

The ‘all’ mechanism

It will be present at the end of the SPF record. This mechanism always matches. For example:

“v=spf1 mx -all”

Allow domain’s MXes to send mail for the domain, prohibit all others.

“v=spf1 -all”

The domain sends no mail at all.

“v=spf1 +all”

The domain owner thinks that SPF is useless and/or doesn’t care.

The ‘ip4’ mechanism

Here, the argument to the mechanism is an IPv4 network range. If no prefix-length is given, /32 is assumed as the value. For example:

“v=spf1 ip4:192.168.0.1/16 -all”

Allow any IP address between 192.168.0.1 and 192.168.255.255.

The ‘ip6’ mechanism

Here, the argument to the mechanism is an IPv6 network range. If no prefix-length is given, /128 is assumed as the value. For example:

“v=spf1 ip6:1080::8:800:200C:417A/96 -all”

Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.

“v=spf1 ip6:1080::8:800:68.0.3.1/96 -all”

The “a” mechanism

In this case, all the A records for the domain are tested. This mechanism matches if the client IP is found among them. When the domain is not specified, the current-domain is used. If a prefix-length is not provided, the A record needs to match the client IP exactly. For example:

“v=spf1 a -all”

The current-domain is used.

“v=spf1 a:example.com -all”

Equivalent if the current-domain is example.com.

“v=spf1 a:mailers.example.com -all”

Perhaps example.com has chosen to explicitly list all the outbound mailers in a special A record under mailers.example.com.

“v=spf1 a/24 a:offsite.example.com/24 -all”

If example.com resolves to 192.0.2.1, the entire class C of 192.0.2.0/24 would be searched for the client IP. Similarly, for offsite.example.com. If more than one A record were returned, each one would be expanded to a CIDR subnet.

The “mx” mechanism

In this case, all the A records for all the MX records for the given domain are tested in order of MX priority. If the client IP address is found among them, this mechanism matches. If a prefix-length is not provided, the A record needs to match the client IP exactly. For example:

“v=spf1 mx mx:deferrals.domain.com -all”

Perhaps a domain sends mail through its MX servers plus another set of servers whose job is to retry mail for deferring domains.

“v=spf1 mx/24 mx:offsite.domain.com/24 -all”

Perhaps a domain’s MX servers receive mail on one IP address, but send mail on a different but nearby IP address.

The “ptr” mechanism

Here, the host name or host names of the client IP address are looked up using PTR queries. Then the host names are validated. Here, at least one of the A records for a PTR host name must match the original client IP. Invalid host names are discarded. The current-domain is used, if the domain is not specified. For example:

“v=spf1 ptr -all”

A domain which directly controls all its machines (unlike a dialup or broadband ISP) allows all its servers to send mail. For example, hotmail.com or paypal.com might do this.

“v=spf1 ptr:otherdomain.com -all”

Any server whose hostname ends in otherdomain.com is designated.

The “exists” mechanism

It will perform an A query on the provided domain. If a result is found, this constitutes a match. Here, the lookup result doesn’t matter. When you use macros with this mechanism, you can perform RBL-style reversed-IP lookups, or set up per-user exceptions. In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

“v=spf1 exists:example.com -all”

If example.com does not resolve, the result is fail. If it does resolve, this mechanism results in a match.

The “include” mechanism

Here, the specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

“v=spf1 include:example.com -all”

If example.com has no SPF record, the result is PermError. Suppose example.com’s SPF record were “v=spf1 a -all”. Look up the A record for example.com. If it matches 1.2.3.4, return Pass. If there is no match, other than the included domain’s “-all”, the include as a whole fails to match; the eventual result is still Fail from the outer directive set in this example.

Trust relationships

The ‘include:’ mechanism is meant to cross administrative boundaries. Great care is needed to ensure that ‘include:’ mechanisms do not place domains at risk for giving SPF pass to messages that result from cross user forgery. ‘include:’ mechanisms should give a Neutral rather than Pass result. This is done by adding ‘?’ in front of ‘include:’. So the above example will be as below.

“v=spf1 ?include:example.com -all”

ie., the name ‘include’ was poorly chosen. Only the evaluated result of the referenced SPF record is used rather than acting as if the referenced SPF record was literally included in the first.