blog

I recently came across a case where a real lot of e-mail from various customers was to be sent from a mail server which wasn't related to the customer's operations in any way, so I tried to find out what might be considered best practice to set envelope and header fields to when mail is sent on behalf of others.

As RFC 5322 states:

In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. […] The contents comprise the object to be delivered to the recipient.

As it turned out, these statements already contain most of the relevant information needed: All the transport-related information is handled using the envelope, and only the content is supposed to be delivered to the recipient.

Let's consider the following case:

• alice@anywhere.test – our customer in whose name we'd like to deliver mail from.
• bob@somewhere.test – the recipient of the e-mail in question.
• mail-server.example.org – the domain name of our mail server used for delivery.

We will deliver Alice's mail to Bob using the following procedure:

• We'll set sender-name@mail-server.example.org as the “envelope from”, respectively 5321.from (this is what we're using for MAIL FROM in the SMTP dialog).
• The mail content's From: header will be alice@anywhere.test.
• We'll sign the mail contents using the DKIM key which we were given by Alice, and for which the corresponding public key is published in the associated <dkim-selector>._domainkey.anywhere.test DNS record.
• In case Alice has published a DMARC record for anywhere.test, she'll make sure that it contains DKIM alignment.

When this e-mail is recevied by Bob's mail server, it will typically run various checks on this e-mail:

• SPF: This check should pass since SPF is validating whether the sender's IP address is authorized to send mail on behalf of the domain of the “envelope from” address. Since we're using our own domain and sender IP address, this check will succeed as long as we've simply got a correctly configured SPF record on our mail-server.example.org domain.
• DKIM: This check will succeed since we've signed the e-mail using Alice's own DKIM key.
• DMARC: In case there's a DMARC record published for the anywhere.test domain, the check will succeed since Alice has made sure that it contains DKIM alignment. Since the DKIM check will be okay, the DMARC check in turn succeeds, since it is sufficient for either SPF or DKIM alignment to be correct.

Furthermore, by setting the “envelope from” to an address of our actual sending mail server we can ensure that non-delivery messages will be actually returned to our sending server, so we'll be able to react accordingly. And since envelope data is never shown directly to the user receiving the mail, bob@somewhere.test will only see alice@anywhere.test as sender.

At first, the points which require cooperation with the customer might sound a bit scary: It might be quite hard simply to comunicate the details of a DKIM or DMARC record, especially to people with no technical background on these matters. In most cases however, it should be sufficient that the client publishes a single TXT record, which will contain the DKIM public key data we're using for signing. In most cases, the DMARC record won't have to be touched, since it's either not present – so DMARC checks won't be performed at all – or it already has the DKIM policy set correctly – because if not, it's practically not possible to receive forwarded mail. As for the DKIM record, we can create the key data ourselves and use a separate DKIM selector which can exist in parallel with others in the customer's DNS records, so just publishing this single TXT record will be enough.