How to Configure SPF Records for Your Small Business Email

Email remains the primary attack vector for cybercriminals targeting small businesses, and your organisation's reputation is only as secure as your email infrastructure. SPF records for small business are one of the most underutilised yet critical defences available, yet many London SMBs operate without them—or worse, with misconfigured ones. Whether you're in professional services, legal practice, or financial advisory, email authentication isn't optional anymore; it's essential. This guide walks you through configuring SPF records properly, ensuring your business emails reach inboxes whilst protecting your domain from spoofing and impersonation attacks.

What SPF Records Actually Do (And Why They Matter)

Sender Policy Framework (SPF) is a DNS authentication protocol that prevents bad actors from sending emails on behalf of your domain. When someone claims to send an email "from" your organisation, receiving mail servers check your SPF record to verify that the sending server is authorised to do so.

Think of it this way: without SPF, anyone can claim to be your company in an email header. A criminal could impersonate your managing director asking for urgent funds transfer, or pose as a trusted partner requesting sensitive information. SPF adds a cryptographic layer of verification that's checked automatically by email providers.

For professional services firms, legal practices, and financial advisers, the stakes are particularly high. Client trust depends on secure communications. A single spoofed email pretending to be from your firm could result in:

• Client funds being misdirected to fraudulent accounts
• Reputational damage and loss of client confidence
• Regulatory compliance violations (FCA, SRA, or relevant bodies may expect email authentication)
• Your legitimate emails landing in spam folders because major providers distrust unauthenticated senders

SPF records are free to implement and take less than an hour to configure correctly—yet they're your first line of defence in email authentication. DMARC and DKIM provide additional layers, but SPF is the logical starting point.

How to Create and Configure Your SPF Record

Understanding SPF Syntax Basics

SPF records live in your domain's DNS settings and follow a specific format. Here's a simple example:

v=spf1 include:_spf.google.com ~all

Let's break down what this means:

• v=spf1 – Identifies this as an SPF version 1 record (the current standard)
• include:_spf.google.com – Authorises Google's mail servers (useful if you use Google Workspace)
• ~all – The "softfail" mechanism; it says "I'm not entirely sure about other servers, but they're probably not authorised"

The final mechanism is crucial. -all (hardfail) means "reject any email not explicitly authorised." ~all (softfail) is more lenient and is recommended during initial setup. You can transition to hardfail once you've tested thoroughly.

Step-by-Step Configuration Process

1. Identify all your email sources

Before writing any SPF record, list every service that sends emails on behalf of your domain:

• Your primary email provider (Google Workspace, Microsoft 365, Proton Mail, etc.)
• Marketing automation tools (HubSpot, Mailchimp, Constant Contact)
• Customer relationship management systems (Salesforce, Pipedrive)
• Transactional email services (SendGrid, Mailgun, AWS SES)
• Backup MX services or disaster recovery systems
• Any third-party integrations that send notifications or reports

This is critical. If you forget to authorise a legitimate sender, their emails may be rejected or marked as spam.

2. Locate your DNS provider and access settings

Your DNS is typically managed through:

• Your domain registrar (e.g., GoDaddy, Nominet, 123-reg)
• A separate hosting provider or DNS management service
• Your IT support company (such as VantagePoint Networks, who manage DNS for many London SMBs)

Log in and find the DNS records section—you'll be looking for an option to create or edit TXT records.

3. Build your SPF record string

Most email providers publish SPF include strings in their documentation. For example:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• HubSpot: include:hubspotemail.net

A typical SMB record might look like this:

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

4. Add the record to DNS

Create a new TXT record with:

• Name/Host: @ (this represents your root domain)
• Type: TXT
• Value: Your complete SPF string from step 3
• TTL: 3600 or 1 hour (standard setting)

Save and allow 24–48 hours for DNS propagation globally, though many providers update within minutes.

5. Test your record

Use free SPF checking tools like MXToolbox or Google's Admin Toolbox to verify your record is published and correctly formatted. These tools will also alert you to common errors, such as exceeding the 10 DNS lookup limit (a technical constraint that can invalidate complex SPF records).

Common SPF Mistakes and How to Avoid Them

Even well-intentioned implementations often contain errors that reduce effectiveness:

• Multiple SPF records: DNS allows only one SPF record per domain. If you create two, mail servers ignore both. Use "include:" statements instead to reference multiple services within a single record.
• Exceeding the lookup limit: SPF records trigger DNS lookups; going over 10 can cause authentication to fail. If you have many authorised senders, consolidate services or negotiate SPF consolidation with your providers.
• Using IP addresses instead of includes: Hardcoding IP addresses is rigid and breaks when providers change infrastructure. Always use "include:" references.
• Forgetting the softfail transition: Jump straight to "-all" (hardfail) and you risk blocking legitimate emails. Start with "~all" for at least two weeks whilst monitoring bounce-backs.
• Not updating after adding services: When you implement new marketing tools or integrations, remember to update your SPF record immediately. Many "authentication failures" are simply missing authorisations.

Moving Beyond SPF: The Complete Email Defence Picture

SPF is foundational, but it's not the complete solution. Email impersonation can be sophisticated. Genuine defence requires a layered approach:

• DKIM (DomainKeys Identified Mail): Cryptographically signs emails to prove they genuinely came from your domain, even if forwarded. Most email providers set this up automatically.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): A policy layer that tells receiving servers what to do with emails that fail SPF or DKIM checks. It also provides reporting, so you can monitor
  From VantagePoint Networks

  Check Your Domain Security for Free

  VP Shield runs six passive checks across DNS, TLS, headers, SPF, DKIM, DMARC and subdomain takeover — no login, no install, no port scans. Results in 15 seconds.

  Scan your domain now →