What is SPF? #
SPF stands for Sender Policy Framework, an email authentication protocol that helps prevent spam, spoofing, and phishing. SPF works by allowing domain owners to create an SPF record in their Domain Name System (DNS) that identifies which mail servers and domains can send email on behalf of their domain. Receiving servers then use this SPF record to verify that incoming emails appear to be from authorized servers. SPF is an important part of email security because it helps protect domain owners from having their domains misused by malicious actors.
Domain Controlled #
SPF records are created and controlled by the domain owner. When checking SPF, remote email servers follow the instructions outlined in the SPF record. For example, one domain owner can specify that any email coming from an unlisted mail server be rejected. This is called a fail in the SPF world. Another domain owner might specify that even if the verification fails, accept the email anyway. This is called a softfail in the SPF world.
So, even with an SPF record in place email can be spoofed if the SPF record for the sending domain has lax restrictions. As an administrator, you cannot control what other domain owners do with their SPF records. However, with Mailborder you can decide how to take action based on those records.
Mailborder SPF Handling #
As of Mailborder version 5.3.0, the SPF settings for the entire Mailborder cluster are located with in the Master GUI. As of this writing, the location is here: [ Master GUI > top menu > transport > SPF Settings ]
The settings allow you as an administrator to be less or more strict with SPF rejections. It is all too common for remote domains to have a policy of “softfail”. Again, this means accept the email even if it fails the SPF check. Under normal circumstances the softfail policy should only be used during testing. However, much too often this is left as a permanent setting resulting in the domain to easily be spoofed.
Another common situation is for a remote domain to not have an SPF record at all. Technically, this is still valid. However, any domain sending email should have an SPF record. You probably do not want to accept email from a remote domain that cannot even meet the most basic of standards.
SPF Reject Mode #
SPF Reject Mode is a setting within the Master GUI that allows you to specify how every server in the Mailborder cluster handles SPF records. The standard, and very lax, default is to only reject on SPF fail. Below are the Mailborder modes listed from most strict to least strict.
| strict | – Reject if the sending domain has no SPF record (None), Neutral, Softfail, Fail |
| softfail | – Reject if result Softfail or Fail (recommended) |
| fail | – Reject on SPF Fail (default) |
| never | – Never reject/defer and prepend header with result |
Which mode you select depends on your needs. The default mode is “fail”. However, we recommend either “softfail” or “strict”. Strict mode will keep the most garbage email out, but you could have a business partner that just can’t their SPF records right. However, you could still run strict mode with a whitelist exception for that domain. Running with “softfail” will allow you to reject email that does fail the checks, but would otherwise be accepted because of the lax settings in the remote domain’s SPF record.
Recommended setting: softfail
Permanent Error Handling #
This error occurs when the sending domain’s SPF record is broken for some reason. Common causes are having more than one SPF record, too many DNS lookups in a record, or invalid syntax in the SPF record. Some good resources for checking SPF records are Easy DMARC and MX Toolbox.
Unlike Temporary Errors, which are usually caused by a brief interruption in DNS lookups, Permanent Errors will remain until the remote domain’s SPF record is fixed. If you accept the delivery you run the risk of accepting bogus email. If you defer the message, the remote server is just going to keep trying with a broken SPF record. If you reject the message, the original sender will be notified by their own email server that there is a problem, which should eventually lead to an administrator for the remote domain fixing their broken SPF record.
Note that your Mailborder server will not send email rejecting the connection. This is done at the SMTP level between the servers.
Recommended setting: reject
Temporary Error Handling #
A Temporary Error is usually the result of a DNS lookup failure. This could be a temporary problem with your Mailborder server’s DNS resolution due to something like a connection issue, or the same problem with the remote domain’s DNS server. These problems are typically resolved rather quickly on their own.
You may elect to accept the email during a temporary error, but you again risk getting bogus email. (We have seen this numerous times out in the wild.) You may also reject the email, which will essentially cancel the delivery all together. The original sender will get a notice from their email server that the email is undeliverable. Finally, you can choose to defer the email, which is the recommended setting. This will tell the remote email server to try again later.
Recommended setting: defer
SPF Options #
Test Mode #
If this option is enabled, SPF results will only be added to the header and logged to syslog. No actions will be taken on the email being evaluated. This should always be temporary when enabled. This option effectively disables SPF error handling.
HELO Checks #
This is considered a strict option. When enabled, the HELO or EHLO greeting sent by the remote server is evaluated for validity. This includes a properly formatted hostname, correct forward DNS lookups, and correct reverse DNS lookups. It is very common for a remote server to fail this check. This option should only be enabled in very strict environments.
Verify Sender Email #
This option evaluates the sending email address for RFC 5321 validity. This includes a check for an overall length of 256 characters or less, proper address formatting, local part compliance (before the @ symbol) of 64 characters or less, and a domain part compliance (after the @ symbol) of 255 characters or less. This check will help in keeping garbage email out, but some senders like Mailchimp regularly violate RFC 5321. However, you may whitelist certain domain from this check and keep it enabled for all other remote domains.
Verbose Logging #
This option enables more details being logged to syslog during evaluation.
SPF Whitelists #
Mailborder has several different SPF whitelist options. These whitelists should, in most cases, be a temporary solution. Be cautious when whitelisting as it can degrade the security of your environment.
IP Whitelist #
The IP whitelist is a list of single IP addresses or CIDR ranges. Email originating from these sources will bypass SPF checks. A common entry would be an internal email server relaying email outbound through your Mailborder solution. This can also be used for problem servers with misconfigured SPF settings, but this should be a temporary implementation until the remote domain owner corrects the SPF record for their domain.
Domain Whitelist #
The domain whitelist is a list of domains or sub-domains. Email originating from these domain will bypass all SPF checks. Note that whitelisting domains can be dangerous and should only be used when absolutely required and for a limited time period. Once the remote domain owner has corrected their SPF record, domain whitelist entries should be removed.
Email Verification Whitelist #
If the option to verify sender email addresses for RFC 5321 compliance is enabled, you may need to whitelist some domains to bypass this check. The most common violation is to exceed the 64 character limit in the local part of the sender email address, which is the portion before the @ symbol. This commonly happens in bounce tracking emails from senders such as Mailchimp. Another common problem is exceeding the 256 character limit of a sender email address. It is not uncommon for email verification whitelist entries to be permanent.
