What is the SPF file format?

An SPF record is a DNS TXT record that tells receiving mail servers which IP addresses and sending services are authorized to send email on behalf of your domain. It is one of the three core email authentication standards, alongside DKIM and DMARC, and it plays a foundational role in protecting your domain from spoofing and improving deliverability. The sections below walk through how SPF configuration works in practice, from DNS mechanics to syntax, common failures, and how SPF fits into a broader authentication stack.

How does an SPF record actually work in DNS?

An SPF record works by publishing a DNS TXT record on your domain that lists every server or service permitted to send email from that domain. When a receiving mail server gets a message claiming to be from your domain, it performs a DNS lookup on your domain, finds the SPF record, and checks whether the sending IP address matches one of the authorized sources listed in that record.

The lookup happens automatically during the SMTP conversation, specifically at the point where the sending server identifies itself with the envelope “MAIL FROM” address. The receiving server compares the connecting IP against the mechanisms in your SPF record and returns one of several results: Pass, Fail, SoftFail, Neutral, TempError, or PermError. A Pass result means the sending server is authorized. Anything else can trigger filtering, rejection, or flagging depending on the receiving server’s policy and your DMARC configuration.

One important constraint is the DNS lookup limit. SPF allows a maximum of ten DNS-resolving mechanisms per record. Exceeding this limit causes a PermError, which effectively breaks your SPF record entirely, even if every sending source listed is legitimate.

What does the syntax inside an SPF record mean?

An SPF record always begins with v=spf1, which identifies the record as an SPF version 1 entry. Everything that follows is a series of mechanisms and qualifiers that define which servers are authorized and what should happen when a server does not match.

The basic structure looks like this: v=spf1 [mechanisms] [all]. Each mechanism describes a category of authorized senders, and the qualifier in front of each mechanism (or its absence) tells the receiving server what to do with a match. The four qualifiers are:

• + (Pass): The default. This mechanism authorizes the sender. If no qualifier is shown, Pass is assumed.
• – (Fail): The sender is explicitly not authorized. Receiving servers should reject the message.
• ~ (SoftFail): The sender is probably not authorized, but receiving servers should accept and flag rather than reject.
• ? (Neutral): No policy statement is made. The result is treated similarly to having no SPF record at all.

The record ends with an all mechanism, which acts as a catch-all for any sending IP not matched by the earlier mechanisms. The qualifier applied to all determines what happens to unrecognized senders, which is one of the most consequential decisions in SPF configuration.

What are the most common SPF mechanisms and their uses?

The most commonly used SPF mechanisms are ip4, ip6, include, a, and mx. Each one defines a different method for specifying authorized sending sources, and most SPF records use a combination of several of them.

• ip4 and ip6: These directly authorize specific IP addresses or CIDR ranges. They are the most straightforward mechanisms and do not consume additional DNS lookups, making them efficient for known static IPs.
• include: This references another domain’s SPF record and inherits its authorized senders. It is the standard way to authorize third-party sending services like ESPs, CRMs, or marketing platforms. Each include counts as one DNS lookup.
• a: Authorizes the IP addresses associated with the domain’s own A record. Useful when your web server also sends email.
• mx: Authorizes the IP addresses listed in the domain’s MX records. Commonly used when the same servers receive and send mail.
• redirect: A modifier rather than a mechanism, it replaces the entire SPF policy with another domain’s SPF record. Unlike include, it cannot be combined with an all mechanism.

For most organizations, the SPF record consists of several include statements for third-party senders and one or two ip4 entries for internal infrastructure, all ending with an all qualifier.

What’s the difference between ~all and -all in SPF?

The difference between ~all (SoftFail) and -all (Fail) is how aggressively the receiving server treats email from senders not listed in your SPF record. With ~all, unlisted senders are accepted but flagged. With -all, unlisted senders should be rejected outright.

In practice, most receiving servers do not automatically reject messages based on a -all result alone. The actual enforcement depends heavily on the receiving server’s own filtering policies and, more importantly, on whether DMARC is configured. DMARC is the layer that actually enforces rejection or quarantine actions based on SPF and DKIM results.

That said, the choice between the two still matters for signaling intent:

• ~all is safer during initial setup or when you are still discovering all your sending sources. It reduces the risk of accidentally blocking legitimate mail from a service you forgot to include.
• -all sends a stronger signal that your domain has a strict policy and that any unlisted sender should not be trusted. This is the recommended setting once you are confident your SPF record is complete and accurate.

If you are moving toward a DMARC policy of p=reject, aligning your SPF to use -all is a natural and consistent choice.

Why does an SPF record fail even when it looks correct?

An SPF record can fail for several reasons that are not immediately obvious from reading the record itself. The most common causes are exceeding the ten DNS lookup limit, sending through a service or IP that is not listed, or a forwarding scenario where the originating IP changes between hops.

Here are the most frequent root causes of SPF failures:

• Too many DNS lookups: Each include, a, and mx mechanism triggers a DNS lookup. Once you exceed ten, the record returns a PermError and SPF effectively fails for every message, regardless of the sending source.
• Missing sending sources: A new ESP, CRM, or transactional email provider was added but its include statement was never added to the SPF record.
• Email forwarding: When a message is forwarded, the forwarding server’s IP replaces the original sender’s IP. That forwarding server is almost never listed in your SPF record, causing a Fail result even for legitimate messages.
• Multiple SPF records: Publishing more than one TXT record with v=spf1 on the same domain causes a PermError. All mechanisms must be consolidated into a single record.
• Subdomain misalignment: SPF does not automatically apply to subdomains. If you send from a subdomain, it needs its own SPF record.

Diagnosing SPF failures accurately requires checking the email headers of a failed message, specifically the Authentication-Results header, which will indicate the result and often the reason.

How does SPF work alongside DKIM and DMARC?

SPF, DKIM, and DMARC are three separate but complementary email authentication protocols that work together as a complete defense against spoofing and phishing. SPF verifies the sending IP address, DKIM verifies the message content through a cryptographic signature, and DMARC ties both together and defines what happens when either check fails.

SPF alone has a significant limitation: it authenticates the envelope sender (the “MAIL FROM” address used in the SMTP handshake), not the “From” address that recipients actually see in their inbox. This means a spoofed display address can still pass SPF. DMARC closes this gap by requiring that the domain in the visible “From” header aligns with the domain that passed either SPF or DKIM authentication.

In a properly configured authentication stack:

1. SPF confirms the sending server is authorized for the envelope domain.
2. DKIM confirms the message has not been altered in transit and links it to your signing domain.
3. DMARC checks whether either SPF or DKIM aligns with the visible “From” domain, then applies the policy you have set (none, quarantine, or reject).

Because email forwarding breaks SPF alignment, DKIM alignment is often the more reliable signal for DMARC to pass on. This is why having both SPF and DKIM configured is strongly recommended rather than relying on either one alone. A message that fails SPF but passes DKIM can still achieve a DMARC pass, providing resilience against forwarding scenarios.

How Email Industries helps with SPF configuration

Getting SPF configuration right is rarely a one-time task. Sending sources change, third-party platforms multiply, and DNS lookup limits creep up quietly until deliverability starts to suffer. We help organizations build and maintain an SPF setup that is accurate, efficient, and properly aligned with their full authentication stack. Our work in this area includes:

• Auditing existing SPF records to identify lookup overflows, missing senders, and conflicting records
• Mapping all active sending sources across ESPs, CRMs, transactional platforms, and internal infrastructure
• Consolidating and restructuring SPF records to stay within DNS lookup limits without losing coverage
• Aligning SPF with DKIM and DMARC to build a complete, enforceable authentication framework
• Providing ongoing monitoring so that newly added sending services do not silently break authentication

If your SPF record is failing, incomplete, or you are simply not sure whether your authentication setup is protecting your domain the way it should, we are here to help. Reach out and contact our team to get a clear picture of where things stand and what needs to change.

Related Articles

• What is a good domain reputation score?
• Is SPF required for email?
• How many SPF records should I have?
• How do you troubleshoot a failed BIMI implementation?
• How does BIMI implementation improve email security?
• What are the biggest DMARC policy mistakes email senders make?
• What does a DKIM failure mean for your email program?
• What is the difference between DKIM, SPF, and DMARC?
• How does SPF work with third-party email sending services?
• Is DMARC mandatory now?
• How do email advertising agencies adapt to algorithm changes?
• How does migrating email platforms affect your ESP reputation history?
• Should you warm up a new domain before sending bulk email?
• How long does it take to improve email deliverability?
• What services do email deliverability agencies provide?