Enterprise Email Infrastructure: Security Baseline and Best Practices - SPF

Sender Policy Framework (SPF)

SPF is an email authentication technique that helps prevent spammers from sending messages on behalf of your domain. It allows the receiving mail server to check that an email claiming to come from a specific domain comes from an IP address authorized by that domain’s administrators.

The above diagram showcases how the receiving server can verify if a domain allows a sender's IP address as an "Authorized" server for the domain Note that SPF is one of the mechanisms to authorize the source of the email. If an SPF validation successfully passes, the receiving server will still proceed with further threat analysis based on the configurations of the email service provider being utilized in the enterprise. If an SPF failure is detected, the course of action for the email is mentioned within the DNS record itself or determined by the policy ('p') tag in the DMARC record of the domain. Additionally, certain Email providers also have various configurations to specially deal with the outcome of DNS failures for the sending server.

Benefits of implementing SPF

• Prevents sender address forgery
• Enhances email deliverability by reducing spam
• Protects against phishing attacks

Structure of the SPF Record

• 'v' tag a.k.a. version, like 'v=spf1'
• 'ip4' or 'ip6' tag to contain the Public or Breakout IP addresses of the sending gateway server
• 'include' tag in which you can add the SPF of other domains, like - 'include:spf.protection.outlook.com' - which Authorizes Microsoft's 365 Exchange Online services to send emails for your domain.
• 'a' tag which authorizes the A record (IPv4 address) of the domain to send emails - like - a:mail.example.com
• 'mx' tag which authorizes the mx for the domain to send emails - like - mx:example.com
• 'ptr' tag This mechanism is used to specify that emails can be sent from any host whose PTR (reverse DNS) record matches the given domain. (Not recommended a it can cause performance issues).
• 'exists' tag which checks for the existence of a domain name. If the domain exists, the mechanism matches. Example: 'exists:%{i}.spf.example.com'
• 'redirect' tag which is used to redirect SPF processing to another domain's SPF record. Example: redirect=_spf.example.com
• 'exp' tag which Specifies an explanatory text or domain providing additional information when SPF evaluation fails. Example: exp=explanation.example.com
• 'all' tag which is a catch all mechanism that defines how emails that do not match the previous rules should be treated.
  It can be used with qualifiers like -all (fail), ~all (soft fail), or ?all (neutral).

Speaking of Qualifiers mentioned in the 'all' tag - SPF mechanisms can be prefixed with one of four qualifiers

• + (Pass): Default if no other qualifier is specified.
• - (Fail): The specified IPs are not allowed to send mail.
• ~ (Soft Fail): The specified IPs are not allowed to send mail but the result is only a warning.
• ? (Neutral): No definitive assertion can be made for the specified IPs.

Implementation

• Step 1: Identify the IP addresses that are authorized to send emails on behalf of your domain.
• Step 2: Create an SPF record with the above structure and qualifier:
  Example:
  Microsoft SPF in Public DNS

  v=spf1 include:spf.protection.outlook.com -all

  Copy
  
  
• Step 3: Publish the SPF record in the external / public DNS host of your domain.

CRITICAL INFORMATION

• IT IS HIGHLY IMPORTANT TO ENSURE ENTRIES IN THE SPF RECORD OF YOUR DOMAIN ARE UNDER YOUR CONTROL. DO NOT ADD ANY IP ADDRESSES OR SERVERS OF UNKNOWN ORIGIN TO YOUR DOMAIN'S SPF RECORD. DOING SO CAN ALLOW RECEIVERS TO AUTHORIZE INBOUND EMAILS FROM YOUR DOMAIN SENT VIA THOSE UNKNOWN SERVERS. OVERTIME THIS CAN CAUSE A LOT OF DAMAGE YOUR DOMAIN'S REPUTATION.
• ADDITIONALLY, IT IS ALSO RECOMMENDED TO REFRAIN FROM ADDED TOO MANY IP ADDRESSES OR SERVERS TO YOUR DOMAIN'S SPF RECORD - A PROCESS CALLED 'WHITELISTING' - THIS INCREASES THE OVERALL ATTACK SURFACE OF YOUR DOMAIN - IN WHICH, IF A SINGLE ONE OF THESE AUTHORIZED SERVERS IS COMPROMISED, THE ATTACKER CAN USE THE COMPROMISED SERVER TO SEND MALICIOUS CONTENT OUT FROM YOUR DOMAIN.
• THE BEST PRACTICE IS TO ONLY ALLOW ONE 'SECURITY HARDENED' EMAIL SYSTEM TO SEND EMAILS FROM YOUR DOMAIN VIA SPF AND INTEGRATE EVERY INTERNAL SERVICE WITH THAT SAME SYSTEM SO THAT YOU CONTROL WHO OR WHAT SENDS EMAILS FROM YOUR DOMAIN.

We shall discuss more on Security Hardening of the Enterprise Email solutions in the upcoming articles. Now, let's move on to DKIM

DokmainKeys Identified Mail (DKIM) >>