Setting Up an SPF Record for Gmail and Google Workspace

SPF (Sender Policy Framework) tells the world which mail servers are allowed to send email on your domain’s behalf. Without it, anyone can forge a “from” address that looks like it came from you, and there’s nothing stopping a receiving server from accepting it. SPF is the first of the three DNS records (alongside DKIM and DMARC) that make up basic email authentication.

How SPF Works

SPF is a single DNS TXT record published on your domain. It lists the servers and services authorized to send mail as you. When another mail server receives a message claiming to be from your domain, it checks the sending server’s IP against your SPF record. If the IP isn’t listed, the message fails SPF and is more likely to be flagged as spam or rejected outright.

Prerequisites

• Access to your domain’s DNS settings (registrar or DNS host)
• A list of every service that sends email on your domain’s behalf (Google Workspace, your CRM, your marketing platform, your app’s transactional email service, etc.)
• Google Workspace admin access, if you’re including Gmail as a sender

Missing a sender in this list is the single most common cause of SPF-related deliverability problems, so build the list first before touching DNS.

Adding the Record

1. In your DNS host, create a new TXT record for your root domain (@).
2. Set the value to v=spf1 include:_spf.google.com ~all if Google Workspace is your only sender.
3. If you send from additional services, add each one as its own include: mechanism inside the same record, for example: v=spf1 include:_spf.google.com include:sendgrid.net ~all.
4. Save and wait for DNS propagation (can take a few minutes to a few hours).

Common Syntax Errors

• Multiple SPF records for one domain. A domain can only have one SPF TXT record. If you need multiple senders, they all go inside a single record’s include: list, not separate records.
• Too many DNS lookups. SPF allows a maximum of 10 DNS lookups per check. Each include: typically costs one lookup, and some third-party senders (mailing list tools especially) chain multiple lookups internally. Exceeding the limit causes a permanent SPF failure, not a warning.
• Using -all before you’re ready. -all (hard fail) tells receivers to reject anything not listed. ~all (soft fail) flags it instead. Start with ~all, confirm every legitimate sender is covered by monitoring your mail logs or DMARC reports, then move to -all once you’re confident nothing legitimate will be blocked.

Troubleshooting

• Record not found: DNS propagation delay, or the record was added to a subdomain instead of the root domain.
• SPF passes but mail still lands in spam: SPF alone doesn’t guarantee inbox placement. It needs to be paired with DKIM and, ideally, a DMARC policy that ties the two together.
• Third-party sender not authenticating: the sender’s own include: domain wasn’t added, or the sender is using a different sending domain than the one documented in their setup guide.

Where SPF Fits with DKIM and DMARC

SPF verifies the sending server. DKIM verifies the message content wasn’t altered in transit. DMARC tells receiving servers what to do when either check fails, and gives you visibility into who’s sending mail as your domain. All three should be configured together for reliable authentication and deliverability.