SPF (Sender Policy Framework) is a standard that was created in order to stop and eliminate the forged or spoofed sender email addresses in the mail envelope SMTP MAIL FROM or Return-Path that commonly used in spam message. SPF works as an extension to the Simple Mail Transfer Protocol (SMTP), and allows relay MTA (Mail Transport Agent) to identify and reject those e-mail spam sent from unauthorized and unapproved mail server.

SPF enabled domain’s email delivery operation works in such a way: Owner of an Internet domain name defines SPF records using a special format of TXT records in the domain zone DNS name server. The SPF specifies which machines are authorized to transmit e-mail for that domain. When an email is received by a mail server, the MTA will query the SPF records from DNS resolver to determine whether the email is originated from a legitimate server. If SPF PASS result is returned, the email is accepted and got delivered. Else if SPF FAIL result is returned, the email is rejected and bounced. Most MTA currently doesn’t immediately bounce a SPF FAIL email, and instead tags it with SOFTFAIL while still accepting the email, most likely filtered as spam, as currently SPF implementation is not popular, and has a high potential of creating wrong SPF records.

Although SPF records is not a must, but it’s a good practice to set up the SPF records to stop spam fault from illegally spoof and forget your domain’s email address. As SPF, like MX, A, CNAME and PTR records, are part of DNS domain tree level, the domain owner will have to have full control to the domain DNS zone authoritative server in order to create this record. Most importantly, some IPSs such as AOL and BellSouth now require valid SPF record for inclusion in their whitelist program. Sender ID records will soon be required by Microsoft for unaltered MSN/Hotmail delivery.

The major issue for SPF records are how to write and create a properly SPF record which is valid and correct for the domains, as all SMTP server that sends email for the domains must be defined. Typically, the DNS syntax for a SPF record looks like following:

example.com. IN TXT "v=spf1 a mx -all"

It’s pretty hard to understand. Luckily there are tools that help webmasters and domain administrators to easily setup a valid SPF DNS entries. OpenSPF offers Record Setup Wizard (retired) and Microsoft has Sender ID Framework SPF Record Wizard (no longer available). Although both a wizard, it may still pretty hard to comprehend especially for people exposed to SPF for the first time or novice. Here are some brief explanation of what each questions in the wizards are meant.

Note: Most of the SPF records creation wizards have been disabled, but the following guide may still be useful to help you understand the content of SPF records.

First, you must enter the domain name (e.g. example.com) that you want to set up the SPF record. The wizard will then try to retrieve if there is any existing SPF record. If existing record is found, the wizard allows you to modify it, or you can continue to set up the SPF by answering several questions.

For this guide, we will follow Microsoft Sender ID Framework SPF Record Wizard, and cross reference to OpenSPF’s wizard, and OpenSPF’s wizard options can be easily identified by using the symbol A, MX, PTR and etc which are clearly marked.

If the domain does not send any email, check Domain Not Used for Sending E-Mail. All other fields are instantly disabled and grayed out, as it’s no longer useful (and not valid) to define other mechanism. To achieve this options in OpenSPF wizard, mark all radio button as “No”, except the last one (~all) as “Yes”.

If the domain mail server is also the one defined in MX record, check Domain’s inbound servers may send mail in Inbound Mail Servers Send Outbound Mail section. In the same section, the detected MX server host name is displayed. If you have multiple mail servers defined in MX records, and want to specifically allow only some of them to relay mail for the domain, then uncheck the previous option, and tick all the valid outbound e-mail server for this domain. The above two options is represented by mx (green) and mx: (light green) in OpenSPF. Beside, if the domain route emails through the MX server of another domain, such as the ISP, specify the domain names in the box provided too (also as mx: in OpenSPF).

For Outbound Mail Server Addresses, if all the domain web servers (as configured in DNS A record) is also the mail server, then tick the All addresses listed in A records may send mail option. The IP addresses of the detected A record is displayed. Again, if you just want to specify few IP addresses as authorized mail server, select them. You can also enter any additional IP addresses (or ranges of addresses) you wish to add to your SPF record (one address or address range per line), and any additional domain names whose A records refer to valid outbound e-mail servers for the domain. This represent a (green), ip4: and a: (light green) on the OpenSPF wizard.

You can also specify that if a mail server IP address is resolved to your domain name after reverse DNS lookup, it can send the email by ticking All PTR records resolve to outbound email servers. Enter any domain names whose PTR records resolve to valid outbound e-mail servers in the text box provided. In OpenSPF, only PTR is provided, and not PTR: which allows you to enter more domain names. And it suggests that this option is expensive, unreliable and not recommended.

If you have mail sent on behalf of the domain is at times actually delivered to its recipients by the computers of another domain, then fill in the text box in Outsourced Domains section the additional domain names whose SPF records refer to valid outbound e-mail servers. This translate to include: in OpenSPF.

The final section has this question “Does example.com send e-mail from any IP addresses that are not identified in the above sections?” or “Do the above lines describe all the hosts that send mail from surfnova.com?”. This question will translate to one of the following qualifiers for ALL mechanism, which describe how the mail server not matched with SPF record is handled:

  • + for a PASS result, this can be omitted.
  • – for FAIL, the mail should be rejected.
  • ? for a NEUTRAL result interpreted like NONE (no policy).
  • ~ for SOFTFAIL, a debugging aid between NEUTRAL and FAIL.

OpenSPF wizard allows only selection of Yes (~) or No (-).

In any case, the Scope section should select Both setting to support all email identities validation, including Purported Responsible Address (PRA) derived from RFC 2822 message headers and MAIL FROM (or reverse-path) address derived from the RFC 2821 protocol’s MAIL command.

Continue next the wizard will generate the SPF record. You will notice that all SPF record start with v=spf1. “v=” defines the version of SPF used, and is mandatory to identify it’s the SPF record. Currently only the only version supported is spf1.

Once get the SPF record, copy and paste the text to the DNS entry as a TXT record. Depending on your DNS system, you may have to exclude the quotation mark (“) when entering the text in DNS system, although the wizard will put the entire text within the quotes.

For those who interested, you can read the definition of A, IP4, MX, PTR and other mechanisms here:

ALL: Matches always, used for a default result like -all for all IPs not matched by prior mechanisms.
A: If the domain name has an A (or AAAA for IPv6 ) record corresponding to the sender’s address, it will match. (That is, the mail comes directly from the domain name.)
IP4: Use IPv4 addresses for verification, match if the sender is in a given IPv4 range.
IP6: use IPv6 addresses for verification, match if the sender is in a given IPv6 range.
MX: If the domain name has an MX record resolving to the sender’s address, it will match. (That is, the mail comes from one of the domain’s mail servers)
PTR: If the Forward Confirmed reverse DNS domain of the sending IP ending in the domain name.
EXISTS: If the given domain resolves, match (no matter the address it resolves to). Rarely used, along with the SPF macro language it offers more complex matches like DNSBL-queries.
INCLUDE: If the included (a misnomer) policy passes the test this mechanism matches. This is typically used to include policies of more than one ISP.

Actually all of the above mechanisms can mix and match with 4 qualifiers mentioned earlier. But due to the limit of wizard, not all options are available. And for complicated use, there are modifiers such as REDIRECT. And normally, when one condition is matched, the email will get a PASS. So if your mail system is simple, simply define the MX or IP address will work as mentioned.

For example, techjourney.net has the following SPF record, “v=spf1 ip4:75.127.69.98 mx a:host.techjourney.net mx:mydigitallife.info ~all”. A lot of duplication, but at least the email will send correctly.

To check if your SPF record is correct, there are various SPF checker, tester or validator available.

You May Also Interested In: