ApiVectPRACTICAL ADVICE
SPF softfail: review your senders before changing policy
By ApiVect ·
Build a sender inventory, understand ~all and -all, and use ApiVect's configuration findings to plan a careful SPF review.
A new week is a useful time to review the services sending email for your business. If a domain audit flags an SPF softfail policy, start with that inventory before editing DNS. A warning can identify a review task without proving that a real message failed authentication.
Understand the policy you are reviewing
SPF checks whether a sending host is authorised for the SMTP MAIL FROM or HELO identity. Under RFC 7208, a matching ~all produces softfail; -all produces fail. Softfail expresses a weaker statement about an unauthorised sender. Receivers should not reject a message solely because of that result; their wider filtering policy still matters.
Changing the final qualifier does not add a missing legitimate sender. Choose a policy with your mail administrator and follow the current guidance for each provider you use. Google's own Workspace setup guidance recommends ~all, so a stricter qualifier is not a universal checklist requirement.
Make a small sender inventory
List each workflow that sends mail: staff mailboxes, website forms, billing notifications, support software and any other authorised service. For each one, record its owner, the domain used for the SMTP envelope sender and the provider's current SPF instructions. The visible From address alone does not tell you which domain SPF checks.
A synthetic review example
Your team confirms the staff mailbox provider, but a website form uses a separate sending service. Before changing policy, ask the website administrator which envelope domain that service uses and whether your domain needs an additional authorisation. Confirm this from provider documentation and your own receiver-side authentication results. This is an illustrative workflow, not a customer case or a live email test.
Review the record and plan verification
Check the existing TXT record for conflicting SPF records and obsolete authorisations. SPF permits only one applicable SPF record per name. Its evaluation also limits DNS-querying terms to ten, including nested includes; counting only the visible include: entries can miss that limit. Keep a copy of the previous record and agree who will verify the change after DNS caches refresh.
Use your own mail system's trusted authentication results to assess real messages from each legitimate workflow. Investigate missing senders or lookup errors before considering a policy change. Keep message contents and credentials out of public reports.
Use ApiVect findings in the right context
ApiVect's Domain and Email Security API reviews public SPF configuration with bounded include traversal. It does not evaluate a sender IP, HELO or MAIL FROM for an individual message. The website tool also presents configuration findings with summaries and practical recommendations. Use those findings to organise the review, then verify actual message authentication separately.
Start your configuration review
Read each finding and its coverage before deciding what to change. ApiVect provides the tools behind this guide.
Sources and further reading
Sources and product coverage checked on 5 October 2026. This is practical guidance from ApiVect, not a new standards announcement.