SPF Configuration

What SPF does

Sender Policy Framework (SPF) is a DNS TXT record listing the servers authorised to send mail using your domain in the envelope sender, also called the return-path. When a message arrives, the receiving server checks the connecting IP against that list. SPF is one of the two mechanisms, alongside DKIM, that DMARC relies on.

A record looks simple, for example v=spf1 include:_spf.example-provider.com ip4:203.0.113.10 -all, but small mistakes cause failures that nobody notices until mail starts disappearing.

It is also easy for an SPF record to drift. Each new marketing tool, helpdesk or billing platform asks you to add an include, and nobody removes the old ones when a service is cancelled. Over time the record grows until it breaks the lookup limit or authorises services you no longer use, which is a small but real security risk.

Signs your SPF needs work

• Headers show spf=permerror, often from too many DNS lookups.
• Your domain has two separate SPF records, which is invalid.
• The record still includes services you stopped using years ago.
• A new tool you added sends mail that fails SPF.
• DMARC reports show SPF passing but not aligning with your From domain.

The 10-lookup limit, explained

SPF allows at most ten DNS lookups while evaluating a record. Mechanisms like include, a, mx, exists and redirect each count, and includes inside includes count too. Exceed the limit and the result is a permanent error, which receivers may treat as a failure. Because each provider’s include can itself contain several lookups, adding a few services is enough to cross the line.

We fix this by removing unused includes, replacing a and mx mechanisms with explicit IPs where appropriate, and moving some senders to their own subdomain with a separate SPF record. We avoid over-aggressive “flattening” that copies provider IPs into your record, because those IPs change and the record silently goes stale.

What’s included

• An inventory of every service that sends mail as your domain: office mail, marketing, CRM, helpdesk, billing, website.
• A single, valid SPF record for each sending domain and subdomain.
• Lookup count checked and kept safely below the limit.
• The right ending: ~all or -all, chosen with your DMARC plan in mind.
• Return-path or MAIL FROM domains set up on each platform so SPF aligns for DMARC.
• Verification from real messages, not just a syntax checker.

How we deliver it

1. Read the current record and any DMARC aggregate reports.
2. Build the sender inventory with your team.
3. Draft the new record and calculate its lookup count.
4. Publish, wait for propagation, and check from several resolvers.
5. Send test mail from each source and confirm spf=pass in the headers.
6. Document which service each part of the record belongs to.

Where a platform can’t use a custom return-path, we note it, since its mail will need DKIM alignment to satisfy DMARC instead.

SPF in the bigger picture

SPF alone doesn’t stop spoofing of the visible From address, and it breaks when mail is forwarded. That is why it works alongside DKIM and DMARC. Gmail and Yahoo expect bulk senders to have SPF and DKIM in place with DMARC aligned, so correct SPF is part of meeting their requirements for permission-based mail.

What affects timeline and cost

• Number of sending services and domains.
• Whether platforms support custom return-path domains.
• Access to DNS and to each platform’s settings.
• Whether DKIM and DMARC are being done at the same time.

Common SPF mistakes

• Publishing a second SPF record instead of editing the first.
• Using +all, which authorises the entire internet.
• Relying on ptr, which is discouraged and slow.
• Adding every include a vendor’s help page suggests, whether or not you use it.
• Assuming SPF pass means DMARC pass, when alignment may be missing.

Read the email infrastructure guide, browse email infrastructure services, or contact us.

Frequently asked questions