SPF Record Syntax: Components, Rules, and Examples

If you’ve ever wondered why some of your legitimate emails end up in spam folders or get blocked altogether, the issue might come down to how your domain’s email authentication is set up. One key factor here is the SPF record syntax, which plays a crucial role in verifying that your emails are sent from authorized servers. While SPF helps prevent your messages from being flagged as suspicious, its syntax can be tricky to understand and even harder to configure correctly. In this post, we’ll break down how SPF record syntax works and what you should keep in mind when setting it up for your domain.

What Is an SPF Record Syntax

An SPF record syntax is the set of rules that define how an SPF (Sender Policy Framework) record is written in a domain’s DNS. In simple terms, it’s the “language” your domain uses to tell receiving mail servers which sources are authorized to send emails on its behalf.

SPF record syntax typically includes mechanisms (such as ip4, ip6, or include), qualifiers (like +, –, ~, or?), and modifiers that work together to determine whether an incoming email passes or fails the SPF check.

Understanding this syntax is crucial because even a minor error, such as an extra space, an incorrect qualifier, or a missing mechanism, can cause your emails to fail authentication and land in spam or be rejected.

Simplify SPF Record Syntax with PowerDMARC!

SPF Record Syntax Components

An SPF record is made up of four main parts: the version tag, mechanisms, qualifiers, and modifiers. Each part plays a unique role, and together they determine how receiving mail servers handle emails claiming to come from your domain. The version tag identifies the record as SPF. Mechanisms define who is allowed to send emails. Qualifiers decide what action to take when there is a match. Modifiers provide optional instructions that extend or refine the policy.

Version tag

The version tag is the starting point of an SPF record. It identifies the record as using SPF syntax and ensures that mail servers interpret the following text correctly. Without it, the record will not work. Only one version tag is allowed, and it must appear at the very beginning of the record.

Key specifics:

• • Must always be at the start of the record.
  • Only one version tag is allowed.
  • Current valid format: v=spf1.
  • Using the wrong version or omitting it makes the record invalid.

SPF qualifiers

Qualifiers are symbols placed in front of mechanisms. They instruct the receiving mail server on what to do if the mechanism matches. Their role is to control the result of the SPF evaluation, whether the email is accepted, rejected, or marked as suspicious. If a qualifier is not specified, the default action is to allow.

Key specifics:

• • Act as prefixes to mechanisms.
  • Control the outcome of the SPF check.
  • Four types:
    • + Pass (allow)
    • – Fail (block)
    • ~ Softfail (accept but mark)
    • ? Neutral (no decision)
      • Default behavior is Pass if no qualifier is used.

SPF mechanisms

Mechanisms are the main rules in an SPF record. They define which servers, IP addresses, or domains are authorized to send mail on behalf of the domain. Each mechanism is checked in order, and if a match is found, the associated qualifier is applied. If no mechanism matches, the record continues until the end is reached.

Key specifics:

• • Define who can send emails for the domain.
    Checked in order from left to right.
  • Work together with qualifiers to determine the result.
  • Eight standard mechanisms:
    • all – matches all senders.
    • ip4 – authorizes IPv4 addresses.
    • ip6 – authorizes IPv6 addresses.
    • a – authorizes based on the domain’s A/AAAA records.
    • mx – authorizes based on the domain’s mail servers.
    • ptr – reverse DNS check (deprecated).
    • exists – checks if a domain resolves.
    • include – references another domain’s SPF record.

SPF modifiers

Modifiers are optional elements that add extra instructions to an SPF record. They do not directly allow or deny mail, but they provide flexibility and more control over how the record is processed. Modifiers are often used in more advanced configurations, but are not always required.

Key specifics:

• Provide optional, extra instructions.
• Do not directly determine pass/fail.
• Common modifiers:
  • redirect – points to another domain’s SPF record.
  • exp – provides a custom explanation for SPF failures.

• Usually appear at the end of the record.

Simplify SPF with PowerDMARC!

SPF Record Syntax Examples

Looking at real SPF records makes it easier to understand how the different components come together. Below are two examples: one simple and one more advanced. Each example follows the correct syntax rules and shows how mechanisms, qualifiers, and modifiers work in practice.

Simple SPF Record

v=spf1 ip4:203.0.113.5 -all

Breakdown:

• v=spf1 → version tag that identifies the record as SPF version 1.
• ip4:203.0.113.5 → mechanism that authorizes the IPv4 address 203.0.113.5 to send mail.
• -all → qualifier and mechanism combined, meaning all other servers not listed should fail the SPF check.

Why it’s valid:

• The record starts with the correct version tag.
• The mechanism (ip4) is written correctly.
• The qualifier (–) is used properly in front of all.
• The syntax is complete and follows SPF rules.

 This is a common setup for a small domain that only sends email from a single server.

Advanced SPF Record

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com

Breakdown:

• v=spf1 → version tag at the start, required by syntax.
• ip4:203.0.113.0/24 → mechanism that authorizes all IP addresses in the range 203.0.113.0 – 203.0.113.255.
• include:_spf.google.com → mechanism that allows Google’s mail servers to send on behalf of the domain.
• include:_spf.mailhost.com → mechanism that allows another third-party provider’s servers.
• ~all → qualifier and mechanism combined, meaning messages from unlisted servers are accepted but marked as suspicious.
• exp=explain._spf.example.com → modifier that provides a custom explanation string when a message fails SPF.

Why it’s valid:

• The record begins with the version tag.
• Multiple mechanisms are included and properly formatted.
• The qualifier ~ is applied to all, which is allowed.
• The modifier exp is used correctly at the end, extending functionality without breaking syntax.

This setup is typical for organizations using multiple email providers while still controlling unauthorized sources.

Rules and Validation for Correct SPF Syntax

Writing an SPF record is all about putting mechanisms and qualifiers in the right order and making sure the record actually works as intended. Even small syntax mistakes, such as a missing tag or an extra space, can cause the record to fail, resulting in emails being rejected, marked as spam, or leaving your domain vulnerable to spoofing.

This section covers three key areas: best practices for writing SPF syntax, common mistakes to avoid, and how to validate your record before publishing it live.

Follow best practices for SPF syntax

Getting SPF right starts with following a few golden rules that make your record both effective and reliable:

• • Always begin with the correct version tag: v=spf1.
  • Limit DNS lookups to avoid exceeding the 10-lookup limit, which will cause the record to break.
  • Use the include mechanism carefully to prevent loops or circular references.
  • Keep records as concise as possible—overly complex configurations are harder to maintain and more likely to fail.
  • Review SPF records regularly, especially if your email infrastructure changes or if you add/remove providers.

Avoid common syntax errors

Many SPF issues come from simple but damaging mistakes. Watch out for these pitfalls:

• Missing version tag: every record must start with v=spf1.
• Duplicate qualifiers: using more than one qualifier for the same mechanism is invalid.
• Excessive mechanisms: long, bloated records increase the risk of errors and exceed DNS limits.
• Syntax formatting issues: misplaced spaces, typos, or unsupported characters can cause the record to fail.
• Multiple SPF records: a domain must only have one SPF record—if more than one exists, validation will fail.
• Deprecated mechanisms: avoid ptr, which is no longer recommended and may not be supported by all servers.

Remember: even if the intent of the record is correct, syntax errors will cause SPF to fail completely.

Validate your SPF record syntax

Before publishing your SPF record, validation is critical. Validators check that the syntax is correct and that the record doesn’t exceed DNS lookup limits or contain unsupported mechanisms.

• Use SPF record check tools, such as PowerDMARC’s SPF checker, to quickly identify issues.
• Validation helps ensure the record works consistently across different receiving mail servers.
• Testing new or updated records in a staging environment is recommended before applying them live.
• Regular validation after changes keeps your SPF policy up to date and functional.

By validating, you reduce the risk of emails bouncing, going to spam, or leaving your domain vulnerable to spoofing.

SPF Record Syntax in Action

Correct SPF record syntax is vital for secure email delivery and protection against spoofing. Each part, including version tag, mechanisms, qualifiers, and modifiers, works together to guide how mail servers handle your messages.

By following best practices, avoiding errors, and regularly validating, you reduce the risk of failures and keep your domain secure. As your email setup evolves, ongoing updates are essential. For easier management and stronger security, consider using PowerDMARC.

Frequently Asked Questions

How to write a SPF record?

Start with ‘v=spf1’, add mechanisms to list authorized senders, and end with a qualifier like ‘-all’ to block everything else.

What happens if my SPF record syntax is wrong?

Mail servers may reject or flag your emails as spam, and your domain becomes more vulnerable to spoofing.

What is an example of a SPF record MX?

An SPF record using MX (MX record) looks like: v=spf1 mx -all, which allows only the domain’s mail servers to send email.

• About
• Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

Latest posts by Ahona Rudra (see all)

• 20 MSP Software Platforms to Run and Scale Your IT Services Business in 2026 - February 3, 2026
• DMARC MSP Case Study: How Systemgemisch Automated Email Authentication Security with PowerDMARC - January 28, 2026
• How Email Threat Intelligence Stops Active Phishing and Spoofing Attacks - January 28, 2026