Using a Sender Address with SocketLabs

Basic Information About the Sender Address

An email message is made up of two primary parts, the header and the body. The header of an email is where you will find common values of a message such as the To Address, From Address, and Subject line. This knowledgebase will review a lesser-known and less-frequently-utilized header field known as the Sender Address.

Specifying a Sender Address allows you to identify a separate address different than the From Address as being responsible for sending the message. This separation helps resolve authentication and spoofing issues when sending email on behalf of others. Here is what a sample email header with a sender address header line item would look like:

Date: Mon, 29 Dec 2018 08:25:53 -0400 (EDT)

From: UserAddress UserFrom@customerexample.com

Sender: CompanyName sender@yourdomain.example.com

To: "Recipient" recipient@socketlabs.com

Message-ID: 1297680571.35922.53455432.root@test203.example.com

Subject: Sample Message with Sender Header

MIME-Version: 1.0

Content-Type: text/html

Content-Transfer-Encoding: 7bit

In the sample header above, the Purported Responsible Address (PRA)would identify as sender@yourdomain.example.com rather thanUserFrom@customerexample.com. The PRA is used in SenderID authentication, a technology once strongly promoted by Microsoft, and it can affect DKIM authentication for messages processing through SocketLabs Email-On-Demand.

Sender Address and DKIM

The Sender address affects DKIM signing in that SocketLabs will only add custom DKIM signatures if a signature has been established at the PRA domain. If you are sending messages on behalf of other users and you do not add the Sender header at your own domain the messages will not be signed with your custom DKIM signature.

In the example above, if a custom DKIM signing option was established in the SocketLabs On-Demand Control Panel for "yourdomain.example.com", a customized signature would be included in the message. This would significantly improve message deliverability and add custom branding on platforms such as Gmail which identify the authenticating domain to the recipient with a “via” tag.

Reference

The Sender Header is officially outlined in RFC 822. Below is a small snippet from the RFC that defines the field and how it should be used in an email message.

4.4.2. SENDER / RESENT-SENDER - This field contains the authenticated identity of the AGENT (person, system or process) that sends the message. It is intended for use when the sender is not the author of the message, or to indicate who among a group of authors actually sent the message. If the contents of the "Sender" field would be completely redundant with the "From" field, then the "Sender" field need not be present and its use is discouraged (though still legal). In particular, the "Sender" field MUST be present if it is NOT the same as the "From" Field.

The Sender mailbox specification includes a word sequence which must correspond to a specific agent (i.e., a human user or a computer program) rather than a standard address. This indicates the expectation that the field will identify the single AGENT (person, system, or process) responsible for sending the mail and not simply include the name of a mailbox from which the mail was sent. For example in the case of a shared login name, the name, by itself, would not be adequate. The local-part address unit, which refers to this agent, is expected to be a computer system term, and not (for example) a generalized person reference which can be used outside the network text message context.

Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer program generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mailbox specification.

Related Information