ここで新しい機能リクエストを開きます。現在、Discourse では envelope-from と reply-to の両方に使用される単一のメールアドレスのみが許可されています。サイトがメール送信のために独自のドメイン SMTP を使用したいが、メールの返信は別のドメイン (例: Gmail) に送信したい場合、送信されたメールは DMARC で失敗します。これら 2 つのヘッダーフィールドを分離することで、DMARC の失敗を回避し、バウンスメールを処理する能力を失うこともありません。
このトピックに関する詳細情報
このシナリオでバウンスがどのように処理されるのか分かりません。バウンスはエンベロープFROMに送信され、Reply-Toのアドレスには送信されません。したがって、エンベロープFROMがVERPタグ付きのメールを処理できない場合、問題は解決しません。
参照しているトピックでは、From:ヘッダーのドメインに対してDKIM署名が機能しない理由を説明していません。SPFが失敗した場合でも、これによりDMARCアラインメントが提供されるはずです。もし私があなたの立場なら、そのアプローチを取るでしょう（そうでなければ、yyy.comの受信SMTPサーバーの管理者にピッチフォークを持っていくでしょう。どのようなMTAが詳細なアドレス指定をサポートしていないのでしょうか？！）。
MTAがcatch allをサポートしているため、機能します。VERPはサポートしていませんが、指定されていないすべてのメールを特定のメールに転送するように設定できるため、バウンス返信が失われることはありません。
また、envelope-fromとreply-toを分離すれば、envelope-fromにVERPアドレスを含める必要はありません。_discourse@yyy.com_のような単純なアドレスで構いません。バウンスバックすると_discourse@yyy.com_に戻り、SPFに失敗することはありません。
reply-toには、_discourse-yyy+sdfkj33@gmail.com_のようなVERPをサポートする別のアドレスを指定できます。これにより、正常に配信された場合、ユーザーが返信するとVERPをサポートするGmailサーバーに届き、fromが依然として_yyy.com_であるためDMARCに失敗することはありません。
同意しますが、私たちはそれらを作成していません。catch-allアドレス指定を使用しているため、VERPはサポートしません。残念ながらそれが現状であり、少しの調整でDiscourseがより多様なエコシステムをサポートできるようになることを願っています。Gmailで返信を処理している小規模サイトの多くがこの状況に陥るでしょう。
MTAがキャッチオールをサポートしているのに、なぜ同じ機能で返信を転送できず、Gmailを完全に除外できないのですか？
エンベロープFROMはVERPをサポートする必要があるアドレスです。なぜなら、バウンスの原因を確実に特定する唯一の方法は、元のメールのエンベロープFROMアドレスに含まれる情報によるからです。これは、Michaelが以前説明したとおりです。
その主張には疑問があります。返信にGmailアドレスを使用するのは、常にまともではなく、まともではありませんでした。mail-receiverは、返信（およびバウンス）を処理するための、はるかに簡単で信頼性が高く、まともな方法です。
Gmailを使用している小規模サイトであっても、本当にごく一部のサイトは利用規約を無視してGmailを送信にも使用している可能性があり、残りの大多数は詳細アドレッシングをサポートしていないMTAに依存していない可能性が高いです。
ドメインのキャッチオールであり、Discourseには1つのメールアドレスしか使用されていないためです。
必ずしもそうではありません。現在、VERPなしで使用していますが、機能しています。私の問題は、Discourseがenvelope-fromとreply-toアドレスを設定する方法により、SPF/DMARCの失敗なしにユーザーがGmailに直接返信できないことです。代わりに、MTAにGmailに転送させる必要があります。Gmailに直接返信できるようにすれば（DMARC/SPFの失敗なしに）、VERPを使用して返信を保護できますが、バウンスメールではVERPは無視されます。それでも、現在の実装よりも安全です。
ここで説明したように、それは選択肢ではありません（Setting Up Discourse using Gmail SMTP Settings - #5 by RBoy
あなたの考え方で何か見落としているのかもしれません。envelope-fromとreply-toアドレスを分離することには、メリットしか見いだせません。より多様なエコシステムをサポートし、より安全で、SPF/MARCの失敗を回避するのに役立ちます。
私の考えでは、これまでのところ表明されているあなたの問題に対する正しい答えは、DKIMを設定することです。IMO（私の意見では）あなたのユースケースでは、メール設定をさらに複雑でエラーを起こしやすくすることは正当化されません。
DKIM は既に設定済みで、問題は SPF が失敗していることです。
envelope-from と reply-to アドレスを分離する追加フィールドを追加することで、多くの柔軟性が提供され、SPF もパスできるようになります（SMTP サーバーがメールを転送する場合や VERP をサポートしていない場合はパスしません）。このフィールドは UI で非表示にすることも、管理者が明示的に上書きしない限り envelope-from および reply-to アドレスに一致するように設定することもできます。説明はこのページを指すことができます。しかし、これがさらに悪化するとは思えません。良くなるしかありません。それらは同じ（この場合、SPF はここで説明されているどのシナリオでも失敗します）か、配信可能性が向上します。