NAME
    Mail::SpamAssassin::Plugin::SPF - perform SPF verification tests

SYNOPSIS
      loadplugin     Mail::SpamAssassin::Plugin::SPF

DESCRIPTION
    This plugin checks a message against Sender Policy Framework (SPF)
    records published by the domain owners in DNS to fight email address
    forgery and make it easier to identify spams.

USER SETTINGS
    whitelist_from_spf user@example.com
        Works similarly to whitelist_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 whitelist, and the
        second is a string to match the relay's rDNS.

        Just like whitelist_from, multiple addresses per line, separated by
        spaces, are OK. Multiple "whitelist_from_spf" lines are also OK.

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

        Since this whitelist 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 "trusted_networks" for more
        info on trust paths.

        e.g.

          whitelist_from_spf joe@example.com fred@example.com
          whitelist_from_spf *@example.com

    def_whitelist_from_spf user@example.com
        Same as "whitelist_from_spf", but used for the default whitelist
        entries in the SpamAssassin distribution. The whitelist score is
        lower, because these are often targets for spammer spoofing.

ADMINISTRATOR OPTIONS
    spf_timeout n (default: 5)
        How many seconds to wait for an SPF query to complete, before
        scanning continues without the SPF result.

    do_not_use_mail_spf (0|1) (default: 0)
        By default the plugin will try to use the Mail::SPF module for SPF
        checks if it can be loaded. If Mail::SPF cannot be used the plugin
        will fall back to using the legacy Mail::SPF::Query module if it can
        be loaded.

        Use this option to stop the plugin from using Mail::SPF and cause it
        to try to use Mail::SPF::Query instead.

    do_not_use_mail_spf_query (0|1) (default: 0)
        As above, but instead stop the plugin from trying to use
        Mail::SPF::Query and cause it to only try to use Mail::SPF.

    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.