A customer receives a fake invoice that appears to come from your domain. Or your real order confirmations land in spam because mailbox providers cannot verify who is allowed to send them. Both problems often start with one overlooked DNS setting. Learning how to set up SPF gives receiving mail servers a clear instruction: these are the services permitted to send email using this domain.
SPF, or Sender Policy Framework, is not a spam filter and it does not encrypt messages. It is an email authentication record stored in DNS. When a receiving server gets a message claiming to be from your domain, it checks the server that actually sent it against your SPF policy. A valid policy helps protect your reputation and makes it harder for attackers to impersonate your business.
What SPF checks and why it matters
SPF checks the sending server’s IP address against the SPF record published for the envelope sender domain. That last detail matters. The visible From address, such as billing@yourdomain.com, may not be the exact address SPF evaluates. This is why SPF works best alongside DKIM and DMARC, which add stronger alignment and reporting controls.
For a small business, SPF is a practical first step toward more trusted email. It can support delivery for business email, website contact forms, invoices, newsletters, support platforms, and WordPress notifications. But it only works when the record includes every legitimate sender.
The trade-off is simple: a strict SPF record improves protection, but it can reject or flag legitimate messages if you forget a platform. Before editing DNS, make a complete inventory of every service that sends mail as your domain.
How to set up SPF step by step
1. List every approved email sender
Start with the services your business uses to send email. Your main mailbox provider is only one piece of the picture. You may also send from your website, an ecommerce platform, a CRM, help desk, accounting system, appointment tool, transactional email provider, or marketing platform.
For example, a business might use Microsoft 365 for employee mail, a transactional provider for password resets, and an email marketing tool for newsletters. Each of those senders needs authorization in SPF, usually through an `include:` value supplied by that provider.
Check each platform’s official SPF documentation or setup screen for its exact value. Do not guess at server IP addresses when the provider gives you an include mechanism. Large services can change infrastructure, and their include record is designed to keep authorization current.
2. Find your DNS manager and check for an existing record
Log in where your domain’s DNS zone is managed. This may be your domain registrar, web host, or a separate DNS provider. Look for DNS records of type TXT on your root domain, often displayed as `@` or your full domain name.
Search for a TXT record beginning with `v=spf1`. If you find one, you already have SPF. You should edit and combine it rather than creating another SPF record.
A domain must publish one SPF record only. Multiple SPF TXT records can cause a permanent error, meaning receiving servers may treat the policy as invalid. This is one of the most common mistakes during email migrations, especially when a business adds Microsoft 365 or Google Workspace after setting up website mail.
3. Build your SPF value
Every SPF record begins with this version tag:
`v=spf1`
You then add mechanisms that authorize the services on your inventory. Here are common examples:
`v=spf1 include:spf.protection.outlook.com -all`
This authorizes Microsoft 365 to send mail for the domain. A Google Workspace setup commonly uses:
`v=spf1 include:_spf.google.com -all`
If you use an email provider’s SMTP server directly, it may require an `a`, `mx`, or `ip4` mechanism. A simple example is:
`v=spf1 a mx ip4:198.51.100.25 -all`
This means mail is permitted from the IP address of the domain’s A record, the servers listed in its MX records, and the stated IPv4 address. In practice, `a` and `mx` are not automatically safer or easier. Use them only when those hosts genuinely send your outbound mail.
For a domain using Microsoft 365 plus a marketing platform, the record could look like this:
`v=spf1 include:spf.protection.outlook.com include:spf.examplemail.com -all`
The second include above is only an illustration. Replace it with the precise include value from your provider. Never copy a sample record without confirming it applies to your account and sending service.
4. Choose the right ending: `-all` or `~all`
The final part of the record tells receivers what to do with senders that are not authorized. `-all` is a hard fail. It states that all other senders are unauthorized. `~all` is a soft fail, which signals that unlisted senders are probably not authorized but leaves more discretion to the receiving server.
If you have completed your sender inventory and tested the record, use `-all`. It provides a clearer policy. If you are still moving email systems or tracking down older applications, `~all` can be a short-term staging option. Do not leave it there indefinitely just because it feels safer. A permissive SPF policy weakens the protection you are trying to build.
Avoid `+all` completely. It effectively authorizes any server on the internet to send mail for your domain.
5. Add or update the DNS TXT record
In your DNS manager, create a TXT record if none exists. Enter `@` as the host or name field when your provider uses that symbol for the root domain. Paste the complete SPF value into the content or value field.
Use the default TTL unless you have a reason to set a different value. A shorter TTL can be useful before a planned mail migration, but it will not fix a bad record. DNS updates may appear quickly, yet some systems can take several hours to recognize them consistently.
If an SPF TXT record already exists, merge the new authorization into that one line. For example, add a new `include:` before the final `-all`, then save the revised single record.
6. Test the record before relying on it
After publishing, send messages to accounts at major mailbox providers and inspect the message headers. Look for an authentication result such as `spf=pass`. Test messages from every sending path, not just your personal mailbox.
Pay close attention to website forms, WordPress notifications, invoices, and support tickets. These messages are often sent by a different system than employee email. If a message fails SPF, compare the sending domain and server in the headers with the services listed in your record.
SPF limits that can quietly cause failures
SPF has a DNS lookup limit of 10. Many `include:`, `a`, `mx`, `redirect`, and `exists` mechanisms trigger lookups. If your policy exceeds the limit, SPF can return a PermError even if every individual provider entry looks correct.
This becomes more likely when a domain accumulates old marketing, CRM, and email forwarding services over time. Remove platforms you no longer use. If you genuinely need several senders, review the provider documentation carefully and consider separating mail streams onto subdomains. For example, keep employee email on your main domain and send newsletters from a dedicated marketing subdomain.
Be cautious with SPF flattening services that convert include records into IP lists. They can reduce lookups, but the IP list must stay updated whenever a provider changes infrastructure. For most small businesses, a clean record with only necessary includes is easier to maintain.
SPF is stronger with DKIM and DMARC
SPF alone does not fully stop From-address spoofing. Forwarded mail can fail SPF because the forwarding server is not in your authorized list. Also, SPF may pass for a different envelope sender domain than the visible From address.
DKIM adds a cryptographic signature to outgoing mail, while DMARC checks whether SPF or DKIM aligns with the domain customers see in the From field. DMARC also gives you a policy for handling failures and reports that reveal unauthorized senders.
Set up SPF first, then enable DKIM on every major sending platform, and add a DMARC record in monitoring mode. This sequence gives you visibility before you move toward stricter enforcement. It is a practical path that protects deliverability without taking unnecessary risks with business-critical email.
Your domain is part of your business identity. Keep a record of every authorized sender, review SPF whenever you add or retire a tool, and make DNS changes deliberately. If you manage your domain and hosting through GiddyHost, keeping those core services organized in one place can make ongoing email authentication far less stressful.