SPF (Sender Policy Framework)

SPF (Sender Policy Framework) uses a DNS record to list the servers authorized to send for a domain. Receiving servers check the sender’s IP address against that record. SPF works with DKIM and DMARC to authenticate email.

How SPF works

The domain owner publishes a TXT record that starts with v=spf1 and names the IP addresses, hosts, and third-party services allowed to send for the domain. When a message arrives, the receiving server reads the Return-Path (envelope sender) domain, queries that domain's DNS for the SPF record, and compares the IP address of the connecting server against the list. The qualifier on the final all mechanism determines the SPF result for a sender that has not matched an earlier mechanism. -all asks for a hard fail and ~all asks for a soft fail. The receiving server decides how that result affects delivery.

SPF checks the Return-Path domain, not the From address the recipient sees. A message can pass SPF and still fail DMARC if those two domains do not align.

Common mistakes

• Exceeding the 10-DNS-lookup limit. Remove unused include: entries and drop a or mx mechanisms you do not need.

• Changing ~all to -all without checking your provider’s guidance and legitimate senders. These produce softfail and fail results respectively; neither guarantees a particular delivery outcome.

• Treating an SPF pass as a DMARC pass. For DMARC to use an SPF pass, the authenticated envelope domain must align with the visible From domain. An aligned DKIM pass can satisfy DMARC even when SPF does not.

• Publishing the record on the wrong host. SPF checks the SMTP MAIL FROM domain, or the HELO identity when the reverse-path is empty. Publish the TXT record at the domain being checked, such as example.com. A separate host such as _spf.example.com can hold a policy referenced through include:.

Check your SPF record

Enter the envelope sender hostname in the DNS checker. Check the exact name your email provider supplies, which may be a subdomain rather than your website’s root. The result shows published DNS records; confirm a real message’s SPF and DMARC results in its authentication headers too.

How to fix multiple SPF records

Two TXT records beginning with v=spf1 at the same hostname cause an SPF permerror. Other TXT records, such as domain verification records, can stay. A single TXT record split into quoted strings is different from two separate SPF records.

1. Identify every service that legitimately sends using that envelope domain.

2. Use each service’s current SPF instructions to combine the required mechanisms into one v=spf1... policy. Keep one v=spf1 prefix and one final all mechanism.

3. Check the DNS-querying term limit, including nested includes. It is not simply a count of visible include: entries.

4. Replace the duplicate SPF records at that hostname with the combined record, then recheck DNS and send a test message from each service.

These rules come from RFC 7208. Do not combine policies that belong to different hostnames.

Google Workspace SPF with Loops

If Google Workspace is the only sender using that envelope domain, Google’s published starting record is v=spf1 include:_spf.google.com ~all. If other services use the same envelope domain, follow Google’s SPF setup guide to include them in one policy.

Loops supplies its SPF record at envelope.sendingdomain.com. It does not need to be merged into Google Workspace’s root-domain SPF record. Copy the exact hostname and value from your Loops account using the sending-domain setup guide.

SPF is one part of authentication. Use the DMARC record generator to prepare your policy and the deliverability guide to check the rest of your email program.

Related: DKIM, DMARC, Email authentication, Email deliverability, Inbox placement, Sender reputation.