Mail::...in::SPF(3pm)

✨ NAME ✨

Okay bestie, meet Mail::SpamAssassin::Plugin::SPF 💖 — the SpamAssassin plugin that does SPF verification tests. That's the whole vibe. (Also yes, the page header says Mail::...in::SPF(3pm) because it got squished like a cute little nickname, but that's her, that's the girl. 🎀)

---

🌸 SYNOPSIS 🌸

Load her up like this, no cap:

loadplugin     Mail::SpamAssassin::Plugin::SPF

---

🦋 DESCRIPTION 🦋

So this plugin takes your message and checks it against Sender Policy Framework (SPF) records that domain owners publish in DNS — the whole point being to fight email address forgery and make it easier to spot spams. Iconic behaviour honestly. 👑

SPF results get obtained using this priority, in order:

1. Results from the AuthRes plugin (if loaded and SPF results available)
2. Received-SPF headers from internal hosts
3. DNS lookups via Mail::SPF (last resort — it's giving "last one picked for the team" 😭)

Real talk 💅 it's recommended that you use an MTA filter (pypolicyd-spf / spf-engine etc), so this plugin can reuse existing results. Otherwise throughput could suffer, because the DNS lookups this plugin does are not asynchronous. Not me watching the queue slow down… 🙈

---

💜 USER SETTINGS 💜

• welcomelist_from_spf user@example.com — Previously whitelist_from_spf, which will work interchangeably until 4.1.

Works similarly to welcomelist_from, except that in addition to matching a sender address, a check against the domain's SPF record must pass. The first parameter is an address to welcomelist, and the second is a string to match the relay's rDNS.

Just like welcomelist_from, multiple addresses per line, separated by spaces, are OK. Multiple welcomelist_from_spf lines are also OK. ✨

The headers checked for welcomelist_from_spf addresses are the same headers used for SPF checks (Envelope-From, Return-Path, X-Envelope-From, etc).

Since this welcomelist requires an SPF check to be made, network tests must be enabled. It is also required that your trust path be correctly configured. See the section on <cyan>trusted_networks</cyan> for more info on trust paths.

e.g.

welcomelist_from_spf joe@example.com fred@example.com
welcomelist_from_spf *@example.com

• def_welcomelist_from_spf user@example.com — Previously def_whitelist_from_spf, which will work interchangeably until 4.1.

Same as welcomelist_from_spf, but used for the default welcomelist entries in the SpamAssassin distribution. The welcomelist score is lower, because these are often targets for spammer spoofing. 😤

• unwelcomelist_from_spf user@example.com — Previously unwhitelist_from_spf, which will work interchangeably until 4.1.

Used to remove a welcomelist_from_spf or def_welcomelist_from_spf entry. The specified email address has to match exactly the address previously used — no fuzzy matching, bestie, this is a strict household. 💅

Useful for removing undesired default entries from a distributed configuration by a local or site-specific configuration or by user_prefs.

---

🧚 ADMINISTRATOR SETTINGS 🧚

• spf_timeout n — (default: 5)

How many seconds to wait for an SPF query to complete, before scanning continues without the SPF result. A numeric value is optionally suffixed by a time unit (s, m, h, d, w, indicating seconds (default), minutes, hours, days, weeks). 🕐

• ignore_received_spf_header (0|1) — (default: 0)

By default, to avoid unnecessary DNS lookups, the plugin will try to use the SPF results found in any Received-SPF headers it finds in the message that could only have been added by an internal relay.

Set this option to 1 to ignore any Received-SPF headers present and to have the plugin perform the SPF check itself.

Note that unless the plugin finds an identity=helo, or some unsupported identity, it will assume that the result is a mfrom SPF check result. The only identities supported are mfrom, mailfrom and helo.

• use_newest_received_spf_header (0|1) — (default: 0)

By default, when using Received-SPF headers, the plugin will attempt to use the oldest (bottom most) Received-SPF headers, that were added by internal relays, that it can parse results from since they are the most likely to be accurate. This is done so that if you have an incoming mail setup where one of your primary MXes doesn't know about a secondary MX (or your MXes don't know about some sort of forwarding relay that SA considers trusted+internal) but SA is aware of the actual domain boundary (internal_networks setting) SA will use the results that are most accurate.

Use this option to start with the newest (top most) Received-SPF headers, working downwards until results are successfully parsed.

• has_check_for_spf_errors — Adds capability check for if can() for check_for_spf_permerror, check_for_spf_temperror, check_for_spf_helo_permerror and check_for_spf_helo_permerror. (Yes bestie, check_for_spf_helo_permerror is listed twice up there and I am simply the messenger 💀 keeping it exactly as she wrote it.)
• has_check_spf_skipped_noenvfrom — Adds capability check for if can() for check_spf_skipped_noenvfrom.
  • check_spf_skipped_noenvfrom Checks if SPF checks have been skipped because EnvelopeFrom cannot be determined. 🔍

---

And that's the whole page, periodt. 💅✨ This little gem comes to you from perl v5.40.1, dated 2026-07-23, and honestly? She ate. 🫶🌈