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 abc.com and when I send email, it get’s the IP 1.1.1.1. That IP Address must be used.
  • I work for abc.com 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 abc.com but I’m sending emails with the xyz.com domain (noreply@xyz.com). I need to have an include for xyz.com domain.

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

  • I work for abc.com and when I send email, it get’s the IP 1.1.1.1. When the client receives my email, kcordero@abc.com, abc.com 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.

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.