LISTSERV Maestro allows you to use DomainKeys signatures to authenticate that the messages (sent for a specific email job) do indeed originate from the domain in the “From:” address. Major ISPs already check every incoming mail to see if it is signed with a valid DomainKeys signature. Once DomainKeys has become an accepted standard for message origin verification, the current policy of only informing the recipient about the DomainKeys verification result in an additional header entry may change, and an ISP may opt to not even deliver the message to the recipient or to mark it as coming from an unsure origin. Therefore, in order to achieve good deliverability, signing messages with a valid DomainKeys signature can become more important in the future.
To define application-wide default settings for DomainKeys signatures, open the Administration Hub, click on the
Global Component Settings icon, click
Maestro User Interface, and then click
Default DomainKeys Settings. The DomainKeys Settings screen opens, allowing you to define the default behavior for DomainKeys signatures.
To setup the DomainKeys signature settings for a group and user, click on the Administer User Accounts icon, click on the name of a group or user (if you clicked on a user, then you may need to click
Maestro User Interface next), then click
DomainKeys Settings. In addition to the options described above, this screen also allows you to define whether or not a certain group or single user is supposed to use the application-wide defaults or special local settings.
If your company or organization has decided that all messages that are sent using LISTSERV Maestro are to be signed with a DomainKeys signature, then choose
Yes, sign e-mails for DKIM and
The user must use the setting supplied above without changes for each mail job on the DomainKeys Setting screen (for application-wide defaults), and then make sure that all groups/users have the
Use inherited value option selected.
If your organization has decided that all messages sent from certain groups using LISTSERV Maestro are to be signed with a DomainKeys signature, then you can create a less strict policy by defining group-level deviations from the application-wide default settings. For example, one group may require the use of DomainKeys signatures while another group may not.
If it is not possible to agree on a strict policy for these settings even on the lowest group and/or single user level, then you should first choose a suitable default for enabling or disabling DomainKeys signatures, and then select the
The user may change the setting supplied above on a per-job basis option.
Important: Before actually using such a setup, make sure to educate your users about the pros and cons of DomainKeys signatures. In a high volume environment, one reason to opt against DomainKeys signatures is that mail job delivery performance is impacted. LISTSERV uses highly optimized algorithms to perform the signing and the throughput benefits from modern CPU extensions such as SSE2, so one option to use DomainKeys even in high volume environments is to acquire better hardware to run LISTSERV. On the other hand, not using DomainKeys may cause deliverability problems in the future if many of your subscribers have accounts with ISPs that enforce DomainKeys signatures on incoming mails or mark mails that lack such a signature as “coming from unsure origin” to warn the user about possible forgery or a phishing attempt.
The LISTSERV Maestro User Interface interacts with LISTSERV to determine if the supplied sender address is supported by one of the DomainKeys that were deployed to the LISTSERV host when DomainKeys was configured. This check is performed at several stages during the life cycle of an email job. The sender definition settings of an email job are only accepted as valid if either DomainKeys signing is switched off or if the check succeeds at the LISTSERV host that is configured for the account. After this, an additional check is performed when the email job is authorized for delivery. If the email job is configured for future delivery, then there is a considerable time window during which the administrator may opt to change the DomainKeys settings at the LISTSERV host. Therefore, if DomainKeys has been disabled during this time window, then the email job delivery will fail with an appropriate error message.
In addition, the system also performs consistency checks between the settings for the current email job and the settings that are defined for the current account in the Administration Hub. These checks ensure that the settings of the email job are the same as the default settings if the administrator has defined that users may not change the DomainKeys settings on the job level. Once the email job has been authorized for delivery, these additional checks are not repeated. This means that if the settings in the Administration Hub are changed, then this change will only affect email jobs that have not yet been authorized for delivery. Jobs that are authorized will not be affected from subsequent changes in the Administration Hub.
