Define Sender
Depending on the settings for your account, you may have up to two of the following methods to define how the sender information is provided with the messages sent to the recipients of the mail job:
Use sender profile: With this method, you pick a predefined sender profile from the given list.
Note: If no predefined sender profiles exist, then you (or another user in your group) must first create a sender profile. Once this has been done, the sender profile is listed here.
Sender profiles are used just-in-time: Once you pick the desired sender profile, the current settings of the profile are shown here. However, any subsequent changes that are made to the sender profile until the moment of delivery are copied into the job just-in-time when delivery starts and are reflected in the messages sent to the recipients.
Define sender information manually: When defining the sender information for the mail job manually, you provide the information described below.
Email Address: This must be a valid Internet email address, used as the sender address for the message. This parameter is mandatory and must be completed.
When a static email address is used as the sender address, all recipients receive the same sender address in the message. Alternatively, you may input a sender address containing a text string with merge fields so that each recipient receives a message with a personalized sender address. See below for details.
Sender Name: Enter the name of the sender, used together with the sender address. This parameter is optional and can be left blank. If left blank, no sender name is used.
When a static sender name is used, all recipients receive the same sender name in the message. Alternatively, you may input a sender name containing a text string with merge fields so that each recipient receives a message with a personalized sender name. See below for details.
Reply-To Address: This must be a valid Internet email address, used as the reply-to address for the message. This parameter is optional and can be left blank. If provided, this address is used to send a reply to the message when recipients click "reply" in their email client. If left blank, replies will go to the sender address.
When a static email address is used, all recipients receive the same reply-to address in the message. Alternately, you may input a reply-to address containing a text string with merge fields so that each recipient receives a message with a personalized reply-to address. See below for details.
Option: Instead of a single email address, you may also specify several addresses, separated by comma.
Bounce Handling: Bounced messages are undeliverable messages that are returned to the sender for various reasons, usually because the recipient was not found at the email address listed.
Bounced messages can be handled automatically by the system, or sent to another user-supplied valid Internet email address.
If bounces are sent to another user-supplied address, LISTSERV Maestro will not see or record them and a report of bounced email addresses cannot be generated. If such a report is desired, then it is necessary to allow bounces to be automatically handled by Maestro.
Note: The bounce handling option is only available if it has been enabled in the hidden options in the preferences.
Advanced Sender-Defined Email Header Settings
The advanced sender-defined email header settings are disabled by default. Click the corresponding link to enable the advanced settings. Once enabled, the advanced settings can again be disabled by clicking the disable link.
"To:" Header Override: This allows you to override the value of the "To:" header for all recipients. Normally, the "To:" header should contain the recipient's address and optionally also his name, so that for each recipient an individual "To:" header is used.
If a sender-override for the "To:" header is defined, the same value is used for all recipients. The value you specify is used without any changes, i.e. you have to make sure to provide a value that is valid for the "To:" header (following the MIME header rules).
Note that the "To:" header override is ignored if the recipients type is "Send to an Existing LISTSERV list" of the type "Send job as standard list message to list members".
List-Unsubscribe Header: Even though the List-Unsubscribe header is optional, including it is strongly recommended. Most web-based email clients provided by the major email providers such as Microsoft and Google recognise this header and, instead of exposing its value verbatim in the email client, show an Unsubscribe button that the recipient can click if they would like to stop future messages. Including this special header (and thus, if supported, an Unsubscribe button in the user interface of the email client) is viewed positively by most ISPs, spam filters and unsubscribe reputation services.
The "List-Unsubscribe" header supports both an email-based (mailto) and web-based (http) unsubscribe mechanism.
Example: <mailto:unsubscribe-address@my.domain>, <http://my.domain/unsubscribe-url>
Note: If the recipients of your mail job are based on a subscriber list in Maestro's builtin Subscriber Warehouse, then LISTSERV Maestro adds the List-Unsubscribe header automatically and uses the subscriber list's unsubscribe http URL as value.
X-Headers: This allows you to define additional sender-defined email headers following the X-Header convention as described in RFC822.
Enter the header name (including the leading "X-", which is mandatory) into the X-Header-Name column and the text for that header into the X-Header-Text column. The additional headers are added to the end of the header part of the email, just before the actual message content. They are added in the order you enter them here.
Rows where both the name and the text columns are empty are ignored; therefore, to remove a certain header, simply click the Clear Row link of the corresponding row. If you need more rows than are currently visible, click the Add Row link.
DomainKeys Signature
The DomainKeys settings are only visible if the administrator has configured this for your account.
If visible, the settings will show if the message will be signed with a DomainKeys signature or not. An override option may also be available, but only if the administrator has enabled it. With this additional option, you can override the default signing behavior for the current mail job and define yourself if the message shall be signed or not.
Digitally signing email messages following the DomainKeys Identified Mail(DKIM) standard is a means to assert that the message indeed originated from the domain that is claimed in the From: address. The digital signature is created for the whole message, which has the additional benefit that the recipient (once the signature has been verified) can be sure that the message has not been modified on its path from the sender to the recipient.
If DomainKeys signing is enabled for the current mail job, then you must supply a sender email address that does not have a merge field in the domain part of the address, and where the domain is one for which a DKIM key has been configured at the LISTSERV host that is used by your account. Otherwise the delivery will fail.
Using Merge Fields Instead of Static Values
Normally, the first three input fields, Email Address, Sender Name, and Reply-To Address are supplied with static values (Sender Name and Reply-To Address are optional). These static values are then used as the sender address, sender name, and reply-to address of the mail. The resulting messages have the same sender information and reply-to address for all recipients.
As an advanced feature, you can provide each recipient with personalized values by entering any text containing one or several merge fields into the corresponding field.
The only merge fields that are available for use in Email Address, Sender Name, and Reply-To Address must come from the merge fields provided by the recipients of the job. These fields may be used to personalize the sender information and reply-to address. The merge field names must be entered in exactly the same format as when they are used as merge fields in the content. This format begins with an ampersand "&", is followed by the exact name of the field, and ends with a semi-colon";".
Example 1: If, in your recipient data, you have a merge field called SENDER_ADDRESS that contains the individual sender address to be used for each recipient, then you would fill out the Email Address field with the following text: "&SENDER_ADDRESS;".
Example 2: If, in your recipient data, you have a merge field called DEPARTMENT that contains the name of the department the recipient belongs to, and you have created management email accounts of the form "manager_DEPARTMENT@company.com" for your departments (where DEPARTMENT stands for the department's name) and you want all replies from recipients to go to the manager address of the department the recipient belongs to, then you would fill out the Reply-To Address field with the following text: "manager_&DEPARTMENT;@company.com"
Important: When using text with merge fields for the sender or reply-to address, you must make sure that after the replacement (which is done individually for each recipient) each field results in a valid Internet email address for every single recipient. If not, then the reply functionality of the email (at the recipient's end) will be broken and recipients will be unable to reply to the message. The system will not verify this for you. You must make sure that this condition is met yourself; otherwise, the delivered email could appear with broken sender information and/or reply addresses.
Option: For the reply-to address, the result after the merge field replacement may also consist of several email addresses, separated by comma.