Sun Java System Messaging Server 6.3 Administration Guide

Chapter 15 Handling Forged Email Using the Sender Policy Framework

Spam producers and email scammers often forge email by using false domain names and email addresses or by using legitimate domain names and email addresses in order to fool users into thinking that a message is from someone or some company they know. For example, a spammer could send email from an address such as and the user could be fooled into thinking the mail was actually from this address. Forging email may fool users into opening the unsolicited message, or worse, provide information to a false authority. Also, spammers prefer to send their email from legitimate domains that are not on an RBL list.

Sender Policy Framework (SPF) is a technology that can detect and reject forged email during the SMTP dialogue. Specifically, SPF is a protocol that allows a domain to explicitly authorize the hosts that may use its domain name. In addition, a receiving host may be configured to check this authorization. SPF can thus significantly reduce the instances of forged email.

15.1 Theory of Operations

When a message comes into Messaging Server, the MTA does an SPF query to determine if the address actually came from the domain on the address. An SPF query consults the DNS for TXT records belonging to the domain of the message (domain). Domain is either the domain name specified as the argument for HELO or EHLO (if the spfhelo channel keyword is used) or the domain name in the originator's address given in the MAIL FROM: command (typically the part after the @ character). If no domain name is specified or available, the one specified during HELO/EHLO is used as domain. Note that most ISPs distribute an authorized list of IP addresses that match their domains. If the IP address does not match the domain name, then the message is assumed to be forged.

Note –

Prior to querying the DNS, we check the SPF_LOCAL mapping table for a match for domain. If a match is found there, it will be used first.

If a record found from the mapping table contains a redirect=domain clause, then the redirection to domain will be done as a DNS query, skipping the recursive and redundant mapping file check.

An example of a resulting TXT record is:

v=spf1 +mx -all

The v=spf1 token is required for SPF records supported by this RFC.

+mx directs us to check MX records for domain and confirm that the source IP address for this SMTP connection matches one of the IP addresses given as a result of an MX query for domain. If there is a match, the + means that the result of this is Pass. directs us to check for A records for, and then confirm that the source IP address for this SMTP connection is in the same specified CIDR subnet as the A records, comparing only 28 bits (masked against No qualifier character was specified, so it defaults to + meaning that a match results in a Pass.

Finally, -all matches everything else and results in Fail. For a more complete description of SPF records, please refer to RFC 4408 at

SPF processing can have one of several results. The table below shows the results and their descriptions.

Table 15–1 SPF Processing Results




The lookup has passed meaning that an SPF record was found and the record validated the originating system as being authorized to use domain.


The lookup found a matching SPF record, however, the record explicitly denied authorization for the SMTP client to use domain during the SMTP transaction. The default behavior of our SPF implementation is to reject the SMTP command with a 5xx reply.


The lookup found a matching SPF record, and the record also denies authorization for the SMTP client to use domain, however the denial is less strict and the record does not direct an outright failure. The default behavior of our implementation is to accept the message, but note the SoftFail in the Received-SPF: header for subsequent evaluation such as during Sieve processing.


The SPF record makes no claim to the SMTP client's authorization to use domain. The message will be accepted. The specification requires that Neutral be treated the same as None below.


No matching SPF record was found, therefore no SPF processing was done. 


A permanent error was encountered during SPF processing, such as syntax errors in the SPF record, DNS failures while processing nested SPF records (due to include: mechanism or a redirect= modifier), or exceeding configured limits for SPF processing while processing nested SPF records. The default behavior is to reject the SMTP command with a 5xx reply.


A temporary error was encountered during SPF processing, most likely due to DNS timeouts querying SPF records. The default behavior is to reject the SMTP command with a 4xx reply. 

After SPF processing has completed, a Received-SPF: header will be written to the message documenting the result of the SPF processing. This header can then be queried during Sieve processing for subsequent consideration. Extensive debugging is available if the MTA option MM_DEBUG is enabled (>0) in the option.dat file.

15.2 Limitations

SPF is only one tool to use to fight spam, and will not address all issues. It is fairly easy for a spammer to create a domain and add an SPF TXT record that will make the domain seem legitimate. On the other hand, SPF is pretty effective for detecting forged email from established ISPs, although many TXT records will allow the SPF to not fail.

15.3 Pre-Deployment Considerations

It is important to have a very fast DNS server on your system because a DNS query for every message will be required.

15.4 Setting up the Technology

There are two steps for setting up SPF technology:

15.5 Reference Information

This section provides reference information for the SPF channel keywords and the SPF MTA options. SPF support is implemented through four channel keywords applied to the incoming tcp_* channel (typically tcp_local). The following table shows the keywords and their descriptions.

Table 15–2 SPF Keywords




Disables SPF processing 


Enables SPF processing for the domain name specified as an argument to HELO or EHLO. 


Enables SPF processing for the domain name provided for the originator envelope address after receiving the MAIL FROM:. 


Enables SPF process for the domain name provided for the originator envelope address after receiving the RCPT TO:. Processing is the same as spfmailfrom except that it is delayed in the SMTP transaction until after the RCPT TO: command has been issued and the recipient has otherwise been confirmed to be a valid recipient.

Note –

spfmailfrom and spfrcptto are conflicting keywords and you should only specify one of these two keywords on the channel. You can, however, use spfhelo in conjunction with either spfmailfrom or spfrcptto to perform both kinds of SPF checks.

There is additional support to establish limits on SPF processing and to control whether SMTP commands will be accepted, failed with a 4xx response (temporary failure), or failed with a 5xx response (permanent failure) for the various SPF results including: Fail, SoftFail, PermError, and TempError.

The following MTA options, in option.dat, can be used to place limits on SPF processing.

Table 15–3 SPF Limiting Options




Specifies the number of recursions that will be allowed into nested SPF records due to include: or redirect=. Exceeding this limit will result in a PermError.

Default: 10 (mandated by the RFC) 


Specifies the number of mechanisms or modifiers that require DNS lookups (including include:, a:, mx:, ptr:, exists:, redirect=, and exp=). Note that the limit is not counted as the number of actual DNS lookups, so one mechanism could lead to several DNS queries. Exceeding this limit will result in a PermError.

Default: 10 (mandated by the RFC) 


Specifies the number of seconds that will be allowed for the SPF processing to complete. Exceeding this value will result in a TempError. The default value is more generous than the RFC suggests.

Default: 45 

Additionally, the following MTA options in option.dat can be configured to control the behavior of the SMTP server in response to SPF results of Fail, SoftFail, PermError, and TempError. For each of these results, the SMTP server can send back a 2xx (success) response, 4xx (temporary failure), or 5xx (permanent failure). Also, for Fail and SoftFail, the MTA can distinguish between an SPF result as the result of an "all" mechanism versus an otherwise explicitly referenced match. You can then make a distinction between a particular result and the SPF record's default result. The valid values for any of these options is 2, 4, or 5. The values of 2, 4, or 5 correspond to 2xx, 4xx, or 5xx responses from the SMTP server as a result of getting that particular SPF status. So, for example, if SPF_SMTP_STATUS_FAIL=2 and the SPF record explicitly blocks us with a "-a:" (our IP address), then instead of responding with a 5xx response, we'll accept the address with a "250 OK" instead.

Table 15–4 SPF Failure and Error Options




Used when the match of an SPF record is a "-" flagged mechanism other than "-all" 

Default: 5  


Used when the matching mechanism is "-all" 

Default: 5  


Used when the match of an SPF record is a "~" flagged mechanism other than "~all" 

Default: 2  


Used when the matching mechanism is "~all" 

Default: 2  


Used when there is a temporary failure, usually related to DNS processing problems. 

Default: 4  


Used when there is a permanent failure, usually due to syntax or other technical errors found during SPF processing. (Note that this will be due to a non-local error.) 

Default: 5  

15.6 Testing SPF using spfquery

This testing utility can be used to test SPF processing.

Note –

spfquery does not test your SPF configuration. It tests what would be returned if you were to enable SPF processing.

Requirements: Must be run as a user who has access to run the Messaging Server binaries and access its libraries such as root or mailsrv, for example.

Location: msg-svr-base/sbin/

15.6.1 Syntax

spfquery [-i ip-address] [-s sender-email] [-h helo-domain]
  [-e none | neutral | pass | fail | temperror | permerror] [-v] [-V] [?] domain

The following table shows the spfquery options and their descriptions.

Table 15–5 spfquery options



-i ip address

Specifies the IP address to be used as the remote address for the SPF query. Default is This option can also be --ip-address.

-s domain

The email address that will be used as if it were specified as MAIL FROM:. Default: postmaster@domain. This option can also be --sender

-h helo-domain

The domain name as if it were specified for the HELO domain. Note that this domain is not verified itself, but instead provided as supplemental information for macro processing. Default value is the same as the value you specified for domain. This option can also be --helo-domain

-e result

spfquery will compare the result of the SPF processing with what is expected and if the result is different, a message will be printed and spfquery will exit with a non-zero return status; result can be one of: none, neutral, pass, fail, softfail, temperror, or permerror. This option can also be --expect.


Enables verbose output during SPF processing. This option can also be --verbose.


Prints the current version of the SPF library. This option can also be --version.


Prints this usage information. This option can also be --help.

15.6.2 Example with Debugging Enabled

# /opt/SUNWmsgsr/sbin/spfquery -v -i
    Running SPF query with:
      IP address:
          Sender: (local-part: postmaster)
     HELO Domain:

    15:30:04.33: ----------------------------------------------------------------
    15:30:04.33: SPFcheck_host called:
    15:30:04.33:       source ip =
    15:30:04.33:          domain =
    15:30:04.33:          sender =
    15:30:04.33:      local_part = postmaster
    15:30:04.33:     helo_domain =
    15:30:04.33:   Looking up "v=spf1" records for
    15:30:04.35:     DNS query status: Pass
    15:30:04.35:       "v=spf1                  -all"
    15:30:04.35:   Parsing mechanism: " mx :"
    15:30:04.35:     Assuming a Pass prefix
    15:30:04.35:     Processing macros in
    15:30:04.35:     Comparing against
    15:30:04.35:     Looking for MX records for
    15:30:04.41: - No match
    15:30:04.41: - No match
    15:30:04.41: - No match
    15:30:04.41: - No match
    15:30:04.42: - No match
    15:30:04.42: - No match
    15:30:04.42: - No match
    15:30:04.42: - No match
    15:30:04.42: - No match
    15:30:04.42: - No match
    15:30:04.42: - No match
    15:30:04.42: - Matched
    15:30:04.42:   Mechanism matched; returning Pass
    15:30:04.42:   Parsing mechanism: "- all : " (not evaluated)
    15:30:04.42: SPFcheck_host is returning Pass
    15:30:04.42: ----------------------------------------------------------------

15.7 Handling Forwarded Mail in SPF Using the Sender Rewriting Scheme (SRS)

As describe above, SPF is a mechanism that attempts to prevent email forgery by looking up special TXT records associated with the domain in the mail FROM: (envelope from) address. This operation, which can actually involve several DNS lookups, eventually produces a list of IP addresses that are authorized to send mail from the domain. The IP address of the SMTP client is checked against this list and if it isn't found, the message may be considered to be fraudulent. Support for SPF was implemented in version 6.3 of the Messaging Server.

SPF presents serious problems for sites that provide mail forwarding services such as universities (for their alumni) or professional organizations (for their members). A forwarder ends up sending out mail from essentially arbitrary senders, which can include senders who have implemented SPF policies and which, of course, don't list the IP addresses of the forwarding system or systems as being permitted to use addresses from their domain.

The Sender Rewriting Scheme, or SRS, provides a solution to this problem. SRS works by encapsulating the original sender's address inside a new address using the forwarder's own domain. Only the forwarder's own domain is exposed for purposes of SPF checks. When the address is used it routes the mail (usually a notification) to the forwarder, which removes the address encapsulation and sends the message on to the real destination.

Of course address encapsulation isn't exactly new. Source routes were defined in RFC 822 and provide exactly this sort of functionality, as does percent hack routing and bang paths. However, these mechanisms are all problematic on today's Internet since allowing their use effectively turns your system into an open relay.

SRS deals with this problem by adding a keyed hash and a timestamp to the encapsulation format. The address is only valid for some period of time, after which it cannot be used. The hash prevents modification of either the timestamp or the encapsulated address.

SRS also provides a mechanism for handling multi-hop forwarding without undue growth in address length. For this to work certain aspects of SRS address formatting have to be done in the same way across all systems implementing SRS.

SRS support has now been implemented for our 6.3P1 release. The following MTA options have been added:

Setting these options is sufficient to enable SRS address decoding. Encoding is another matter - it should only be done to envelope From: addresses you know are associated with forwarding activity. SRS encoding is controlled by six new channel keywords: addresssrs, noaddresssrs, destinationsrs, nodestinationsrs, sourcesrs, and nosourcesrs.

Three conditions have to be met for SRS encoding to occur:

(1) The current source channel has to be marked with sourcesrs. (nosourcesrs is the default).

(2) The current destination channel has to be marked with destinationsrs (nodestinationsrs is the default).

(3) The current address, when rewritten, has to match a channel marked addresssrs (noaddress is the default).

Encoding only occurs when all of these conditions are true. About the simplest setup is a pure forwarding one where all messages enter and exit on the tcp_local channel and all non-local addresses need SRS handling. In such a setup, tcp_local would be marked with the three keywords sourcesrs, destinationsrs, and addresssrs.

Finally, imsimta test -rewrite has been enhanced to show SRS encoding and decoding results for whatever address is input. For example, the address might produce the output similar to:

SRS encoding =

If this encoded address is rewritten it will produce the output:

SRS decoding =

imsimta test -rewrite will also show any errors that occur during SRS decoding.