58

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 temp, part-time, or contract employees, and so have private email addresses (eg Hotmail, GMail, Yahoo!, etc).

Up to now, we've been sending from an internal address, but this means that replies come back to us when employees aren't paying attention or don't know to send queries to our clients. I'd like to change this, so that the person who requests that the email is sent is the person that is replied to.

We've used reply-to: in the past, but it seemed to cause additional mail to be trapped by spam filters.

I've been reading about sender: and on-behalf-of: headers, and was wondering what the current best-practice was for sending email in a scenario where we need to send email such that the reply goes to a domain we don't control.

Nick Berardi
  • 54,393
  • 15
  • 113
  • 135
Ben Doom
  • 7,865
  • 1
  • 27
  • 30
  • A common problem, unfortunately spammers have ruined the party on this one. Have you thought about not actually trying to send the email yourself, but rather get your clients to setup email addresses for you (or use an existing one) and then connect to their SMTP to send the emails? This way the replyTos will go straight to your client's email box. – Martin Jul 30 '13 at 09:11
  • Going off of the above comment, would it be possible to have users enter their credentials/email address in a form on your app and then just forward those credentials along to their SMTP server? Would you be able to send an email on their behalf that way? Or is that a bad idea and why? – cs_pupil Apr 03 '19 at 00:42
  • 3
    For those who just want to read the docs: Official IETF RFC Header definitions: https://tools.ietf.org/html/rfc5322 Wiki page on email headers: https://en.wikipedia.org/wiki/Email#Message_header – ADJenks May 31 '19 at 20:17

3 Answers3

44

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.

Nick Berardi
  • 54,393
  • 15
  • 113
  • 135
  • 1
    We already do most of what is recommended in the codinghorror blog (which I read). We use an SPF/Sender-ID record, we have a proper reverse PTR to our web system's SMTP relay. We don't have a problem getting spam trapped at the moment, sending from our own domain. The problem is getting replies routed to the correct parties. – Ben Doom May 06 '10 at 15:59
  • 1
    The problem is that the two methods you listed are for verifying your domain as a valid sender. You need to take the next step and sign every email that is delivered. With a domain key. You need to implement the DKIM, if you read wikipedia (http://en.wikipedia.org/wiki/DKIM) it says "... the transit path; or an indirect handler, **such as an independent service that is providing assistance to a direct handler**...". It is going to be hard if your emails code is all over the place, or if your SMTP server doesn't automatically sign them, another reason to get the service I mentioned above. – Nick Berardi May 06 '10 at 18:33
  • 2
    After you sign every email you can use `on-behalf-of` or you can even just put the actual email in the `from` address which is the bullet proof solution. – Nick Berardi May 06 '10 at 18:35
  • I'll start testing DKIM and see if I can get it running correctly on our mail server(s). I'll let you know if it works. – Ben Doom May 06 '10 at 21:01
  • 3
    I have never heard of `On-Behalf-Of:` and Google only seems to turn up Outlook and Gmail results, nothing like an official standard. Traditionally you would put your client in `From:` and yourself in `Sender:`. My suspicion is that this is what turns up as "on behalf of" in Outlook and possibly Gmail. – tripleee Aug 13 '12 at 07:08
  • 2
    @triplee Putting your client in `From:` violates DMARC. You'll likely get your e-mails rejected, or at least marked as spam. – Zenexer Sep 19 '13 at 23:24
  • @Zenexer Thanks, I didn't know. More of a historical note then. – tripleee Sep 20 '13 at 06:16
  • 2
    `on-behalf-of` - There's no such header in RFC or any known mail standards, Googling does not help too. This question is the only source that pops up. @NickBerardi please indicated the source – jazzcat Nov 23 '16 at 15:59
32

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.

Zenexer
  • 18,788
  • 9
  • 71
  • 77
  • Setting `Sender:` instead of `From:` made the `SendAsDenied` error go away for me with Outlook.com, but as I already use aliases both the `Sender:` and the `From:` were overwritten with my chosen alias and my Outlook.com canonical email address. – Mikael Dúi Bolinder Nov 22 '22 at 09:45
1

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.

Community
  • 1
  • 1
Engineer
  • 47,849
  • 12
  • 88
  • 91
  • This is definitely the way to go. But there must be a ready-made package for forwarding emails that way. Do you know of something? – gabn88 Feb 11 '21 at 10:45