Trend Micro Email Security (TMEmS) では送信保護を利用して外部宛にメッセージを送信する際、TMEmS のメールサーバから "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." の応答が返され、メッセージを送信できない場合があります。
この事象は TMEmS のリレー制限に起因しており、対処策も含め、TMEmS のリレー制限の詳細について説明します。
インターネットメールを処理するメールサーバ (SMTP サーバ) ではオープンリレー (不正リレー) を防止するためのリレー制限が設けられています。
Trend Micro Email Security (TMEmS) のメールサーバも例外ではありません。TMEmS では管理コンソールの ドメイン メニュー に登録されている管理ドメインの設定状況にしたがってリレーが制限されています。
ここでは 受信保護 (外部から内部宛) のトラフィックと 送信保護 (内部から外部宛) のトラフィックに分けて説明します。
-
「送信者」「受信者」とはここではエンベロープの送信者と受信者を意味します。From ヘッダや To ヘッダなど、メッセージヘッダに指定されているものではありません。
-
受信保護と送信保護のメールサーバのホスト名は TMEmS を利用しているデータセンターによって異なります。
受信保護のメールサーバのホスト名は管理コンソールの ドメイン メニュー にあるドメイン設定の 受信サーバ のセクションにおいて「詳細な設定」のリンクをクリックすると、「➌ 次のTrend Micro Email Securityサーバを、プリファレンス値が最小のドメイン内のMXレコードとして設定します。」に記載されています。
送信保護のメールサーバのホスト名はドメイン設定の 送信サーバ のセクションにおいて「詳細な設定」のリンクをクリックすると、「➌ 送信メールサーバを次のTrend Micro Email Securityサーバにルーティングします。」に記載されています。
受信保護におけるリレー制限
TMEmS の受信保護のメールサーバ (通常 <会社 ID>.in.tmems-jp.trendmicro.com) のホストは受信者のドメインが管理コンソールの ドメイン メニュー に管理ドメインとして登録されていればメッセージのリレーを許可します。
受信者のドメインが管理ドメインとして登録されていない場合、受信保護のメールサーバは送信元メールサーバに "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." の応答を返し、メッセージの受信を恒久的に拒否します。
送信者のドメインや接続元 (送信元) のIPアドレスは受信保護のリレー制限には関係ありませんが、送信者ドメインの DNS の公開状況によってメッセージの受信が拒否される場合 があります。
受信保護のリレー制限でブロックされたメッセージの確認方法
受信者のドメインが管理ドメインとして登録されていないため、原則、製品側でブロックされたメッセージを確認することはできません。
受信保護のメールサーバが送信元メールサーバに "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." の応答を返してメッセージの受信を恒久的に拒否した場合、送信元のメールサーバは配信不能通知 (バウンスメール) を生成して送信者に送信します。通常バウンスメールにはメッセージが "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." で拒否されたことが明記されています。
また、送信元メールサーバのメールログには通常、受信保護のメールサーバが "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." でメッセージの受信を拒否したログが出力されています。
そのため、送信者に送信されたバウンスメールや送信元メールサーバのメールログを確認する必要があります。
受信保護のリレー制限でブロックされた場合の対処策
例えば内部から外部宛のメッセージはユーザのメールサーバから送信保護のホスト (通常 <会社 ID>.relay.tmems-jp.trendmicro.com) にリレーされますが、誤設定でユーザのメールサーバが外部宛のメッセージを受信保護のホストにリレーした場合に発生します。
その場合、ユーザのメールサーバの配送設定を見直し、外部宛のメッセージを送信保護のホストにリレーするよう適切に設定してください。
送信保護におけるリレー制限
TMEmS の送信保護のメールサーバ (通常 <会社 ID>.relay.tmems-jp.trendmicro.com) のホストは送信者と接続元の条件をいずれも満たしている場合にメッセージのリレーを許可します。
- (送信者の条件) 送信者が null である、または、送信者のドメインが管理ドメインとして登録されており、そのドメイン設定において送信保護が有効化されている
- (接続元の条件) 接続元 (送信元) IPアドレスがドメイン設定の 送信サーバ のセクションに登録されている
送信者のドメインが 送信者の条件 を満たしていない場合、送信保護のメールサーバは送信元メールサーバに "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." の応答を返し、メッセージの受信を恒久的に拒否します。
送信者のドメインに対して送信保護が有効化されていたとしても、送信者ドメインの DNS の公開状況によってメッセージの受信が拒否される場合 があります。
接続元IPアドレスが 接続元の条件 を満たしていない場合、送信保護のメールサーバは送信元メールサーバに "554 5.7.1 ... Recipient address rejected: Invalid-Sender-IP." の応答を返し、メッセージの受信を恒久的に拒否します。
送信保護のリレー制限でブロックされたメッセージの確認方法
まず、通常、送信者に送信されたバウンスメールや送信元メールサーバのメールログから、送信保護のメールサーバが "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." または "554 5.7.1 ... Recipient address rejected: Invalid-Sender-IP." でメッセージの受信を拒否したことがわかります。バウンスメールやユーザのメールサーバのログを確認してください。
また、送信者のドメインが管理ドメインとして登録されているものの送信保護が有効化されていない場合 (送信者の条件)、管理コンソールの ログ > メール追跡 の画面で方向に「送信」、種類に「ブロックされたトラフィック」を選択して検索すると、ブロック理由 に「その他」が表示されたログを確認できます。
送信者のドメインに対して送信保護が有効化されているものの、接続元IPアドレスが 送信サーバ のセクションに登録されていない場合 (接続元の条件)、同様に ログ > メール追跡 の画面で方向に「送信」、種類に「ブロックされたトラフィック」を選択して検索すると、ブロック理由 に「許可されない送信者のIP」が表示されたログを確認できます。
送信者のドメインが管理ドメインとして登録されていない場合 (送信者の条件)、メール追跡の画面で検索することはできません。
送信保護のリレー制限でブロックされた場合の対処策
一般的に、メッセージの送信者のドメインが管理ドメインとして登録されているか、登録されている場合にはドメイン設定の 送信サーバ のセクションで「送信保護を有効にする」のオプションが有効化されているかを確認してください。
また、送信保護が有効な場合、送信サーバ のセクションにユーザのメールサーバに応じて「Office 365」や「Google G Suite」、そしてユーザのメールゲートウェイのIPアドレスがすべて登録されているかを確認し、適切に設定してください。
内部から外部に転送されるメッセージや内部のメーリングリストのメールサーバから外部に送信されるメッセージが "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." で拒否されるのであれば、以下の対処策を実施してください。
転送やメーリングリストの場合
外部から内部宛のメッセージをユーザのメールサーバなどが外部の宛先に自動的に転送した場合や、内部のメーリングリストのメールサーバがメーリングリストに登録されている外部の宛先に転送した場合、エンベロープの送信者に外部の元のメールアドレスが指定されたまま送信保護のメールサーバにリレーされる可能性があります。
例えば外部の送信者 (gmail.com) が内部ドメイン (ここでは example.com とします) 宛にメッセージを送信した場合、まずメッセージはエンベロープの送信者 (Mail From) には gmail.com、エンベロープの受信者 (RCPT TO) には管理ドメインである example.com のメールアドレスが指定され、以下の配送経路でユーザのメールサーバに配送されます。
- 元のメッセージ (送信者 gmail.com, 受信者 example.com)
- Gmail のメールサーバ → TMEmS の受信保護のメールサーバ → ユーザのメールサーバ
ユーザのメールサーバではその受信者宛のメッセージを受信すると自動的に yahoo.com のメールアドレスに転送しているとします。しかし、転送時に送信者のメールアドレスを変更していなければ、エンベロープの送信者 (Mail From) には gmail.com、エンベロープの受信者 (RCPT TO) には yahoo.com のメールアドレスが指定され、送信保護のメールサーバに転送メッセージは配送されることになります。
その場合、メッセージは 送信者の条件 を満たしていないため、送信保護のメールサーバは送信元メールサーバに "554 5.7.1 ... Recipient address rejected: NO-DOMAIN." の応答を返し、メッセージの受信を恒久的に拒否します。
- 転送メッセージ (送信者 gmail.com, 受信者 yahoo.com)
- ユーザのメールサーバ → ✖ TMEmS の送信保護のメールサーバ
対処策として以下があります。
- 外部からのメッセージに対する転送メッセージやメーリングリストのメッセージは送信保護のメールサーバにはリレーしない
- エンベロープの送信者を null ("<>") または管理ドメインのメールアドレスに変更して転送する
まず、通常、元のメッセージは外部からメッセージを受信した時点で受信保護のメッセージとして TMEmS によってすでに検索されています。もしユーザのメールサーバやメーリングリストのメールサーバ側で設定が可能であれば、外部からのメッセージに対する転送メッセージは送信保護のメールサーバにはリレーせず直接、外部の宛先のメールサーバに配送してください。
送信保護のメールサーバに配送しないよう対処することが困難な場合、ユーザのメールサーバやメーリングリストのメールサーバ側で エンベロープの送信者のメールアドレスを null ("<>") に変更するか、管理ドメインのメールアドレスに変更 (特定の管理ドメインのメールアドレス、または元のメッセージにおいてエンベロープの受信者に指定されていたメールアドレスに変更) して送信保護のメールサーバにリレーしてください。
前述の例であれば、ユーザのメールサーバにおいてエンベロープの送信者に内部ドメイン (example.com) のメールアドレスを指定して転送するよう設定を変更した場合、転送メッセージは以下のように宛先である Yahoo! のメールサーバに問題なく配送されます。
- 転送メッセージ (送信者 example.com, 受信者 yahoo.com)
- ユーザのメールサーバ → TMEmS の送信保護のメールサーバ → Yahoo! のメールサーバ
-
送信者を null ("<>") に変更した場合、メール追跡でメッセージのログを検索することはできません。
-
送信者を管理ドメインのメールアドレスに変更した場合、外部の宛先のメールサーバがなんらかの理由でメッセージの受信を拒否すると、バウンスメールが送信者に指定したメールアドレスに送信されます。そのバウンスメールが再度外部の宛先に転送されると、宛先のメールサーバによってメッセージの受信を拒否され、バウンスメールが生成され、メールループの状況に陥ります。
送信者を null ("<>") に変更した場合、バウンスメールは生成されないため、メールループの状況に陥ることはありません。
