Copy-paste SPF snippets for the services UK businesses actually use: Microsoft 365, Google Workspace, SmartXHosting email, Mailchimp, SendGrid, Mailgun, Amazon SES, HubSpot, Zoho, Klaviyo, Salesforce and more. Every example is annotated with the lookup cost it consumes, the recommended terminator, and the common gotchas.
A domain must publish exactly one SPF record. If you send from Microsoft 365 for staff mail, Mailchimp for marketing, and a dedicated transactional service, you do not publish three SPF records — you publish one record that chains them together with multiple include: mechanisms.
The structure is always the same:
v=spf1 [mechanism-1] [mechanism-2] [mechanism-3] ... [~- terminator]Mechanisms are space-separated. Order rarely matters (each mechanism is evaluated against the connecting IP; the first match wins). The terminator is always ~all during rollout and -all at steady state.
Track your lookup budget as you combine. Aim to stay under 9 to leave headroom; the 10th lookup is too close to the cliff.
v=spf1 include:spf.protection.outlook.com -allLookup cost: Microsoft's include expands to roughly 10 IPv4 and 10 IPv6 ranges at the leaf, via nested macros — typically counted as 2-3 lookups by evaluators. Check your domain's actual usage with a lookup counter.
Notes:
include:spf.protection.outlook.com as the single canonical entry — do not try to list individual Microsoft IP ranges manually.ip4: or a: mechanism for the on-premises Edge Transport servers in addition to the Microsoft include.v=spf1 include:_spf.google.com -allLookup cost: Google's SPF is heavily nested — _spf.google.com includes three further _netblocks records. Typically 4 lookups consumed for Google Workspace alone.
Notes:
v=spf1 include:_spf.smartxhosting.uk -allLookup cost: 1 lookup for the include itself; 0-1 further depending on current infrastructure. Typically 1-2 lookups total.
Notes:
epost.plus namespace.include:servers.mcsv.netSingle flat lookup. Mailchimp recommends also signing with DKIM using a custom authentication domain — follow their "Set Up Email Domain Authentication" guide.
include:hubspotemail.netSingle lookup. HubSpot uses separate ranges per portal; the include macro handles the mapping automatically.
include:_spf.klaviyo.comSingle lookup. Klaviyo requires dedicated sending domain setup for branded tracking and DKIM; SPF alone is not enough for good deliverability.
include:spf.activecampaign.comOne to two lookups depending on current expansion.
include:_spf.getresponse.comPopular in the UK SME marketing space. Single lookup.
include:spf.createsend.cominclude:sendgrid.netSingle flat lookup. SendGrid also requires CNAME records for DKIM signing — the SPF include alone does not authenticate messages; always configure DKIM alongside.
include:mailgun.orgUK accounts may additionally need include:eu.mailgun.org depending on region. Check the sending domain settings in the Mailgun dashboard.
include:spf.mtasv.netSingle lookup. Postmark strongly recommends DKIM + DMARC alongside.
include:sparkpostmail.cominclude:amazonses.comSingle lookup. The include covers all AWS regions; you do not need separate entries per region. SES also publishes a regional variant (eu-west-1.amazonses.com and similar) — the generic include is sufficient for most UK deployments.
If you are on a dedicated IP plan with Postmark, add the specific IP with ip4: alongside the main include.
include:_spf.salesforce.comCovers Salesforce core send-from-my-domain functionality, Pardot and Marketing Cloud send infrastructure.
include:zoho.euFor UK-hosted Zoho accounts, use zoho.eu; for the US datacentre, use zoho.com. Check the admin console.
include:spf.pipedrivemail.cominclude:_spf.freshemail.netinclude:mail.docusign.netinclude:spf.surveymonkey.comTypeform does not publish a dedicated SPF include. Their outbound mail is sent from typeform.com subdomains — your own domain does not need to authorise them for survey responses, since those go from Typeform to respondents, not via your domain.
include:spf.adobesign.cominclude:pandadoc.netinclude:spf.messagingengine.comFastmail is the email engine behind many UK third-party services as well as its own consumer offering.
Proton publishes per-plan includes. The Business plan uses:
include:_spf.protonmail.chinclude:zohomail.euUK/EU datacentre. The US variant is zohomail.com. Consult the admin console if unsure.
include:icloud.comFor Apple Business custom-domain email deployments.
When a sender does not publish an SPF include — perhaps it is an internal monitoring tool, a legacy server, or a dedicated transactional service — you add its IP directly:
ip4:203.0.113.25 # single IPv4
ip4:203.0.113.0/24 # IPv4 range (256 addresses)
ip6:2001:db8::25 # single IPv6
ip6:2001:db8::/32 # IPv6 range
a:legacy-mail.firm.co.uk # IP backing this hostname's A record
mx:gateway.firm.co.uk # all IPs backing this domain's MX recordsAlways prefer ip4:/ip6: (zero lookups) over a:/mx: (one lookup each) when possible. The difference becomes material once you have several senders.
freelancer.co.uk. IN TXT "v=spf1 include:_spf.smartxhosting.uk -all"One lookup. Hard-fail terminator. The baseline.
sme.co.uk. IN TXT "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all"Four to five lookups. Covers staff email and marketing newsletters.
retailer.co.uk. IN TXT "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com include:sendgrid.net ~all"Eight to nine lookups. Close to the ceiling — consider flattening the Microsoft and Salesforce includes into explicit ranges, and add DKIM signing for every one of these services.
council.gov.uk. IN TXT "v=spf1 a mx include:spf.protection.outlook.com include:_spf.gov.uk -all"Varies by configuration; roughly six to eight lookups. Public sector bodies often use on-premise MX plus Microsoft 365, plus the centrally managed gov.uk mail infrastructure.
charity.org.uk. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.donorbox.org ~all"Around seven lookups. ~all during rollout gives safety while the charity confirms all donation notifications pass.
parked.co.uk. IN TXT "v=spf1 -all"Zero lookups, zero senders. Combined with DMARC p=reject and a null DKIM, makes the domain unspoofable.
Some UK platforms and vendors are worth calling out specifically because their documentation is harder to find:
NHS.net operates through a centrally managed relay. Organisations that send on behalf of NHS suppliers via NHS.net do not add an NHS-specific include — NHS.net mail is sent from NHS-owned domains. Instead, ensure any DMARC policy on your own domain includes @in.mailhardener.com or equivalent in rua= so NHS receivers can confirm your posture.
If you integrate with HMRC APIs and receive notification emails, those come from HMRC's own infrastructure. No SPF changes needed on your side. Outbound integrations sent from your systems use your existing SPF.
Public sector bodies sending via GOV.UK Notify add:
include:_spf.notifications.service.gov.ukGOV.UK Notify also requires the sending organisation to verify domain ownership through a TXT record.
Sage and Xero notifications to your customers are sent from sage.com and xero.com respectively — not from your domain. No SPF changes required. Invoices sent "from your domain" via Xero's custom-domain feature require:
include:_spf.xero.comWHMCS sends from the server it is installed on. SPF is configured as per the underlying mail server's IP — typically already covered by your main include if WHMCS runs on the same hosting.
Jisc Mail is the UK academic sector's list management platform. Outbound mail uses:
include:spf.jiscmail.ac.ukFor universities whose DMARC policy must accept Jisc Mail forwarding, configure ARC at the receiving gateway as well.
A 15-partner Bristol law firm came to us after their clients reported receiving convincing invoice scams purporting to come from partners' email addresses. Investigation showed the firm had no SPF, no DKIM, and no DMARC. The criminals had been spoofing the domain for six months, invoicing clients' accounts payable teams, and intercepting bank details.
The remediation record they ended up with, after identifying every legitimate sender:
law-firm.co.uk. IN TXT "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.clio.com -all"Plus DKIM on Microsoft 365 and Clio, plus DMARC p=reject; adkim=s; aspf=s. The fraud attempts stopped inside 72 hours. The firm also registered two common typosquats and published v=spf1 -all on each for defensive coverage.
A mid-size Manchester charity using Google Workspace, Mailchimp, SendGrid (for donation receipts), Donorbox, Salesforce NPSP, DocuSign, SurveyMonkey, Eventbrite, and three custom web apps. Initial SPF count: 14 lookups — PermError. The charity had to flatten the Google and Salesforce includes to explicit IP ranges and consolidate three of the web apps behind a single transactional service. Final record:
charity.org.uk. IN TXT "v=spf1 ip4:172.217.32.0/20 ip4:173.194.0.0/16 include:_spf.salesforce.com include:sendgrid.net include:servers.mcsv.net include:mail.docusign.net -all"9 lookups, fitting under the ceiling with one lookup of headroom. The IP ranges for Google had to be reviewed twice a year in case Google expanded their infrastructure.
A four-person Leeds SaaS company with mail on SmartXHosting Business Email and transactional receipts through Postmark. Simple, clean:
startup.co.uk. IN TXT "v=spf1 include:_spf.smartxhosting.uk include:spf.mtasv.net -all"2-3 lookups, plenty of room for future growth. DKIM automatic on both. DMARC p=reject from day one because the deliberate greenfield deployment meant they could verify every sender before flipping the switch.
SPF is only one third of the authentication picture. Most of the services above also require DKIM signing (which ties to a DMARC alignment pathway) and benefit from a custom sending subdomain. A summary of what else each class of service typically needs:
| Service type | SPF | DKIM | Custom sending domain | Additional DNS |
|---|---|---|---|---|
| Microsoft 365 | include | Two CNAMEs per tenant | Automatic | Autodiscover, DMARC |
| Google Workspace | include | CNAME per selector | Automatic | DMARC, optional BIMI |
| SmartXHosting email | include | CNAME for default selector | Automatic | DMARC, MTA-STS |
| Marketing (Mailchimp, HubSpot) | include | Two CNAMEs | Strongly recommended | Tracking CNAME |
| Transactional (SendGrid, Mailgun) | include | Two to three CNAMEs | Essential | Tracking, link-branding |
| CRM (Salesforce, Zoho) | include | CNAME | Strongly recommended | Return-Path |
| E-signature (DocuSign, Adobe) | include | CNAME | Optional | — |
| Surveys (SurveyMonkey) | include | CNAME | Optional | — |
An SPF include without a matching DKIM setup means messages may pass SPF but fail DMARC alignment. The standard failure mode: marketing emails arrive from [email protected] rather than [email protected], and customers mark them as spam because the visible sender does not match the brand they expect. The fix is always the same — configure DKIM with a custom sending domain.
An SPF record is not a "set and forget" asset. Maintenance tasks that should appear on every UK IT team's quarterly checklist:
include: and confirm the service is still active and still authorised. Remove anything that has not sent in the last 90 days.After publishing or updating your SPF record, verify that every legitimate service actually passes:
spfcheck command-line utility. Confirm the count is under 10.Authentication-Results in the "Show original" view).spf=pass with the expected smtp.mailfrom domain.rua= tag. Look for any sources that are still failing and add them to SPF (if legitimate) or investigate them (if suspicious).sudo systemd-resolve --flush-caches on Ubuntu).From: but use their own envelope sender. SPF passes on their domain, DMARC alignment fails. Solution: switch the service to a custom sending domain (most allow this with a CNAME).Q: My provider's include is not listed here. Where do I find it?
A: Check the provider's "set up email authentication" or "sending domain configuration" documentation — every reputable provider publishes their SPF include in their help centre. If they do not, treat that as a red flag and consider switching.
Q: What happens if I include a service I no longer use?
A: The include consumes a DNS lookup but otherwise harms nothing specific — no additional senders are authorised that would not have been. However, stale includes add to the 10-lookup pressure and quietly widen your attack surface if the provider's SPF changes. Audit at least annually.
Q: Do I need to include services I only receive email from?
A: No. SPF authorises outbound sending for your domain. Services that send email to you — like survey response notifications from Typeform — send from their own domains, not yours, so they do not belong in your SPF.
Q: Is include:outlook.com the same as include:spf.protection.outlook.com?
A: No. spf.protection.outlook.com is the canonical include. The bare outlook.com domain has its own SPF that covers consumer Hotmail senders — not your Microsoft 365 tenant.
Q: What should I use for a custom domain on Proton Mail Business?
A: Follow the "DNS setup" wizard in Proton's admin — the exact include depends on your plan tier. The Business plan typically uses _spf.protonmail.ch.
Q: How do I test that my combined SPF is working for every service?
A: Send a test message from each service to a known external address (for example an address at Gmail or a personal Fastmail account) and inspect the Authentication-Results header. Every service should produce spf=pass.
Q: Some services say I only need DKIM — do I still need an SPF include?
A: Add the SPF include anyway. SPF and DKIM are independent sources of DMARC alignment; having both gives you redundancy on forwarded mail and improves deliverability on receivers that still weight SPF.
Q: What if a service asks me to publish a TXT record with their provided SPF and I already have one?
A: Merge, do not duplicate. If they say "publish v=spf1 include:service.net -all", what you actually do is add include:service.net to your existing record — you never publish a second TXT starting with v=spf1.
Q: Do shared-IP providers count as separate senders requiring separate includes?
A: Shared-IP providers require the same single include their documentation lists. The infrastructure behind the include handles multi-tenant sending.
Q: How often do providers change their SPF?
A: Rarely for the canonical include macros (they are a stable API); frequently for the underlying IP ranges inside those macros. This is why include: is always preferred to hard-coded IPs — the macro insulates you from upstream changes.
Q: What happens when a provider adds a new sending region? Do I need to update my SPF?
A: If you used the provider's canonical include (for example include:amazonses.com for Amazon SES), the macro is updated centrally and your SPF automatically inherits the new ranges. If you hard-coded specific IPs, you must update manually. This is the single strongest argument for include-based SPF over flattened IP-range SPF in 2026.
Q: My provider does not document their SPF anywhere. What should I do?
A: Contact their support team and ask for the canonical SPF include macro. Any reputable UK provider will publish this. If they refuse or cannot provide one, that is a serious red flag — consider whether the service meets your authentication requirements at all. For small, legacy providers, a hard-coded ip4: range may be the only option, but you then take on the maintenance burden.