SPF Format : SPF Basic & Advanced Formats Explained
by
Last Updated: 4 min read
You can send emails without using SPF or knowing about SPF format, but that won’t be safe. SPF adds an additional trust indication to recipients’ mailbox providers, and all the authentic emails sent using your domain land in the box inbox instead of being marked as spam.
SPF isn’t a fool-proof method; therefore, you must combine it with other email authentication protocols like DKIM, DMARC, and BIMI to improve email deliverability.
Since these protocols are crucial to the email authentication process and all email-driven businesses must know about them, we’ll focus on the SPF record format in this blog.
Key Takeaways
- Implementing SPF offers an extra layer of trust for your emails, reducing the chances of being marked as spam.
- Combining SPF with other protocols like DKIM and DMARC enhances your overall email authentication strategy.
- A valid SPF record published in DNS helps email servers verify the legitimacy of incoming messages from your domain.
- Regularly monitoring your domain’s SPF records can help protect against cyber threats such as spear phishing and ransomware.
- Understanding the syntax and components of SPF records is crucial for successfully implementing and maintaining email authentication.
What is SPF?
SPF is short for Sender Policy Framework- one of the most common email authentication protocols. It works using a list of IP addresses authorized to send emails using your domain name. The list typically includes IP addresses of your employees, shareholders, and third parties that directly use your domain to send emails.
If you’ve implemented SPF, any email sent from an IP address outside the list is considered unauthorized by the recipient’s mailbox.
Simplify SPF with PowerDMARC!
How is Email Authenticated Using SPF?
You need to publish a valid SPF record (in TXT format) on your DNS to implement this protocol. When an email is sent from your domain, the receiver’s mail server cross-checks the sender’s IP address with the SPF records on your DNS. If it’s on the list, validation passes, and the email lands in the inbox. However, if it isn’t on the list, authentication fails, and emails don’t reach their destination.
After implementing it, you must regularly monitor your domain activity using an SPF checker to ensure it isn’t on a hacker’s radar. This can prevent spear phishing, scamming, and ransomware attacks attempted using your company’s name.
SPF Format
SPF record is complicated and has a typical format that’s difficult to understand. Here we’ll be discussing SPF record syntax and SPF record structure- the head and heart of SPF record format.
SPF Record: Basic Syntax
An SPF record is a DNS record enlisting all the IP addresses allowed to send emails using your email domain. This is what an SPF record syntax looks like:
v=spf1 ip4=193.0.1.0 ip4=193.0.1.1 include:samplesender.net -all
Let’s check out the elements included in this.
- v=spf1- It tells the server that this contains an SPF record. Every SPF record must begin with this string.
- ip4=193.0.1.0 ip4=193.0.1.1- It indicates the IP addresses allowed to send emails using a specific domain.
- Include:examplesender.net: It tells third parties authorized to send emails. The ‘include’ tag directs the recipient servers to verify the included domain’s (here- samplesender.net) SPF record. You can add several domains within one SPF record.
- -all: tells recipient servers to reject emails coming from unauthorized IP addresses, basically the ones not included in the list.
SPF Record: Advanced Syntax
As per the SPF record format for syntaxes, it always starts with the ‘v=’ element. It tells the SPF version; currently, there’s only one version, so all SPF record formats begin like this.
SPF record syntax has three primary elements; SPF Mechanism, SPF Qualifiers, and SPF Modifiers. Let’s see what they are.
Mechanisms
Here are the eight mechanisms
- ALL: This means there’s always a match. You’ll see default results like ‘-all’ for unmatching IPs.
- A: Domain name with A or AAAA address record matches as they can be resolved to the sender’s address.
- IP4: The match is valid when the sender is linked to the given IPv4 address range.
- IP6: The match is valid when the sender is linked to the given IPv6 address range.
- MX: Sender’s email address is validated only if their domain name includes an MX record for resolution.
- PTR: The match is authorized if the PTR record belongs to a given domain resolving to the client’s address. Experts don’t suggest its use as it might block all emails sent using your domain.
- EXISTS: It works if the given domain name is validated. This SPF mechanism functions with all resolved addresses.
- INCLUDE: It references other domain policies. So, if that passes, it passes automatically. However, if the included policy fails, processing continues.
Modifiers
Modifiers determine an SPF record’s functional framework. It consists of name or value pairs separated by the ‘=’ symbol, pointing out additional information. You’’ see them many times at the end of the SPF record, and all the unrecognized modifiers are ignored in the process.
The ‘redirect’ modifier directs to other SPF records responsible for efficient functioning. Experts use them whenever more than one domain is linked to the same SPF record. This modifier must be used if a single entity controls all the domains; otherwise, the ‘include’ modifier is used.
Qualifiers
Each mechanism can be combined with one of four qualifiers.
‘+’ for the PASS result
‘?’ for a NEUTRAL result interpreted like NONE policy.
‘~’ for SOFTFAIL. Usually, messages that return a SOFTFAIL are accepted but tagged.
‘-’ for FAIL, the email is rejected.
Conclusion
SPF prevents cyberattacks committed using your brand’s name and reputation. You can stop emails sent by hackers using your domain from reaching their target audience. This works by enlisting and allowing only trusted entities to send emails using your domain.
After understanding the SPF record format’s structure and components, you can use the SPF record generator if you haven’t implemented the protocol yet. 
Domain & Email Security Expert at PowerDMARC
Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.
Latest posts by Ahona Rudra (see all)
