Configuring the Domino SMTP server to reduce spam

Domino servers that receive SMTP messages directly from the internet can be configured to use the SPF protocol to evaluate whether the sending server is an authorized one.

Note: This feature is supported on Windows and Linux.

Sender Policy Framework, or SPF, is a standardized protocol intended to reduce email spoofing. It allows an SMTP server receiving a message from another SMTP server to authenticate, via IP address, the sending server as an authorized sender of messages from the domain of the apparent sender of the message. The sending domain publishes an SPF policy in their DNS by means of a TXT record. The receiving server retrieves the sending domain's SPF policy through a DNS lookup, and determines whether the sending server's IP address is designated as an authorized sender of mail from the domain. If the sending server is not an authorized sender, the policy specifies how to classify the result of the SPF evaluation.

Table 1. Possible SPF evaluation results
Result Reason Untrusted?
None No syntactically valid SPF policy was found in DNS that could be used to validate the sending server, or no SPF record is published by the domain of the apparent message sender, thus no evaluation is possible. No
Neutral The sending domain's SPF policy explicitly states that it is not asserting whether the IP address is authorized. No
Pass The IP of the sending SMTP server was validated according to the SPF policy published in DNS by the apparent sender's domain. No
Fail The IP of the sending SMTP server was not validated according to the SPF policy published in DNS by the apparent sender's domain, and the SPF policy explicitly states to treat the sender as not authorized to send mail for the apparent sender's domain. Yes
Softfail A "softfail" result is a weak statement by the apparent sender's domain, according to the SPF policy, that the host is probably not authorized. It did not publish a stronger, more definitive policy that results in a "fail." No
Temperror Domino encountered a transient error while performing the check, generally DNS. A later retry might succeed without further action by the apparent sender's domain. No
Permerror The apparent sender's domain's published records could not be correctly interpreted. This signals an error condition that requires the apparent senders domain's intervention to resolve. Yes
Note: SPF checking can result in multiple DNS lookups, and thus can potentially impact SMTP server performance. An internal cache is utilized by Domino to reduce this impact.

DomainKeys Identified Mail, or DKIM, is a standardized protocol intended to reduce email spoofing. A sending domain may affix one or more DKIM-Signature headers, which are linked to a domain name, to a message. A receiving server may then use these signatures, and public keys published in DNS by the sending domain, to verify that the message was authorized by the domain, and that the contents of the message have not been modified in transit. Domino records the result of each signature validation in an Authentication-Results header that it affixes to the message. Both the signatures and the authentication results are not generally visible to end users.

Table 2. Possible DKIM evaluation results (only one result per signature is recorded)
Result Reason Untrusted?
None No DKIM signatures were found on the message No
Neutral The message was signed, but the signature or signatures contained syntax errors or were not otherwise able to be processed. This result is also used for other failures not covered elsewhere in this list. No
Pass The message was signed, the signature was acceptable, and the signature passed verification. No
Fail The message was signed and the signature or signatures were acceptable, but they failed verification. Yes
Temperror The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key from DNS. A later attempt may produce a final result. No
Permerror The message could not be verified due to some error that is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result. No
Note:

DKIM signature verification can result in multiple DNS lookups, thus can potentially impact SMTP server performance. An internal cache is utilized by Domino to reduce this impact.

A domain may choose to sign a message with multiple signatures. For example, the domain may choose to use multiple signing algorithms. If any of those signatures passes, the message is considered trusted.

DKIM signature verification requires accurate system time. Ensure that Domino servers which perform DKIM signature verification are synchronizing with an NTP server.

About this task

Domino servers which receive SMTP messages directly from the internet may be configured to use SPF and DKIM signature verification. Because the IP address of the sending server is used as the input to the SPF evaluation, SPF evaluation should generally not be enabled on servers which are not externally facing. A Domino server which does SPF evaluations will add a Received-SPF header to a received message with the results of its evaluation, and also add the results to an Authentication-Results header. A Domino server which does DKIM signature verification will add the results of each signature's verification to an Authentication-Results header.

Procedure

  1. From the Domino® Administrator, click the Configuration tab and expand the Messaging section.
  2. Click Configurations.
  3. Select the Configuration Settings document for the SMTP server or servers you want to administer, and click Edit Configuration.
  4. Click Router/SMTP > Restrictions and Controls > SMTP Inbound Controls.
  5. Locate the Inbound Sender Domain Authentication Controls section.
  6. If DKIM signature verification is desired, in the DKIM signature verification field, change the setting to Enabled.
  7. In the Sender Policy Framework check (SPF) field, change the setting to Enabled.
  8. In the Desired action when the sending IP hard fails the SPF check for the sender domain field, select the action you wish to take for messages determined to be untrusted as a result of SPF evaluation:
    • Log and tag message - Outputs a message in the server console, noting the domain and IP address used to determine the failure. For example, "SMTP Server: Message will be tagged but allowed. SPF policy for domain example.com does not designate host 10.100.127.35 as a permitted sender." Records the SPF evaluation result status in both the Received-SPF header and the Authentication-Results header.
    • Log and reject message - Outputs a message in the server console, noting the domain and IP address used to determine the failure. For example, "SMTP Server: Mail rejected for policy reasons. SPF policy for domain example.com does not designate host 10.100.127.35 as a permitted sender." Rejects the message in protocol by returning the following message to the sending SMTP server: "554 Mail rejected for policy reasons. SPF policy for domain example.com does not designate host 10.100.127.35 as a permitted sender."
  9. If you have internal or trusted external servers from which you receive messages over the SMTP protocol and which you don't want to do SPF checks on, enter the servers in the Do not perform an SPF check for the following internet hostnames/IP addresses field.
  10. Administrators may choose to have messages that were tagged as untrusted delivered to the recipient's Junk folder. See Delivering untrusted mail to the Junk folder to configure the controls for delivering to the Junk folder.