Say Google’s or Yahoo’s mail transfer agent (MTA) retrieves an email sent from an MTA running on the host with the (fictional) IP address
184.108.40.206. Say the sending MTA identifies itself as sending on behalf of
important.com (within the EHLO/HELO handshake, or with a
From address with the domain
important.com). Then the receiving MTA (Google or Yahoo, or something else) usually queries the
important.com domain via DNS for the so-called SPF (Sender Policy Framework) record. Using this SPF record the retrieving MTA can verify whether the owner of the domain
important.com intended to send mail from
220.127.116.11 or not.
The SPF record might say that
important.com does not send mails. Then the receiving MTA knows for sure that the incoming mail is invalid/fake/spam. Or this record says that
important.com actually sends mail, but only from the (fictional) IP address
18.104.22.168. Then the retrieving MTA also knows for sure that something is wrong with the mail. Another possibility is that the record states that
important.com actually sends mail from
22.214.171.124, in which case the incoming mail likely is intended by the owner of the domain
important.com. This does not mean that this mail is not spam, but at least one can be quite sure that nobody crafted that mail on behalf of
That was a simplified description for why it is important to have a proper SPF record set for a certain domain in case one intends to send mail from this domain. In the next paragraphs I explain how I have set the SPF record for
gehrcke.de and why.
SPF record for gehrcke.de
Domainfactory is the tech-c for
gehrcke.de. However, the DNS entries for gehrcke.de are managed by Cloudflare (free, and quite comfortable). Today, I added an SPF record for
gehrcke.de via Cloudflare’s web interface. The first important thing to take note of is that the SPF record actually is a TXT record. There once was a distinct SPF record proposed, but in RFC 7208 (which specifies SPF) we clearly read:
The SPF record is expressed as a single string of text found in the RDATA of a single DNS TXT resource record
SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. Use of alternative DNS RR types was supported in SPF’s experimental phase but has been discontinued.
By now it should be clear that I had to add a new TXT record for
gehrcke.de, with a special syntax, the SPF syntax. This syntax is specified here. What I need to express in the record is that mail sent on behalf of
gehrcke.de is only sent by the machine with the IPv4 address
126.96.36.199 / or from the IPv6 subnet
fe80::5054:8dff:fe9b:358d/64. This is the machine that I know should send mail. No other people / machines should send mail on behalf of my domain. The corresponding record is:
v=spf1 ip4:188.8.131.52 ip6:fe80::5054:8dff:fe9b:358d/64 -all
v=spf1 declares the SPF version, the
ip6 markers declare that mail from a certain address or subnet are valid.
-all expresses that mail from all other hosts is disallowed. The fact that I do not “allow” others to send mail on behalf of
gehrcke.de is just my declaration of intent. A retrieving MTA is not required to respect my SPF record. However, larger mail providers should respect it and at least classify a mail that does not pass the SPF test as spam, if not reject it right away.
Whenever I switch machines or IP addresses, I need to remember to update this record. This is a minor disadvantage. To circumvent this, in many cases a short
v=spf1 a -all
would be enough. It expresses that mail sent from the IP address corresponding to the DNS A record of the domain is allowed. In my case, however, this does not work since the A record points to Cloudflare’s cache rather than directly to my machine.
Testing the record
There are many web-based tools for checking whether a certain domain has an SPF record set and whether its syntax is valid. Particularly useful is, for instance, mxtoolbox.com/SuperTool.aspx. However, a real full-system validation obviously requires you to send a mail to an external service that resembles a serious mail provider and debugs the communication for you, meaning that it informs you about all externally visible details of your mail setup, including the SPF record. A great verification tool that does exactly this is provided by Port25. On the command line I used my local MTA (Exim4) to send mail to their service, instructing them to return the corresponding report to may Googlemail address:
$ echo "This is a test." | mail -s Testing firstname.lastname@example.org
The following is an excerpt of the test result, indicating that the actual mail sender matches the data provided in the SPF record:
HELO hostname: gurke2.gehrcke.de Source IP: 184.108.40.206 mail-from: email@example.com ---------------------------------------------------------- SPF check details: ---------------------------------------------------------- Result: pass ID(s) verified: firstname.lastname@example.org DNS record(s): gehrcke.de. SPF (no records) gehrcke.de. 300 IN TXT "v=spf1 ip4:220.127.116.11 ip6:fe80::5054:8dff:fe9b:358d/64 -all"