未配信のメールについて不満を言う人-AWSによると、プロバイダーはSMTP250コードを返しました

Question

ウェブサーバーがAWSSimple Email Serviceを介して送信するメールのsomeだけを受信しないことに不満を言うユーザーが何人かいます。電子メールを受信しないユーザーのほとんどは、hotmail.fr電子メールアドレスを持つユーザーです。

現在、専用IPアドレスなしでAWS SESを使用しています（専用IPアドレスを使用することが適切なソリューションであるかどうかについての情報を収集中です）。

Mail-tester.comによると、このメールのレピュテーションは9.9/10であり（DKIMなどはすでに有効になっています）、ここでは主にトランザクションメールについて話しているので、問題は品質に起因するとは思われません。 Eメール。

AWSにサポートチケットを送信しましたが、AWSから次のように返信されました

あなたが親切に提供したhotmailアドレスへのメッセージのリストに関して、私は各電子メールでログダイブを実行し、分析中に次のことに気づきました。

各メッセージは '@。com'によって送信され、250SMTPステータスコードを返しました。これは、SESエンドポイントが受信者のメールサーバーに電子メールを正常に配信したことを意味します。ただし、hotmailドメインに送信された各電子メールには、「SMTP応答メッセージ：配信用のキューに入れられたメール-> 2502.1.5」というメッセージも返されました。これには、「* @ hotmail.com、* @ hotmail.fr、*** @ hotmail.frなど」に送信された電子メールが含まれます。

SESが各電子メールを正常に送信し、受信者サーバーの「hotmail」が要求を処理する方法とキューに入れられた理由がわからないため、Microsoftメールサーバーが電子メールを転送しなかった理由を説明することはできません。受信者に。

メッセージがキューに入れられた理由については、Microsoft（hotmail）とGoogle（gmail）だけが詳細を把握しているため、それぞれのチームに連絡して詳細を確認することをお勧めします。各電子メールサービスプロバイダーには独自のルールとポリシーがあり、電子メールの受け入れ、拒否、キューイング、または分類の方法に関する最後の言葉があります。

これについてMicrosoft/hotmailに連絡する方法をまだ検討中です（適切な連絡フォームを見つけようとしていますが、適切なカテゴリが見つからないようです）。その間、私はこの有名な250 SMTPコードに関するいくつかのものを見つけようとしていますが、配信が実際に機能したという意味で202 Accepted HTTPコードに非常に似ているように感じますが、それでもユーザーはメッセージ）

この250SMTPコードに光を当てるのを手伝っていただければORユーザーがメールを受信しないデバッグの経験があれば、喜んでお手伝いします。

omniomi · Answer

内部ブラックリストからの削除についてMicrosoftに連絡するには、次のフォームを使用する必要があります： https://support.Microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75

送信に正直で、実際にはスパムを送信しておらず、ドメインとメールサーバーを正しく構成していれば、2〜3営業日で削除されると予想できます。

マイクロソフトに連絡する前に：

他のブラックリストをチェックして、公開リストに載っていないことを確認してください（MXToolboxや他のサイトでは簡単な検索ツールが提供されています）。
メールサーバーが実際にスパムの送信に使用されていないことを確認してください（オープンリレー）。
一括またはトランザクションの電子メールを送信する場合は、ベストプラクティスに従っていることを確認してください。
- SPF、DKIM、およびDMARC（最低限SPF）を使用して電子メールを認証します。
- バルクメールの購読解除メカニズムを含めます。（メッセージ内リンクとList-Unsubscribe-PostおよびList-Unsubscribeヘッダーが含まれます。）
- デッドアドレスにメールを送信しないでください。バルク送信者とトランザクション送信者が犯す1つの間違いは、もう存在しないアドレスに送信し続けることです。 MicrosoftやGmailのような大規模な受信者は、これを行う送信者の評判を下げることがよくあります。
- バルクメールとトランザクションメールに異なる送信アドレスを使用し、一貫性を保ちます。

Microsoftには配信可能性ガイドラインドキュメントがあります： https://docs.Microsoft.com/en-us/office365/securitycompliance/reference-policies-practices-and-guidelines そしてGoogleの一括送信者向けガイドラインにも優れたものが含まれています普遍的なアドバイス。