A legitimate message can still land in spam when its sending server is not authorized in your DNS. When you configure SPF email records correctly, receiving mail systems can verify that a server is allowed to send email for your domain. That helps protect your reputation, improves deliverability, and reduces the chance that someone can impersonate your business.
SPF is not difficult once you know which services send mail on your behalf. The risk is guessing. A single missing sender can cause invoices, contact-form alerts, newsletters, or staff email to fail authentication. The right approach is to map your email services first, then publish one accurate SPF record.
What an SPF record does
SPF stands for Sender Policy Framework. It is a DNS TXT record that lists the servers and platforms permitted to send mail using your domain in the envelope sender address, sometimes called the return path.
When a receiving server gets a message from `yourdomain.com`, it checks the SPF record for that domain. If the sending server matches an authorized source, SPF passes. If it does not match, SPF can fail. The receiving system then considers that result alongside other signals, including DKIM, DMARC, message content, and the sender’s reputation.
SPF alone does not guarantee inbox placement. It is one part of a sound email authentication setup. Still, it establishes a clear rule: only approved systems should send for your domain.
Before you configure SPF email records
Start by making a complete list of every system that sends email from your domain. This is the step that prevents most problems. Your list may include your mailbox provider, website hosting server, contact forms, ecommerce platform, accounting software, help desk, CRM, and email marketing provider.
Be precise about the domain each service uses. A newsletter sent from `news.yourdomain.com` may need its own SPF policy, while a staff mailbox using `yourdomain.com` belongs in the main domain’s record. Some platforms send with their own domain by default and do not need to be added unless you have configured a custom return path.
Also confirm where your DNS is managed. Your domain may be registered with one provider while its authoritative DNS is hosted elsewhere. Adding a record in the wrong control panel changes nothing. If your domain uses Raphus nameservers, manage the DNS record in the relevant domain or hosting DNS zone. If it uses external nameservers, make the change with that DNS provider instead.
SPF record syntax in plain English
An SPF record is published as a TXT record. It begins with `v=spf1`, followed by mechanisms that identify approved senders, and ends with a policy qualifier.
A simple example looks like this:
`v=spf1 include:_spf.google.com -all`
This authorizes Google Workspace to send mail for the domain. The `include` mechanism tells receiving servers to evaluate Google’s published SPF policy as part of yours. The `-all` at the end states that all other sending servers should fail SPF.
Another common example for a domain that sends from a specific server IP address is:
`v=spf1 ip4:203.0.113.25 -all`
Replace the example address with your actual outgoing mail server IP address. If you use both an email platform and a hosted server, you can combine approved sources into one record:
`v=spf1 include:_spf.google.com ip4:203.0.113.25 -all`
Common SPF mechanisms include `ip4` for an IPv4 address, `ip6` for an IPv6 address, `a` to authorize the IP address associated with a domain’s A record, `mx` to authorize mail exchanger servers, and `include` for an external provider’s SPF record. For most small businesses, provider-supplied `include` values and clearly documented server IP addresses are safer than broad `a` or `mx` mechanisms.
Create the TXT record
Open the DNS management area for your domain and look for existing TXT records. Search specifically for a value beginning with `v=spf1`.
Your domain must have only one SPF TXT record. This point matters because multiple SPF records can produce a PermError result, meaning the receiver cannot reliably evaluate your policy. If you find an existing SPF record, edit and expand it rather than creating a second one.
Create or update the record with these typical fields:
- Type: TXT
- Host or Name: `@` for the root domain, unless your DNS panel specifies the full domain name
- Value: Your complete SPF policy, beginning with `v=spf1`
- TTL: Use the default value unless you have a reason to set a shorter period while testing
DNS control panels vary, but the underlying record is the same. Do not add extra quotation marks unless your provider’s interface does so automatically. Do not paste an SPF record into an MX or CNAME field.
Choose `-all`, `~all`, or `?all` carefully
The final part of the record tells receivers how to treat sources that are not authorized.
`-all` is a hard fail. It is generally the right end state when you are confident that every legitimate sender has been included. It provides the clearest policy and works well with a properly configured DMARC record.
`~all` is a soft fail. It signals that unauthorized sources are probably not legitimate, but it gives receiving servers more discretion. This can be useful during a short migration or audit when you are still identifying mail sources.
`?all` is neutral and offers little protection. It is rarely a good long-term choice because it does not express a meaningful policy.
For a newly organized domain, begin with `~all` only if you need a cautious testing period. Review mail activity promptly, update the record for any valid sender you missed, and move to `-all` once the policy is complete. Leaving a soft fail indefinitely weakens the value of the record.
Avoid the SPF lookup limit
SPF has a technical limit that catches many growing businesses: an evaluation may use no more than 10 DNS lookups. Every `include`, `a`, `mx`, `exists`, `redirect`, and some nested provider policies can contribute to that total.
If you exceed the limit, SPF returns a PermError. That is not a minor warning. Mail receivers may treat it as a failed or unreliable authentication result.
This is why an SPF record should not become a running list of every tool your business has ever tested. Remove providers you no longer use. Ask each active provider for its current SPF guidance, because values can change. If you send through several third-party services, review their documentation and consider whether each one truly sends with your domain in the envelope sender.
Avoid online “SPF flattening” shortcuts unless you understand how they are maintained. Flattening replaces includes with IP addresses, which can reduce lookups but can also break without notice when a provider changes its infrastructure. For most organizations, simplifying the sender list is more reliable than copying a long flattened policy.
Test after publishing
DNS changes may appear quickly, but propagation depends on the record’s TTL and resolver caching. Give the change time, then confirm that the public TXT result matches exactly what you intended to publish.
Next, send test messages from every authorized platform to a mailbox you can inspect. Review the message headers for an SPF result such as `spf=pass`. Test not only staff email but also website forms, order confirmations, password resets, and marketing messages. These are often sent by separate systems.
If SPF fails, compare the sending IP address or return-path domain in the headers with your SPF policy. The problem is usually one of three things: the service was not included, the platform is using a different sending domain than expected, or the DNS record was edited in the wrong zone.
SPF works best with DKIM and DMARC
SPF verifies the server used for the envelope sender. DKIM adds a cryptographic signature that shows the message was authorized by the signing domain and was not altered in transit. DMARC then checks alignment and tells receivers how to handle messages that fail authentication.
For business email, configure all three. A message can pass SPF but still fail DMARC if the visible From domain does not align with the SPF-authenticated domain. DKIM alignment can provide an alternative path to DMARC compliance, which is particularly useful with mailing platforms that use a separate return path.
Treat SPF as an operational record, not a one-time setup task. Review it whenever you move hosting, change mailbox providers, add a marketing tool, or retire a service. A clean, current record gives your customers and partners a clearer signal that messages from your domain are genuinely yours.