Best practices: Sending email on behalf of users

Question

The company I work for provides testing services for the healthcare industry. As part of our services, we need to send email to our clients\' employees. Typically, these are t

Answer 1

The on-behalf-of header is the best way to do that, but you are also going to get trapped by spam filters. The best to mitigate or lessen the likelihood that you will end up in the spam filter is to implement all the industry standards around verifying your domain and mail server. As indicated in this article:

http://www.codinghorror.com/blog/2010/04/so-youd-like-to-send-some-email-through-code.html

However that is very tough to do, because you need to stay on top of SPAM standards, and abide by CAN-SPAM laws and everything else. The better bet is to use a on-demand cloud based SMTP server like this one:

https://www.postmarkapp.com

Use a company that is a domain expert in the area of sending email and has gone through all the leg work to get the highest deliverability rate. And will stay on top of the standards for you, and monitor black lists for problems.

Answer 2

You want to cheat and hack email authentication systems by trying to send emails on behalf of others. Maybe this hack can work temporarily, but in the future it will be banned by mailbox providers, as phishing attacks require more and more strict policies mailbox providers need to apply.

To avoid such hacks here is a solution I would suggest. Create a unique email address for every client and make it "mediator" for conversation between client and employees.

How it works

All email conversation must be done through your created email. You can set custom display names (e.g. John <123@yourdomain.com) to not confuse email receivers with your strange unique ids. So when A needs to write to B, it actually writes to your email, then you forward email to B, and vice versa for B to A.

This implementation have some complexity, but that will be paid in the future.

Answer 3

You're probably looking for Reply-To. It's an official and widely supported header, unlike On-Behalf-Of, and it's not subject to the same spam checks as From.

If you really wanted to appear as sending on behalf of another user, the "mostly" correct way, by SMTP standards, would be to put your "real" address in Sender: and your client's address (of whom you're sending on behalf) in From:. However, From: is specifically targeted by DMARC, a very strict spam prevention protocol implemented by most major e-mail providers. They won't overlook a From: DMARC failure just because you have a valid Sender: header.

DMARC allows domain owners to specify how SPF and DKIM should be applied to the From: header. A popular policy is to reject e-mail that fails either SPF or DKIM, which means your e-mail won't even be flagged as spam: it will be downright rejected.

Sender: + From: still works, technically. It was originally created with the intention of being used by people in the same organization, such as a secretary or an assistant. This has turned into a hard constraint with the advent of spam prevention mechanisms.