ベストプラクティス：ユーザーに代わってメールを送信する
私が働いている会社は、ヘルスケア業界にテストサービスを提供しています。サービスの一環として、クライアントの従業員にメールを送信する必要があります。通常、これらは臨時社員、パートタイム社員、または契約社員であり、プライベートメールアドレス（Hotmail、GMail、Yahoo！など）を持っています。
これまでは、内部アドレスから送信していましたが、これは、従業員が注意を払っていないか、クライアントにクエリを送信することを知らない場合に返信が返されることを意味します。これを変更して、メールの送信を要求する人が返信される人になるようにします。
過去にreply-to：を使用していましたが、スパムフィルターによって追加のメールがトラップされるようでした。
Sender：およびon-behalf-of：ヘッダーについて読んでいますが、返信がドメインに送信されるようにメールを送信する必要があるシナリオで、メールを送信するための現在のベストプラクティスは何であるか疑問に思っていましたtコントロール。
on-behalf-ofヘッダーはそれを行うための最良の方法ですが、スパムフィルターに閉じ込められることにもなります。スパムフィルターに陥る可能性を軽減または軽減する最善の方法は、ドメインとメールサーバーの検証に関するすべての業界標準を実装することです。この記事に示されているとおり：
http://www.codinghorror.com/blog/2010/04/so-youd-like-to-send-some-email-through-code.html
ただし、これは非常に困難です。SPAMの標準を維持し、CAN-SPAMの法律およびその他すべてを順守する必要があるためです。より良い方法は、次のようなオンデマンドのクラウドベースのSMTPサーバーを使用することです。
電子メールの送信分野のドメインエキスパートであり、最高の配信率を得るためにすべての作業を行った会社を使用します。そして、あなたのために標準のトップに留まり、問題のブラックリストを監視します。
おそらくReply-Toを探しています。 On-Behalf-Ofとは異なり、広くサポートされている公式のヘッダーであり、Fromと同じスパムチェックの対象ではありません。
別のユーザーに代わって送信するように見せたい場合は、SMTP標準による「ほぼ」正しい方法は、Sender:とクライアントのアドレス（自分のアドレス）に "実際の"アドレスを入れることです。代わりに送信）From:で。ただし、From:は、ほとんどの主要な電子メールプロバイダーによって実装されている非常に厳格なスパム防止プロトコルであるDMARCによって明確にターゲットにされています。有効なFrom:ヘッダーがあるからといって、Sender: DMARCの失敗を見逃すことはありません。
DMARCでは、ドメイン所有者がSPFとDKIMをFrom:ヘッダーに適用する方法を指定できます。一般的なポリシーは、SPFまたはDKIMのいずれかで失敗した電子メールを拒否することです。つまり、電子メールはスパムとしてフラグ付けされることさえありません。完全に拒否されます。
Sender: + From:は引き続き技術的に機能します。もともとは、秘書やアシスタントなど、同じ組織の人々が使用することを意図して作成されました。これは、スパム防止メカニズムの出現により、厳しい制約に変わりました。
他の人に代わって電子メールを送信しようとすることにより、電子メール認証システムをごまかし、ハッキングしたいと考えています。このハッキングは一時的に機能する可能性がありますが、フィッシング攻撃にはメールボックスプロバイダーが適用する必要のあるより厳しいポリシーが必要になるため、将来的にメールボックスプロバイダーによって禁止されます。
このようなハッキングを避けるために、ここで解決策を提案します。 すべてのクライアントに一意のメールアドレスを作成し、クライアントと従業員間の会話の「仲介者」にします。
仕組み
メールでの会話はすべて、作成したメールで行う必要があります。カスタム表示名を設定できます（例：John <[email protected]）電子メールの受信者を奇妙な一意のIDと混同しないようにします。したがって、AがBに書き込む必要がある場合、実際にあなたのメールに書き込み、Bにメールを転送し、BからAにメールを転送します。 。
この実装には多少の複雑さがありますが、将来的には支払われる予定です。