Email security is one of the biggest challenges in today’s digital world. With phishing, spoofing, and spam on the rise, protecting your domain is essential. One of the most important tools for this is the SPF record (Sender Policy Framework).
In this article, we’ll explain what SPF is, why it matters for Google Workspace and other platforms, how it works, and how to set it up properly—without the jargon.
What is a SPF Record?
SPF (Sender Policy Framework) is a type of DNS (Domain Name System) TXT record that tells other email servers, which mail servers, are allowed to send email on behalf of your domain.
An SPF (Sender Policy Framework) record is a type of DNS TXT record that helps prevent email spoofing and improve email deliverability. For Google Workspace, it essentially tells other email servers that Google’s mail servers are authorized to send emails on behalf of your domain.
When you send an email, the recipient’s mail server performs checks to verify that the email is legitimate and not a spoofed or fraudulent message.
👉 Example for Google Workspace: v=spf1 include:_spf.google.com ~all
This means:
- Only Google’s mail servers can send on behalf of your domain.
- Others will fail or soft-fail the check.
Why Do We Need SPF Records in Google Workspace?
To protect your domain from email spoofing (fake emails pretending to be from your domain).
Without SPF:
- Spammers can send fake emails using your domain.
- Your emails might land in the Spam/Junk folder or get blocked.
With SPF record:
- Mail providers like Gmail, Yahoo, and Outlook can verify your email if the email is really from your domain.
- Email deliverability improves and trust meaning fewer lost messages.
- Your domain gains trust and credibility.
Here’s why spf is crucial:
- Prevents Email Spoofing: Without an SPF record, anyone could potentially send an email claiming to be from your domain, even if they aren’t authorized. This is called email spoofing and is a common tactic used in phishing attacks. The SPF record acts like a digital “whitelist” of authorized senders for your domain.
- Improves Email Deliverability: if you don’t have a valid SPF record or if it’s incorrectly configured, recipient mail servers are more likely to flag your emails as suspicious, send them to the spam folder, or even reject them outright. By having a correct SPF record, you tell receiving servers that emails from Google Workspace are legitimate, which increases the likelihood of your emails reaching the recipient’s inbox.
- Enhances Domain Reputation: A properly configured SPF record (along with DKIM and DMARC) demonstrates to Internet Service Providers (ISPs) and email clients that you are committed to email security best practices. This builds trust and positively impacts your domain’s sending reputation.
Key Components
- Mechanisms: These are tags that define the authorized senders. Examples include:
v=spf1: This is required and indicates the SPF version.ip4/ip6: Authorize specific IP addresses.a: Authorize servers by their domain name.mx: Authorize servers listed in your domain’s MX records.include: Authorize a third-party service (like Google Workspace or Office 365) to send email for your domain.all: A catch-all mechanism that should be the last entry in the record, defining how to handle all other senders not explicitly listed.- Qualifiers: These are optional prefixes that tell the receiving server what to do with messages from unauthorized senders.
+(Pass): The default qualifier if none is specified, meaning the message is authenticated.-(Fail): A hard fail, telling the server to reject the message immediately.~(Soft Fail): A soft fail, meaning the message is likely unauthorized but should be accepted and marked as spam.?(Neutral): The message is neither authenticated nor unauthenticated.
How to Set Up SPF
A. Identify your senders: Make a list of all services that send email from your domain (e.g., your own mail servers, Google Workspace, Amazon SES, marketing platforms, etc.).
B. Create your SPF record: Combine the mechanisms for all your identified senders into a single DNS TXT record. Always start with v=spf1 and end with a qualifier for all, such as ~all or -all. For example, v=spf1 include:_spf.google.com ~all is a common record for Google Workspace users.
C. Publish the record: Log in to your domain host (e.g., GoDaddy, Cloudflare) and add the created SPF record to your domain’s DNS settings.
Keeping your SPF record up to date is important. It is also recommended to use SPF in combination with other authentication standards like DKIM and DMARC for a more robust email security strategy.
How an SPF Check Works: A Step-by-Step Breakdown
Here’s how the SPF process happens behind the scenes when you send an email a series of steps between the sender’s and receiver’s email servers.
Sender Initiates Email (Step 1 in Diagram):
A user, designated as the “Sender,” composes an email message and clicks ‘send’. This action initiates the entire email delivery process from their end.
Email Sent via Sending Email Server (Step 2 in Diagram):
The email client (e.g., Outlook, Gmail web interface) of the Sender hands off the email to their organization’s “Sending Email Server.” This server is responsible for processing outbound emails from the sender’s domain and preparing them for delivery to the recipient’s mail server. The email is then “forwarded to receiver mail server.”
Receiving Email Server Initiates SPF Check (Step 3 in Diagram):
When the “Receiving Email Server” (the recipient’s mail server) receives an incoming email, one of its first tasks, particularly for security and anti-spam purposes, is to perform an SPF check. This check aims to verify if the sending server’s IP address is authorized to send email on behalf of the domain from which the email claims to originate (specifically, the domain in the MAIL FROM address, also known as the envelope sender or return-path address).
Receiving Email Server Queries Sending Organization’s DNS Server (Step 4 in Diagram):
To perform the SPF check, the “Receiving Email Server” needs to retrieve the SPF policy published by the sending domain. It does this by sending a DNS query to the “Sending Organization’s DNS Server,” asking “Do you have an SPF record published for this sending domain?” This query specifically looks for a TXT record that begins with v=spf1.
Published SPF Record Retrieved (Step 5 in Diagram):
The “Sending Organization’s DNS Server” looks up the requested SPF record. If a valid SPF record exists for the domain in question, it retrieves this “Published SPF Record,” which contains a list of IP addresses or other mechanisms identifying servers authorized to send email on behalf of that domain.
DNS Server Responds to Receiving Mail Server (Step 6 in Diagram):
The “Sending Organization’s DNS Server” sends its response back to the “Receiving Email Server.” The response will indicate either “Yes” (an SPF record was found and its content is provided) or “No” (no SPF record was found for that domain).
SPF Check Evaluation by Receiving Email Server (Decision Point):
The “Receiving Email Server” then takes the information received from the DNS server and compares the IP address of the “Sending Email Server” (the server that established the connection and delivered the email) against the list of authorized IP addresses/mechanisms in the SPF record (if one was found). It essentially asks “Is the IP address of the server that sent this email found on the authorized list within the SPF record for the sender’s domain?”
Outcome Based on SPF Check Result:“YES” (Found on the authorized list – Green Arrow):
If the sending IP address is listed in the SPF record, the SPF check passes. This signifies that the email is likely legitimate and originates from an authorized sender for that domain.
Result: The email is accepted by the “Receiving Email Server” and is “Received in Inbox” by the “Receiver” (the final recipient).
“NO” (Not found on the authorized list – Red Arrow):
If the sending IP address is not listed in the SPF record (or if no SPF record was found and the receiving server’s policy defaults to rejection), the SPF check fails. This indicates that the email might be spoofed, unauthorized, or spam.
Result: The “Receiving Email Server” takes action according to its configured policy for SPF failures. As shown, the email is “Rejected, Mark email as spam,” preventing it from reaching the recipient’s inbox and protecting them from potentially malicious or unwanted messages.
What Does an SPF Record Look Like?
An SPF record is a string of text in a DNS TXT record. Here are a few examples:
Google Workspace (G Suite):
v=spf1 include:_spf.google.com ~allMicrosoft 365:
v=spf1 include:spf.protection.outlook.com -allFor Your Own Mail Server (by IP):
v=spf1 ip4:175.175.101.101 -allNotice that Google workspace uses a tilde character where Office 365 uses a hyphen character for ~all.
Understanding the Difference: ~all vs. -all
The difference between a hyphen and tilde character:
- –Fail, an IP that matches a mechanism with this qualifier will fail SPF (the receiving server should not accept the email).
~SoftFail indicates that if an IP matches a mechanism with this qualifier, the host should accept the email but mark it as an SPF failure, treating the email as suspect.
Domain forgery can cause a lot of email bounces. The amount of bounced email notifications, sometimes, can take down a small email server. Using a -all can decrease the amount of bounced email notification messages. However, this is up to the email delivery hosts to control and implement bounced message handling properly.
Google workspace recommends using a soft fail: ~all.
About SPF record format and tags
- SPF records always start with the v=spf1 tag.
- Use the include: tag in front of each sender domain (or IP address) in your SPF record. An SPF record can have up to 10 include: tags.
- Receiving servers will mark messages as spam if they are from servers not listed in the SPF record and the
~alltag is present. Google recommends you use ~all in your SPF record.
For detailed information about SPF record format and tags, visit About SPF records.
| For these senders | Use this SPF record |
| Google Workspace (only) | v=spf1 include:_spf.google.com ~all |
| Google Workspace and Amazon | v=spf1 include:_spf.google.com include:amazonses.com ~all |
| Google Workspace and GoDaddy | v=spf1 include:_spf.google.com include:secureserver.net ~all |
| Google Workspace and Mailchimp | v=spf1 include:_spf.google.com include:servers.mcsv.net ~all |
| Google Workspace and Microsoft Office 365 | v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all |
| Google Workspace and Salesforce | v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all |
Limitations of SPF
While SPF records are highly effective, they do have some limitations:
- 10 DNS Lookup Limit: The SPF specification limits an SPF record to a maximum of 10 DNS lookups to prevent Denial-of-Service attacks. Exceeding this limit results in a “PermError,” and this can cause the receiving mail server to mark legitimate emails as spam or to reject them.
- 255 Character Limit: You can only use up to 255 characters per individual string within a TXT record. Although you can break longer records into multiple strings, older systems may not handle this correctly.
- Does Not Protect the “Header From” Address: SPF primarily authenticates the “envelope sender” (
Mail From), which is not what the end-user sees. Spoofing the “Header From” address is a common tactic that SPF alone does not prevent. This is why implementing DMARC is crucial, as it requires alignment between the “Header From” domain and the domain authenticated by SPF or DKIM. - Breaks with Forwarding: When an email is forwarded, the forwarding server often changes the
Mail Fromaddress to its own, which can cause the SPF check to fail for the original sender, leading to legitimate emails being marked as spam. - Lack of Reporting: SPF does not provide domain owners with a built-in mechanism to receive reports on how receiving mail servers are evaluating their SPF records. DMARC addresses this by providing reports on SPF and DKIM authentication results.
👉 That is why For stronger protection, always combine SPF with DKIM and DMARC, Which we will see in another Post.
Should You Implement SPF?
✅Yes, we highly recommend that you implement SPF, even though it is not mandatory.
- It reduces spoofing.
- Improves inbox placement.
- Builds domain reputation.
The setup cost is low, and the benefits for security and deliverability are huge.
Recommended Best Practices for Spf
- Use ~all instead of -all (at least initially).
- Keep DNS TTL around 3600 seconds (1 hour).
- Combine with DKIM and DMARC for maximum protection.
- You need to regularly review and update your SPF record if you add new mail services.
Final Thoughts For SPF
SPF is the first line of defense against email spoofing. By publishing an SPF record for your domain, you:
- Protect your brand,
- Increase email trust, and
- Ensure better deliverability.
If you’re using Google Workspace, Office 365, or any email platform, implementing SPF should be a top priority for your business.
Summery of SPF
SPF (Sender Policy Framework) is a way to help stop email spoofing by specifying who is allowed to send emails on behalf of your domain. This is done by adding an SPF record to your domain’s DNS as a TXT record, which email providers check when they receive a message claiming to come from your domain. (Cloudflare, Wikipedia)
Key Parts of an SPF Record
- Version tag (
v=spf1)
Every SPF record starts with this. It tells mail servers it’s an SPF rule.
- Mechanisms
These phrases define who is allowed to send email for your domain:all: Matches any sender—usually placed at the end.a: Authorizes servers with an A or AAAA record matching the domain.mx: Allows servers listed in the domain’s MX records.ip4:/ip6:: Authorizes specific IPv4 or IPv6 addresses or ranges.include:: Lets you allow trusted third-party domains.ptr: Uses reverse DNS to check hostname (not recommended).exists:: Checks if a DNS A record exists for a given domain.
- Qualifiers
These optional prefixes tell mail servers what to do when a mechanism matches:
| Symbol | Meaning |
+ | Pass (default if no qualifier is given) – allowed |
- | Fail – email is rejected |
~ | SoftFail – email is accepted but marked as suspicious or spam |
? | Neutral – no clear decision, mail is neither explicitly allowed nor blocked |
- If a mechanism matches, its qualifier determines the outcome.
- Modifiers
These are optional elements, placed at the end of the record, to add extra behavior:redirect=another-domain.com: Tells the system to use another domain’s SPF settings.
exp=: Defines a custom explanation message if an SPF check fails.
A Simple Example
v=spf1 ip4:192.0.2.1 include:mailservice.example.com -allv=spf1→ Recognized as SPFip4:192.0.2.1→ Specifies one allowed IPv4 hostinclude:mailservice.example.com→ Also trusts servers allowed by this third party-all→ Only the above sources are allowed; others are definitely blocked
Best Practices & Tips to Remember
- Only one SPF record per domain: Multiple records can cause failures. (Google Help, Microsoft Learn)
- Keep it short: An SPF record is limited to 255 characters and at most 10 DNS lookups. (Google Help, Microsoft Learn)
- Avoid uppercase letters: Everything should be in lowercase. (Google Help)
- Use
-allwhen you’re confident: This ensures enhanced security—but make sure legitimate senders are covered. Soft fail (~all) is safer during testing. (EasyDMARC, Valimail –, Google Help, Wikipedia)
Why It Matters
Without SPF, anyone could pretend to send emails from your domain, leading to phishing or spam attacks. SPF helps receiving email servers check whether a message is legally coming from you, and act accordingly.
👉 Call to Action:
Want a step-by-step guide to setting up SPF, DKIM, and DMARC in Google Workspace? Stay tuned for our next article where we’ll walk you through the entire process!
