SPF findings help identify records that deserve a mail-configuration review. Treat the module’s lookup count as an inspection result rather than a complete simulation of every receiver evaluating a particular message.

Inspect the finding

1. Open PD Modules → Deliverability → Needs attention.
2. Review the SPF finding’s severity and What it means.
3. Choose How to fix and confirm the affected domain.
4. Compare the currently published record with the intended sending services before making a DNS change.

The module can flag a missing record, multiple records, a high lookup count, permissive or neutral endings, missing all mechanism and ptr usage. It follows readable nested includes and redirects for its estimate, but does not have the message sender context needed to expand every macro or reproduce conditional evaluation.

Know the inspection limits

Repeated targets, loops, unreadable nested records and conditional branches can affect the estimate. A redirect can be valid without an all mechanism; a no-all finding is not by itself proof that SPF is invalid. The standard’s lookup limit applies during evaluation, not to an arbitrary count of every DNS packet. See the SPF specification.

Review a correction safely

Inventory the actual senders and consult their current authorised record requirements. Do not add a second SPF policy beside an existing one or flatten includes merely to clear the module’s warning. A suggested no-mail record is appropriate only after confirming the domain truly sends no mail; an absent MX is not proof of that.

Recheck after an authorised correction and inspect the resulting evidence. A closed finding or high grade does not prove that a particular message passed SPF or reached an inbox.

See the PD Email Deliverability Blesta guide for related tasks, or explore PD Email Deliverability.