What Is an SPF Record? How It Works and How To Set It Up

What is an SPF record?

SPF, or Sender Policy Framework, is an email-authentication standard defined in RFC 7208. A domain owner publishes a TXT record containing rules that authorize IP addresses and sending services. When a message arrives, the receiving server compares the connecting IP with the SPF policy for the SMTP MAIL FROM domain. If MAIL FROM is empty, the receiver can evaluate the HELO domain instead.

This distinction matters: SPF does not directly authenticate the address readers see in the From field. DMARC connects an authenticated SPF or DKIM domain to the visible From domain through alignment. Use all three controls together for stronger protection.

Why use an SPF record for email?

A correct SPF policy gives mailbox providers a reliable way to identify infrastructure that is allowed to use your envelope-sender domain. It supports security and deliverability, but it does not guarantee Inbox placement.

Reduce domain spoofing

Unauthorized systems cannot produce an SPF Pass for a protected envelope-sender domain unless they match its published policy. With DMARC alignment, this also helps protect the domain displayed to recipients.

Support deliverability

Mailbox providers combine SPF with DKIM, DMARC, reputation, content, and local policy. A valid SPF record removes one common authentication problem, but a Pass is only one signal and a Fail does not prescribe one universal delivery action.

Protect domain reputation

Clearly documenting legitimate senders makes it easier to identify configuration drift and unauthorized activity. It also reduces the risk that missing authentication will contribute to filtering or a DNS blacklist problem.

How SPF works

1. The sending system opens an SMTP connection.
2. The receiving server identifies the MAIL FROM/Return-Path domain. If it is empty, it can use HELO.
3. The receiver retrieves that domain’s SPF TXT policy.
4. It evaluates mechanisms from left to right against the connecting IP address.
5. The evaluation returns Pass, Fail, Softfail, Neutral, None, TempError, or PermError.
6. The receiver combines this result with DKIM, DMARC, reputation, and its own filtering policy.

SPF evaluates the transmission path, not the message body. Forwarding can therefore break SPF because the forwarder’s IP may not be authorized by the original domain. Sender Rewriting Scheme (SRS) can help a forwarding service use a new aligned envelope sender.

An SPF result is evidence, not a delivery command. For example, ~all produces Softfail when no previous mechanism matches; it does not force every receiver to put the message in spam. Likewise, SPF Pass does not guarantee Inbox delivery.

SPF record syntax explained

A simple Selzy-oriented policy can look like this:

If the domain already sends through another provider, combine all authorized services into one policy. Do not publish a second v=spf1 record.

Qualifiers define the result when a mechanism matches: + Pass (the default), - Fail, ~ Softfail, and ? Neutral. Avoid +all, which authorizes every sender. The ptr mechanism is deprecated and should not be used.

Rules and limits that commonly break SPF

• Publish only one SPF policy per domain.
• Merge every legitimate sender into that record.
• Keep DNS-query-causing terms within the RFC processing limit of 10. Nested include chains count too.
• Too many lookups or malformed terms can produce PermError.
• Temporary DNS failures can produce TempError.
• Avoid unnecessary a, mx, and exists chains.
• Review the record whenever you add or remove a sending service.

How to add an SPF record

1. Inventory the Return-Path and every sender

List all platforms that send on behalf of your domain: your mailbox provider, Selzy, transactional systems, help desk, CRM, invoicing tools, and any custom servers. Send a real test message from each service and inspect the Return-Path and Authentication-Results headers. The Return-Path may differ from the visible From address.

2. Get the current Selzy settings

In Selzy, open Account → Settings → Domain Authentication, select Create, enter the domain, and choose Obtain Settings. Copy the exact DNS values shown in the account. Current Selzy documentation uses include:spf.selzy.com, but the account-generated settings are the final source of truth.

Open the Domain Authentication section and create a domain entry.

Enter the domain without a page path and obtain its authentication settings.

Selzy will show the DNS records that must be published. If an SPF policy already exists, add Selzy’s include to that policy instead of creating another SPF record.

3. Publish one TXT policy in DNS

Open your DNS provider and add or edit the TXT record for the sending domain. Provider labels vary, but the fields usually mean:

• Type: TXT.
• Host/Name: @, blank, or the domain, depending on the provider.
• Value: the complete policy beginning with v=spf1.
• TTL: the provider default is normally acceptable.

Some interfaces append the domain automatically, so confirm the final DNS name before saving.

Create or edit the TXT record in the DNS zone. Never split authorized providers into multiple v=spf1 records.

Allow time for DNS caches to refresh. Changes are often visible quickly but can take longer depending on the previous TTL. Then return to Selzy and verify domain authentication.

How to check an SPF record

Use more than one verification method:

1. DNS lookup: confirm that the expected TXT policy is publicly visible and that only one SPF record exists.
2. SPF checker: review syntax, expanded includes, and DNS lookup count with a tool such as MXToolbox.
3. Real-message test: send through each authorized platform and inspect Authentication-Results and Received-SPF. Confirm which domain was evaluated and whether it aligns with the visible From domain for DMARC.

A DNS lookup should return the policy you intended to publish. If nothing appears, check the host name, record type, and DNS delegation.

A syntax checker can identify malformed terms, but a syntactically valid record may still omit a legitimate sender or exceed the lookup limit after includes are expanded.

Review warnings as well as the pass/fail indicator. Test a real message from every sending service.

If a tool reports an error, fix the underlying policy rather than adding a second SPF record.

Common SPF errors and fixes

SPF implementation checklist

• Inventory every service that sends email for the domain.
• Confirm the MAIL FROM/Return-Path used by each service.
• Collect official SPF include values from providers.
• Merge them into one policy.
• Validate syntax and the 10-lookup processing limit.
• Publish the TXT record and wait for DNS caches to refresh.
• Test real messages from every sender.
• Enable DKIM and DMARC and check alignment.
• Review SPF whenever sending infrastructure changes.

SPF is most useful when it is accurate, compact, and maintained. Treat it as one part of an authentication system — not as a guarantee of delivery or a complete defense against phishing.