An SPF record includes the servers and IP ranges a domain owner allows to be used to send emails on behalf of their brand. It’s composed of syntaxes, primarily categorized as SPF mechanisms, SPF qualifiers, and SPF modifiers. The combination of these syntaxes lets domain owners clearly convey how they want the receiving servers to handle unauthorized emails sent on their behalf.
SPF records are complex and have a format. Not having the knowledge of the format makes your SPF record erroneous, which ultimately makes it invalid. This blog explains the basic and advanced syntaxes.
SPF records basic syntax
An SPF record is a TXT record that is published in your domain’s DNS to prevent phishing and spoofing. Here’s an example of a standard SPF record-
v=spf1 ip4=203.0.113.42 include:_spf.google.com include:company.com -all
This is what each element included in this example means-
- v=spf1: This tells the mail server that the specific DNS record is an SPF record. All SPF records must start with this.
- ip4=203.0.113.42 ip4=203.0.113.43: These are the IP addresses that are allowed to send emails on behalf of the domain. Only emails sent from these addresses will be considered valid.
- include:_spf.google.com: This allows a third-party service (in this case, spf.google.com) to send emails on behalf of the domain. The ‘include’ tag tells recipient servers to check the SPF record of the included domain (spf.google.com) to confirm it’s authorized.
- -all: This means any email sent from IP addresses not listed in the SPF record should be rejected as unauthorized. It ensures stricter email security by blocking unapproved senders.
SPF records advanced syntax
As mentioned above, the advanced syntaxes are categorically divided into mechanisms, modifiers, and qualifiers.
1. SPF mechanisms
- all: This means it always matches. You’ll commonly see defaults like -all to handle unmatched IPs.
- a: Matches if the domain name has an A or AAAA record that resolves to the sender’s address.
- ip4: Matches when the sender’s IP falls within the specified IPv4 address range.
- ip6: Matches when the sender’s IP falls within the specified IPv6 address range.
- mx: Validates the sender’s email only if the domain name has an MX record that resolves properly.
- ptr: Matches if the PTR record corresponds to a domain that resolves to the client’s address. However, experts advise against using this as it can unintentionally block all emails from your domain.
- exists: Matches if the specified domain name resolves to an address. This mechanism validates any resolved addresses.
- include: Refers to policies from other domains. If the included policy passes, it’s accepted automatically. If it fails, processing continues.
2. SPF modifiers
Modifiers shape how an SPF record works. They are written as name-value pairs separated by `=`, providing extra details. Modifiers often appear at the end of an SPF record, and any unrecognized ones are ignored.
The `redirect` modifier points to another SPF record, helping manage multiple domains under the same setup. It’s best used when a single organization controls all the domains. The `include` modifier is a better choice if different entities manage the domains.
3. SPF qualifiers
SPF qualifiers define how recipient mail servers should treat emails that match or fail a specific rule. There are four qualifiers:
- `+` (Pass): Indicates that the email comes from an authorized sender. This is the default qualifier and can be omitted.
- `-` (Fail): Specifies that emails from this source should be rejected outright.
- `~` (SoftFail): Means the email is likely unauthorized but should not be outright rejected. It is typically flagged or treated as suspicious.
- `?` (Neutral): No specific action is recommended, and the email is neither accepted nor rejected based on the SPF check.
Complementing SPF with DKIM and DMARC
Using DMARC alongside SPF and DKIM creates a stronger defense against email-based attacks and enhances email deliverability. DMARC addresses SPF’s shortcomings, offering a more flexible and comprehensive framework for email authentication.
One key limitation of SPF is its lack of a standard way for domain owners to receive feedback on how their emails are being authenticated across various servers. DMARC solves this by introducing reporting mechanisms, allowing domain owners to receive detailed DMARC reports that show the results of SPF and DKIM checks.
SPF checks can fail during email forwarding because the forwarding server is not listed in the original sender’s SPF record. DMARC helps address this issue by allowing domain owners to define how to handle emails that fail authentication, such as forwarding them with modified headers.
With DMARC, domain owners can specify how receiving servers should deal with emails that fail SPF or DKIM checks. This provides more flexibility, enabling tailored email authentication policies.
DMARC also introduces the concept of alignment, ensuring that the domain in the ‘From’ header matches the domain authenticated by SPF and/or DKIM. This alignment strengthens email authentication and prevents domain spoofing.
