How to Set Up an SPF Record for Gmail

Without a proper Google SPF record, Gmail’s mail transfer agents may mistakenly classify your legitimate emails as phishing or spam. That’s a problem if you’re running any business on Google Workspace.

SPF (Sender Policy Framework) is a DNS TXT record that specifies which mail servers are authorized to send emails on behalf of your domain. It acts as a gatekeeper, ensuring only designated servers can send emails on your behalf. Google now requires email authentication for all senders, making SPF setup non-negotiable.

This guide covers exactly how to set up SPF in Gmail and Google Workspace; the correct Google mail SPF record syntax, verification steps, common mistakes to avoid, and how to layer in DKIM and DMARC for complete protection.

What are Gmail SPF Records?

An SPF (Sender Policy Framework) record specifies which mail servers are authorized to send emails on behalf of your domain. When an email is received, the receiving server checks the SPF record of the domain in the “From” address to verify whether the email is coming from an authorized server.

It is published in your domain’s DNS as a SPF TXT record. It contains a list of IP addresses or hostnames of the servers permitted to send emails on behalf of your domain. This record can include multiple servers and third-party services.

If an email is sent from an unauthorized source, the receiving server will check the domain’s SPF record using the DNS TXT record.

The Importance of a Gmail SPF Record

Google requires all email senders to implement authentication, and bulk senders (over 5,000 messages daily) must have SPF, DKIM, and DMARC configured. Ignoring these requirements has real consequences. Without a Google Workspace SPF record:

• Your emails may get flagged as spam by receiving servers that can’t verify your domain’s legitimacy.
• Your domain or IP address can get blocklisted, making deliverability recovery significantly harder than setting up authentication in the first place.
• Your domain reputation takes a hit as spam email complaints increase, which compounds over time and affects all future sends.

SPF records serve as a critical line of defense for your domain against malicious actions like email spoofing and phishing attacks.

Beyond security, implementing an SPF record can significantly enhance a domain’s credibility and trustworthiness with major mailbox providers like Gmail, Outlook, and Yahoo. This directly improves the chances that your emails land in the inbox rather than the spam folder.

How Does an SPF Record Work?

An SPF record is published in your domain’s DNS as a TXT record. It’s a single line of plain text made up of tags that specify the IP addresses and domain names of your authorized sending sources.

SPF records can have up to 255 characters per DNS string, and the total TXT record file size should not exceed 512 bytes.

When an email is sent, the receiving server checks the SPF record of the domain in the “From” address to verify whether the email is coming from an authorized server. It does this by comparing the sending server’s IP address against the list of allowed IPs published in your SPF record. Gmail automatically checks incoming messages against the sending domain’s SPF record to verify legitimacy as part of this process.

Based on this check, the receiving mail server assigns one of the following results:

• Pass means the sending server’s IP is listed in the SPF record and is authorized to send email for the domain.
• Fail means the IP is not authorized, which indicates potential email spoofing, and the message may be rejected outright.
• Softfail means the IP is not explicitly authorized, but the domain owner has used the ~all qualifier to indicate that servers should accept, but likely flag, messages from unlisted IP addresses.
• Neutral means the domain makes no assertion about whether the IP is authorized or not.
• None means no SPF record was found for the domain, so no authentication check could be performed.

SPF helps prevent email spoofing by providing an email authentication mechanism that verifies if the sending mail server’s IP matches the allowed IPs for the domain.

If the IP doesn’t match and the record uses a hard fail (-all), the message is rejected. With a soft fail (~all), the message is accepted but marked as suspicious.

Components of an SPF Record

To properly construct and interpret an SPF record for Gmail or Google Workspace, you need to understand the key mechanisms and qualifiers that make up the record.

SPF mechanisms

Every SPF record is built from mechanisms that define which servers are authorized to send email on behalf of your domain.

Each mechanism counts toward the 10 DNS lookup limit, except ip4 which points directly to an IP address and doesn’t trigger a lookup. When adding an SPF record, ensure that you do not exceed this maximum to avoid validation failures.

SPF qualifiers

Every mechanism can be preceded by a qualifier that tells the receiving server how to handle the result.

For most Google Workspace setups, the recommended SPF record is v=spf1 include:_spf.google.com ~all.

The soft fail qualifier ~all at the end indicates that servers should accept, but likely flag, messages from unlisted IP addresses. This gives you visibility into unauthorized senders without immediately rejecting legitimate mail that might be misconfigured.

Prerequisites Before Setting Up an SPF Record

Before you set up an SPF record for Gmail, ensure you have:

• Complete inventory of email senders: List all services that send emails on your behalf (Google Workspace, marketing platforms, CRM systems, etc.)
• DNS management access: Provide admin access to your domain’s DNS settings
• Understanding of your domain structure: Ensure complete knowledge of subdomains that send email
• Current SPF record check: Verify if an SPF record already exists
• Third-party service documentation: Include statements from your email service providers

💡 Pro tip: For organizations with multiple third-party senders, create a spreadsheet tracking each service’s SPF requirements. This prevents exceeding the 10 DNS lookup limit.

How to Create and Add an SPF Record for Gmail

Setting up a Google mail SPF record is straightforward. The entire process happens outside of Google, in your domain registrar’s DNS settings. Here’s how to set up SPF in Gmail step by step.

Step 1: Sign in to your domain registrar

To create an SPF record for Google Workspace, sign in to your domain account where you purchased and manage your domain: GoDaddy, Namecheap, Cloudflare, or whichever domain provider you use.

If you’re unsure where your domain is registered, check with your IT team or look up your domain’s WHOIS record.

Step 2: Navigate to your DNS settings

Once logged in, locate the DNS management area.

In the DNS settings, look for the TXT records section. This is where you’ll add your SPF record. An SPF record is published in your domain’s DNS as a TXT record, so you won’t find a separate “SPF” record type in most registrars.

Step 3: Check for existing SPF records

Before adding anything new, check whether your domain already has an SPF record. You can only have one SPF record for Gmail per domain. Having multiple SPF records for a single domain can cause email authentication failures.

If one already exists, you’ll edit it in the next step rather than creating a new one.

Step 4: Create your Google mail SPF record

Add a new TXT record with these values:

• Host / Name: @ (or blank, depending on your provider)
• Record Type: TXT
• Value: v=spf1 include:_spf.google.com ~all
• TTL: Default (typically 3600)

The recommended SPF record for Google Workspace is v=spf1 include:_spf.google.com ~all.

If you use other email services to send emails, you need to include them in your SPF record. Since you can only have one record per domain, merge everything into a single line:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

A few things to watch for: Do not exceed the maximum of 10 DNS lookups, each include: triggers at least one, and nested includes count too. SPF records can have up to 255 characters per DNS string. If yours exceeds this, most providers will auto-split it.

Step 5: Save and allow time for propagation

After creating your SPF record, save the changes and allow up to 48 hours for the record to propagate.

Most providers propagate within a few hours, but the full window accounts for slower DNS networks. Avoid making further changes during this period unless you spot an obvious error.

Step 6: Verify your SPF record

Once propagation is complete, to verify your SPF record, use an SPF checker tool to ensure it is valid and correctly configured. Two ways to do this:

• SPF lookup tool: MXToolbox, Dmarcian, or Kitterman let you enter your domain and instantly check that your Google mail SPF record is published, syntactically valid, and within the 10-lookup limit.
• Test email: Send a message to a Gmail address, open it, click the three-dot menu, select “Show original,” and look for spf=pass in the Authentication-Results header.

Step 7: Set up SPF for subdomains (if applicable)

If you are using subdomains to send email (e.g., marketing.yourdomain.com), you need to set up SPF records for each subdomain separately if your provider allows it.

SPF policy isn’t inherited from the root domain. Each subdomain needs its own TXT record. The setup process is identical; just change the Host/Name field from @ to the subdomain.

Common SPF Record Mistakes and How to Avoid Them

Even a small misconfiguration can break email authentication entirely. When setting up SPF, avoid common mistakes such as having multiple records or incorrect syntax. Here are the ones that come up most often.

Multiple SPF records on a single domain

You can only have one SPF record per domain.

If a receiving server finds two or more, it returns a permanent error and fails the check. If you need to authorize additional services, merge all include: mechanisms into one record; don’t create a second TXT entry.

Using +all instead of ~all

The +all qualifier tells receiving servers to accept email from any IP address, which completely defeats the purpose of SPF. Always use:

• ~all (soft fail): Google’s recommended default
• -all (hard fail): stricter, rejects unauthorized senders outright

Exceeding the 10 DNS lookup limit

SPF records are limited to a maximum of 10 DNS lookups; exceeding this limit will cause authentication to fail. Each include, a, mx, and redirect mechanism counts as a lookup, and nested includes count too. If you’re approaching the limit, use SPF flattening tools to convert includes into direct IP addresses.

Forgetting to include new sending sources

Added a new CRM, marketing tool, or transactional email service? If you don’t update your SPF record to include them, emails sent through those services will fail authentication. Regularly monitoring your SPF record can help identify potential issues before they affect email deliverability.

How to Troubleshoot SPF Failures in Gmail

Set up your SPF record, waited for propagation, but emails are still landing in spam or failing authentication? Here’s a quick checklist to diagnose and fix common SPF issues.

• Check email headers: Send a test email to a Gmail address, click “Show original,” and look for spf=pass, spf=softfail, or spf=fail in the Authentication-Results header.
• Run an SPF lookup: Use MXToolbox or Dmarcian to verify your record is published, syntactically correct, and within the 10-lookup limit.
• Confirm all senders are included: Ensure every third-party service (CRMs, helpdesks, marketing platforms) is in your record. If an email is sent from an unlisted source, the receiving server checks your SPF record and fails the message.
• Check for duplicate records: Confirm only one TXT record starting with v=spf1 exists for your domain; having multiple SPF records for a single domain causes authentication failures.
• Monitor regularly: Review your SPF record after adding new tools or changing providers. Issues don’t always surface right away, and catching them early prevents deliverability problems.

Validating and Monitoring Your SPF Record

Setting up your SPF record is only half the job. If the record has a syntax error, exceeds the 10-lookup limit, or goes out of date after you add a new sending service, your emails can silently start failing authentication. Regular validation and monitoring ensure your SPF record for Gmail stays functional and your deliverability stays intact.

Initial verification steps

• You can use our SPF lookup tool to check your Gmail SPF record setup instantly.
• Go through the TXT entry of your implemented SPF record to see if the status is valid.
• Recheck if the record contains all the authorized IP addresses and third-party vendors you use to send your emails.
• Make sure you haven’t published multiple SPF records for a single domain. If you use additional third-party vendors other than Google Workspace for email marketing, you can use the “include” mechanism in the same SPF record.
• Make sure you maintain proper formatting.

If any discrepancies are found in your SPF record, update it to remove these errors and verify your setup again.

Ongoing monitoring best practices

• Periodic SPF checks: Review your SPF record monthly for accuracy and completeness.
• Email header analysis: Regularly examine email headers for SPF authentication results.
• DMARC report monitoring: Use DMARC reports to identify SPF failures and unauthorized senders.
• Change management: Update SPF records when adding new email services or changing providers.
• Automated monitoring: Set up alerts for SPF authentication failures.

Suggested read: How to Setup DMARC: Step-by-Step Configuration Guide

Implement DMARC and SPF With PowerDMARC

Implementing SPF alongside DKIM and DMARC provides a comprehensive layer of protection, ensuring that every message sent from your domain is both verified and trusted. Together, these protocols protect your domain from email-based cyber-attacks like spoofing, phishing, and BEC.

PowerDMARC helps you get there faster with:

• Automated error detection: Catch SPF misconfigurations, syntax issues, and lookup limit violations before they impact email delivery.
• Real-time monitoring: Receive instant alerts when SPF, DKIM, or DMARC authentication fails so you can act before deliverability drops.
• Compliance reporting: Generate audit-ready reports that meet industry compliance requirements and give you full visibility into who’s sending email on your behalf.
• 24/7 expert support: Access certified email security specialists whenever you need help with configuration, troubleshooting, or enforcement.

A customer shares: “With PowerDMARC, we caught SPF misconfigurations before they caused deliverability issues. Their support is top-notch!” – IT Manager, SaaS Company

Setting up a Google Workspace SPF record is only the first step toward protecting your domain. Start a free 15-day trial with PowerDMARC today!

Frequently Asked Questions (FAQs)

1. What is an SPF record for email?

An SPF (Sender Policy Framework) record is a DNS TXT record that specifies which mail servers are authorized to send emails on behalf of your domain. It prevents email spoofing and improves deliverability by allowing receiving servers to verify that emails are coming from legitimate sources.

2. How do I fix SPF failure in Gmail?

To fix SPF failures in Gmail:

• Check if your SPF record includes “include:_spf.google.com“
• Ensure you have only one SPF record per domain
• Verify your SPF syntax is correct
• Make sure you haven’t exceeded the 10 DNS lookup limit
• Wait for DNS propagation after making changes

3. Is SPF still relevant for email security?

Yes, SPF remains highly relevant for email security. Google requires all email senders to implement either SPF or DKIM, and SPF is a fundamental component of email authentication when combined with DKIM and DMARC.

4. Can I have multiple SPF records for different subdomains?

Yes. While you can only have one SPF record per domain, each subdomain can have its own separate SPF record. If you are using subdomains to send email, you need to set up SPF records for each subdomain separately if your provider allows it, since SPF policy is not inherited from the root domain.

5. What’s the difference between ~all and -all in SPF records?

~all (softfail) means emails from unauthorized sources should be accepted but marked as suspicious, while -all (hardfail) means emails from unauthorized sources should be rejected. Start with ~all to monitor results, then move to -all for stricter enforcement once you’re confident your SPF record is complete.