SPF (Sender Policy Framework) record analysis and sender policy evaluation

1. SPF Analysis overview

This row in your DNSprobe report groups everything related to your SPF policy: the raw record, a parsed view of mechanisms, include domains, resolved IPs and a final score.

Why this matters

SPF is one of the core building blocks of e-mail authentication. If it is missing or badly configured, other protections like DMARC or alignment checks will be far less effective.

How to read this block

Start at the top by confirming that the Host, Value and TTL match what you expect at your DNS provider. Then look at the parsed tables of mechanisms and include domains, and finally at the all policy and score which summarise how strict your policy is.

Best practices at a glance

• Always publish exactly one SPF record for a given host, starting with v=spf1.
• Keep the policy as simple and readable as possible so that future changes are safe.
• Use the SPF Evaluation Score as a quick indication, but always double-check with your mail provider before tightening the policy.

2. SPF record: Host, Value and TTL

The header of the SPF Analysis block shows the host where the record lives (usually the bare domain), the raw TXT value and its TTL in seconds.

Why this matters

SPF is discovered via DNS. If the record is published on the wrong host, has a typo in the v=spf1 prefix or is cached for too long, receivers may interpret your policy incorrectly.

How DNSprobe checks it

DNSprobe queries your authoritative nameservers for TXT records at the domain apex and looks for the one starting with v=spf1. It then displays the exact text and TTL returned by DNS.

Typical problems detected here

• No SPF record at all, or more than one v=spf1 string published on the same host.
• SPF text published on the wrong hostname (for example only on mail.example.com instead of example.com).
• Malformed SPF version line or missing v=spf1 prefix.

Best practices for the SPF record itself

• Publish exactly one SPF record at the domain apex for normal mail traffic.
• Keep TTL reasonably short while you are tuning the policy, then increase it once stable.
• Avoid packing unrelated TXT values into the same record; keep SPF separate from other TXT uses.

3. SPF mechanisms and targets

The Parsed SPF part of the block breaks down mechanisms like a, mx, ip4, ip6, exists or redirect and shows which target each one refers to and how it resolves.

Why mechanisms matter

Each mechanism is a rule that can pass or fail a given sending IP. Understanding which mechanisms you use tells you which systems are currently authorised to send mail.

How DNSprobe interprets mechanisms

DNSprobe reads the SPF string from left to right, extracts mechanisms and qualifiers (+, -, ~, ?), and for host-based mechanisms it resolves the corresponding IPs. These are displayed in the Mechanism / Target / Resolution table.

Common issues with mechanisms

• Using broad mechanisms like a or mx without being sure all associated hosts are meant to send e-mail.
• Relying on deprecated or risky mechanisms such as ptr, or complicated redirect chains.
• Accidentally including test or legacy infrastructure that should no longer be allowed to send.

Best practices for mechanisms

• Prefer explicit ip4/ip6 ranges or limited a/mx mechanisms scoped to the correct hosts.
• Avoid ptr and overly complex redirect logic whenever possible.
• Review the list of resolved IPs regularly to ensure only current sending systems are covered.

4. Include hosts and resolved IPs

Many providers ask you to use include:mechanisms so that their own SPF records are pulled into yours. DNSprobe shows these include hosts and the IP ranges they resolve to.

Why includes deserve attention

Includes are convenient, but each one adds DNS lookups and brings in external IP ranges you do not directly control. You should know which providers you trust to send on behalf of your domain.

How DNSprobe expands includes

For each include:host, DNSprobe retrieves that domain’s SPF policy, collects the resulting IP ranges and shows them in the Include Hosts / Resolved IPs table. It also adds their lookups to the global SPF lookup count.

Typical problems related to includes

• Too many nested includes causing the 10 DNS lookup limit of SPF to be reached or exceeded.
• Old providers still referenced via include: even though they no longer send any mail for you.
• Includes that bring in extremely broad IP ranges, unintentionally authorising large third-party networks.

Best practices for includes

• Only include providers that actively send mail for your domain.
• Periodically audit the resolved IPs to confirm they still make sense for your use cases.
• Keep an eye on the total DNS lookup count and simplify the policy before you hit SPF’s hard 10-lookup limit.

5. SPF all policy and evaluation score

At the bottom of the Parsed SPF section, DNSprobe summarises the all mechanism (for example -all, ~all, ?all, +all) and explains how strictly it treats unauthorized senders, along with an SPF Evaluation Score.

Why the all mechanism is so important

The all mechanism is the default rule applied when no previous mechanism matches. It determines whether unknown senders are explicitly rejected, treated as suspicious or effectively accepted.

How DNSprobe evaluates your all policy

DNSprobe reads the final all mechanism, labels it as Fail (-all), SoftFail (~all), Neutral (?all) or Pass (+all), and combines this with other factors such as lookup count and syntax quality to compute a score out of 5. A short explanation under the all policy tells you what that means in practice.

Typical issues highlighted here

• Using +all, which effectively authorises any IP to send mail for your domain and is considered very bad practice.
• No all mechanism at the end of the policy, leaving receivers to guess how to handle unknown senders.
• Exceeding the 10 DNS lookup limit, causing some receivers to treat the SPF evaluation as a permanent error.

Best practices for the all policy and score

• Aim for -all once you are confident that all legitimate sending systems are covered.
• Use ~all as a transitional step while you monitor DMARC and logs before moving to a stricter policy.
• Keep the score and explanation as a guide, but validate changes with real-world tests and monitoring.

6. Test SPF records manually from your own terminal

DNSprobe parses your SPF record, resolves include mechanisms and highlights potential issues such as overly broad ranges or duplicate IP addresses. You can inspect the raw SPF record yourself from a terminal by querying TXT records and filtering for the SPF policy.

Linux: using dig (BIND utilities)

On most Linux distributions, the dig command is provided by the BIND utilities package. The following commands query all TXT records at the root of your domain, then focus specifically on the SPF record that begins with v=spf1:

                dig example.com TXT
                dig example.com TXT +short
    
                # Optional: filter the TXT records to show only the SPF policy (the line starting with v=spf1)    
                dig example.com TXT | grep "v=spf1"
        

macOS: using dig from the built-in tools

macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to list TXT records and isolate the SPF policy for your domain:

                dig example.com TXT
                dig example.com TXT +short
    
                # Optional: filter the TXT records to show only the SPF policy (the line starting with v=spf1)    
                dig example.com TXT | grep "v=spf1"
        

Windows: using nslookup

On Windows, the legacy nslookup tool can query TXT records for your domain. Run the following commands from a Command Prompt or PowerShell window, then look for the TXT line that starts with v=spf1, which is your SPF policy:

                nslookup -type=TXT example.com
    
                REM Optional: query TXT records for a specific mail host (for example mail.example.com) instead of just the root domain    
                nslookup -type=TXT mail.example.com
        

Important: only query DNS records for domains that you own or are authorised to analyse. Repeated automated lookups against third-party domains may be treated as abusive traffic by some providers.