SPF Records

SPF’s are used to help mitigate SPAM emails.  It basically dictates what happens when there’s a failure in a match and what the host should do. I prefer -all when I’m in control of my domains. What’s the use of the SPF if it’s not affective? You have to think about what exactly is the SPF trying to accomplish. The simplest way to think about it is, it’s a pass/fail lookup mechanism.

Example of an SPF record:
v=spf1 ip4:1.1.1.1 include:spf.protection.outlook.com -all

First to start, there’s the version for the SPF record which is “v=spf1“. After that, there are typically two options used when setting up an SPF record. Those are IP4 and INCLUDE. You might also see an A option so I’ll briefly discuss it. These are followed by the “what should I do if it’s a pass or fail?“. This is the last thing you set. That’s where the “all” option comes into play.

ip4:{IP ADDRESS} = IP Addresses that are authorized to send email on my behalf

• I work for cordero.me and when I send email, it get’s the IP 1.1.1.1. That IP Address must be used in the record configuration.
• I work for cordero.me and when I send email for surveys, it get’s the IP 2.2.2.2. That IP Address must be used.

include:{DOMAIN} = Domains that are authorized to send email on my behalf

• I work for cordero.me but I’m sending emails with the example.com domain (noreply@example.com). I need to have an include for example.com domain.

a:{DOMAIN} = DNS A record lookup must match

• I work for cordero.me and when I send email, it get’s the IP 1.1.1.1. When the client receives my email, kcordero@cordero.me, cordero.me must resolve to 1.1.1.1. If not, it’s a fail.

How do you control Pass/Fail? You use any of these three:

-all = hardfail Fail or Reject if it does NOT match
~all = softfail marked as spam but accept if it does NOT match
+all = email accepted no matter what       :DON’T USE!

NOTE:
It’s not a bad idea to use a softfail when testing email and then change it to hardfail when it’s working correctly.

Let’s break down the example SPF (Sender Policy Framework) record I provided above: `v=spf1 ip4:1.1.1.1 include:spf.protection.outlook.com -all`. This record is used to specify which mail servers are authorized to send emails on behalf of the domain where this record is published.

1. Version (`v=spf1`):

• `v=spf1` is the tag that indicates the version of SPF being used. SPF1 is currently the standard version for these records.

2. IP4 Mechanism (`ip4:1.1.1.1`):

• `ip4:1.1.1.1` specifies that emails sent from the IP address `1.1.1.1` are authorized to send emails for the domain. This is a direct way to whitelist an IP address.

3. INCLUDE Mechanism (`include:spf.protection.outlook.com`):

• `include:spf.protection.outlook.com` allows the SPF record of another domain (in this case, `spf.protection.outlook.com`) to be included in the evaluation. This means that the SPF record of `spf.protection.outlook.com` will be looked up and its specifications will be considered part of this domain’s SPF policy.
• This is commonly used when a domain outsources its email services to a third-party provider, like Microsoft Outlook in this case. It essentially says, “trust emails sent from servers authorized by Outlook’s SPF record as if they were our own.“

4. ALL Mechanism (`-all`):

• The `-all` at the end of the SPF record is a policy mechanism that defines how to treat emails that don’t match any of the prior mechanisms in the record.
• `-all` indicates a “hardfail” policy. This means that if an email is received from an IP address not listed in the SPF record (and not covered by the `include` directive), the receiving mail server should reject it as it does not conform to the defined SPF policy.
• This setting is used to strictly enforce the SPF policy and helps to prevent unauthorized use of the domain for sending emails.

In summary, this SPF record:

• Authorizes emails sent from the IP address `1.1.1.1`.
• Includes and trusts the SPF settings of `spf.protection.outlook.com`, likely a third-party email service provider.
• Advises receiving email servers to reject any emails from this domain if they do not come from these authorized sources (`-all`).

More Details on Each Option and Recommendations

a mechanism:

• • Function: Checks if the domain’s A (or AAAA) record IP address is allowed to send an email for the domain.
  • Usage: It can be used simply as a or with an argument as a:example.com.
  • When to use: When the sending server’s IP address matches the A record of the domain. It’s especially useful if your domain’s A record IP and your mail server’s IP are the same.
  • Recommendation: Use this mechanism when you want to specify that the host(s) the domain resolves to are allowed to send email.

mx mechanism:

• • Function: Allows mail servers (as listed in the domain’s MX records) to send emails on behalf of the domain.
  • Usage: Used as mx without any argument or with a domain as mx:example.com.
  • When to use: When you want to specify that any server that’s a mail exchanger for your domain (as per the MX record) is permitted to send mail for your domain.
  • Recommendation: This is quite common for domains that receive and send mail because the servers that accept mail (MX servers) are often the same ones sending it.

ip4 mechanism:

• • Function: Explicitly lists individual IPv4 addresses or ranges that are permitted to send email.
  • Usage: ip4:1.2.3.4 or with a range like ip4:1.2.3.0/24.
  • When to use: When you want to specify exact IP addresses or ranges that are authorized to send mail for your domain. This provides more granular control.
  • Recommendation: It’s an excellent choice when you know the exact IP addresses of your sending servers. It’s clear and explicit.

include mechanism:

• • Function: References the SPF record of another domain. It’s a way to say, “Include the rules from this other domain’s SPF record in my own.”
  • Usage: include:spf.example.com.
  • When to use: Commonly used when outsourcing email to a third party, like a newsletter service or a transactional email provider. By using include, you’re incorporating their SPF rules into your own without knowing all their mail server IPs.
  • Recommendation: Useful and commonly used. However, be cautious as it does mean you’re trusting another domain’s SPF record. If they change their record, it could indirectly affect your email deliverability. Always ensure you’re including trusted third parties.

Recommendations:

• Always be specific in your SPF records to reduce the potential for email spoofing.
• Avoid using too many include mechanisms, as there’s a limit (10 DNS lookups) for SPF processing. If you exceed this, the SPF check might not complete, affecting your email deliverability.
• Using -all at the end of your SPF record (hard fail) is good practice once you’re sure of your SPF setup. It indicates that only the sources listed in your SPF record can send emails to your domain.
• Periodically review and update your SPF record, significantly if you change email providers or add new third-party services that send emails on your behalf.