Spoofing is a type of a computer attack in which the attacker pretends to be someone else. In particular, email spoofing is an attack in which the attacker sends an email with a fake “From:” field. You can compare it to sending a traditional mail with forged return address.

If you are using one of the popular email services such as Gmail or Yahoo, you don’t need to worry about that. These providers keep security on the high level. But if you are just the owner of an internet domain, you should be aware of the spoofing vulnerability (even if you don’t send emails on your own).

What is SPF (Sender Policy Framework)?

SPF is an email protocol that prevents third parties from pretending to be the owner of the domain they do not actually own.

It boils down to placing a small piece of information in a DNS TXT field which defines which IP addresses are allowed to send emails from this domain.

Here’s a quick example of the Gmail’s DNS TXT record:

**>> dig gmail.com TXT**
gmail.com. 278 IN TXT "v=spf1 redirect=_spf.google.com"

The redirect attribute means that all SPF records for this domain are defined on another domain. The v attribute defines the SPF protocol version.

So let’s check the record of the _spf.google.com domain:

**>> dig _spf.google.com TXT**
_spf.google.com. 109 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

include means that 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. If the domain does not have a valid SPF record, the result is a permanent error.

Let’s dig deeper:

**>> dig _netblocks.google.com TXT**
_netblocks.google.com. 3247 IN TXT "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ~all"

SPF check is passed when sender’s IP matches one of the ranges. If not, it proceeds to the next directive.

Let’s check what’s returned in the next lookup:

**>> dig _netblocks2.google.com**
_netblocks2.google.com. 3599 IN TXT "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

This domain has directives for validating IPv6 protocol.

**>> dig _netblocks3.google.com**
_netblocks3.google.com. 3599 IN TXT "v=spf1 ~all"

If the sender’s IP is missed by all directives, the v=spf1 ~all flag comes into action. The flag means that even when the SPF fails, the domain holder doesn’t want to get rid of the message, but mark it as a possible fail instead.

The SPF protocol specifies 4 qualifiers:

+ pass
- fail
~ soft fail
? neutral

These qualifiers can by placed before any directive. The default qualifier is +. All directives are processed in order.

So if you spotted that someone is sending email from your domain, but you don’t send any email on your own, just use the "v=spf1 -all" SPF rule. It says that the domain does not send any mail at all. All servers that support SPF rules will reject emails coming from your domain.

There’s one important thing to be aware of when configuring SPF. Using SPF breaks plain message forwarding (Wikipedia explains that problem in details).

What’s interesting, Gmail uses a workaround when you forward a text email using their platform. They don’t stick to that buggy standard. Instead, they just send an email on your behalf, prepend the “Re: ” text to the email subject and quote previous emails in the body.

To read more about the syntax of SPF records, check out the following address: http://www.openspf.org/SPFRecordSyntax