550 5.7.367 Sender Not Authorized for Relay" エラーメッセージの修正

メールを送信しようとしたが、"550 5.7.367 送信者がリレーを許可されていません。"エラーのポップアップが表示された場合、あなたは正しい場所に来ました。重要なメールの送信に失敗した人にしか、このエラーがどれほど疲れるものかは理解できないでしょう。しかし、これはあなただけではありません！sender not authorized for relay "エラーは通常、受信側のメールサーバーがあなたを本物の送信者として認識しない場合に発生します。

メール配信の問題を防ぐためには、この問題を解決することが不可欠です。この記事では、このエラーの意味、考えられる理由、そして最も重要な解決方法について説明します。詳しくはこちらをご覧ください！

送信者が中継を許可されていない」とは？

メール送信時に「Sender Not Authorized for Relay」というエラーが表示されたことがあるかもしれません。このエラーは、その名の通り、メールを送信しようとしている人が、サーバーを経由してリレーメールを送信することを許可されていない場合に発生します。

リレーとは、ユーザーのメールボックスに到達するまで、サーバーからサーバーへ電子メール・メッセージが送信されるメール・サーバーのことである。オープン・リレーとは、認証されていないメール・サーバーのことで、このサーバーを経由してメールが送信される。これらのサーバーのセキュリティはほとんどゼロに等しい。そのため、サイバー攻撃を受けやすい。

しかし、制限付きリレーでは、認証された電子メールだけがサーバーを通過することができる。そのため、ユーザーがこれらのサーバーを経由してメールを送信しようとすると、「Outlookの送信者はリレーが許可されていません」というエラーが表示される。

送信者がリレーを許可されていません」エラーの一般的な原因

このエラーの主な原因は、適切な認証が行われていないことである。しかし、さまざまな原因が考えられます。

1.SPFレコードの問題

送信元IPがドメインの SPFレコードに含まれていない場合、"Sender Not Authorized for Relay" エラーが発生することがあります。SPF認証の際、受信サーバーはあなたのドメインのSPFレコードをチェックし、承認された送信者を確認します。あなたの送信元IPがこのレコードに記載されていない場合、未承認とみなされ、次のようなエラーにつながります。 SPF失敗.

2.DKIMまたはDMARCの失敗 

DKIMまたは DMARCの失敗は、厳格な認証ポリシーが適用されている場合、"Sender Not Authorized for Relay "エラーにつながる可能性があります。 DKIMは、設定ミス、DNSレコードの欠落、転送中の電子メールの変更などが原因で失敗することがあります。さらに、ドメインの DMARCポリシーが "p=reject"に設定されている場合、SPFとDKIMのアライメントに失敗したメールはすべてブロックされ、不正な送信者によるメッセージの中継を防ぐことができます。

3.不適切なメールサーバーの設定

メールサーバーの設定が正しくない場合、SMTPリレーの問題から古いサーバーセッションまで、さまざまな問題があります。メールサーバーの認証プロトコルを更新していない場合、このエラーが表示されることがあります。不正なポート番号を含む構成設定も、このエラーにつながる可能性があります。

4.IPブロックリストとドメイン制限

Eメールサービスプロバイダーは、IPアドレスをブロックしたり、ブロックリストにドメインを追加したりして、トラブルを引き起こすことがある。ESPによってブロックリストに登録されたドメインは、メッセージの中継ができなくなる。

これ以外にも、ドメインによっては、認証されたユーザーだけがメールを送信できるように厳しい制限を課している場合があります。また、ドメインがブロックリストに登録されているかどうかを確認することもできます。 DNSおよびIPブロックリスト監視ツールツールを使って確認することもできます。

5.SMTP認証の設定ミス

SMTPサーバーは、送信者がそのサーバーを経由してメールを送信することを許可されていることを確認するために認証を必要とします。認証設定が正しくない場合、サーバーは電子メールを拒否し、「Sender Not Authorized for Relay（送信者がリレーを許可されていません）」というエラーが表示されます。これは、送信者が不適切なユーザー名またはパスワードの組み合わせを使用している場合や、電子メールクライアントが認証を使用するように設定されていない場合に発生する可能性があります。

6.異なるネットワークからの送信

電子メールサービスプロバイダによっては、SMTPリレーアクセスを自社のネットワークに接続しているユーザーだけに制限している。異なるネットワークを使用してメッセージをリレーしようとすると、SMTPサーバーはセキュリティのためにその活動をブロックすることがあります。 

リレーエラーの症状と影響を認識する

このようなリレーエラーは、メール送信に支障をきたすだけでなく、コミュニケーションやワークフローにも支障をきたします。ここでは、「550 5.7.367 Sender is Not Authorized for Relay」エラーの見分け方と、メールコミュニケーションへの影響について説明します。

リレーエラーの兆候

1.エラーコードを含むバウンスメールの増加

というようなメッセージとともに障害通知メールが届く：

• "550 5.7.1 中継できません"
• 「リレーアクセス拒否
• 「送信者はリレーを許可されていない

2.一貫性のないメッセージ配信

メールが特定の受信トレイに入らず、他のアドレスは正常に動作している場合、このエラーを予測することができます。このようなメールの選択的な失敗は、送信側と受信側のメールサーバー間に制限があることを示しています。 

3.受信はできても送信はできない 

メールを正常に受信しているのに送信できない、または以前は問題なく送信できていたのに突然送信できなくなった場合は、リレーの問題である可能性があります。 

4.スパムまたは未配信としてマークされるメール

不正確な SPF、DKIM、DMARCレコードが正しく設定されていない場合、メッセージがフラグを立てられたり拒否されたりする可能性があります。

ユーザーへの影響

リレーエラーは、重要な電子メールメッセージをブロックすることで、コミュニケーションに影響を与える可能性があります。重要なメールがユーザーの受信トレイに落ちるのを制限することで、ビジネスに影響を与える可能性があります。これらの問題がタイムリーに対処されない場合、メールシステムに影響を及ぼし、大きな損失をもたらします。以下に、このエラーの結果としてユーザーが直面する可能性のある問題をまとめます：

1. メールの直帰率の増加 
2. メール到達率の悪さ 
3. スパムメールの増加 

主な統計とユーザーへの影響例

• 2024年、スパムメールは約 47.27%を占め、前年から1.27ポイント増加した。
• 毎日のスパムメール推定 1,600億通のスパムメール2023年には、毎日送信される3,470億通のメールの46%を占める。
• 2024年、主要なメールマーケティングプラットフォームの平均メール到達率は以下の通りです。 83.1%で、ほぼ5通に1通が受信者の受信トレイに届かなかったことになります。
• 10％以上の 10％以上の電子メール送信されたメールの10％以上が購読者の迷惑メールフォルダに入り、適切な認証と送信者評価の重要性が浮き彫りになった。

550 5.7.367 Sender Not Authorized for Relay" エラーのトラブルシューティング

IT管理者であれ、ドメインを通してメールをリレーしようとしているユーザーであれ、「送信者がリレーの許可を得ていません」というエラーをなくすためにできることは以下の通りです：

IT管理者向け

このエラーに対処しようとするIT専門家は、次のような手順を踏むことができる：

1.メールサーバーの設定を確認する

まず、SMTPサーバーの設定を確認してください。設定が正しいことを確認してください。確認が必要な主な設定は、ポート番号、サーバーアドレス、更新された認証プロトコルなどである。変化するルールに従って、サーバー設定のチェックと更新を続けてください。

2.電子メール認証プロトコルの確認と更新

最新の電子メール認証プロトコルは、電子メール・リレー・システムが円滑に機能する上で大きな役割を果たします。リレーエラーを防ぐために不可欠な認証プロトコルは、DMARC、SPF、DKIMです。これらの認証プロトコルを適切に設定し、送信メールの認証を行いましょう。

3.ブロックリストとホワイトリストの検査

また、あなたのドメインがESPによってブラックリストに登録されていないかどうかを確認する必要があります。これはオンラインのDNSチェッカーツールで行うことができます。あなたのドメインがブロックされている場合は、ブロックリストから削除する措置を取ることができます。また、メールが届かないことを防ぐために、ユーザーのIPアドレスをホワイトリストに登録する必要があります。

4.SMTP設定とリレー許可のテスト

SMTPリレー許可の適切な設定を確認してください。認証されたユーザーまたはサーバーが簡単に電子メールをリレーできるように設定する必要があります。オンラインテストツールを使用して、電子メール送信を刺激する。

エンドユーザー向け

ユーザー側でも、このエラーによってメールでのコミュニケーションが台無しにならないよう、対策を講じることができます。以下は、このエラーを解決するための手順です：

1.問題の範囲を特定する

まず最初にすべきことは、エラーを特定することです。すべての受信者にメールを送信しているときにエラーが発生するのか、それとも特定の受信者だけにエラーが発生するのかを判断することによって、これを行うことができます。これにより、エラーの診断が容易になります。ユーザーは、エラーが自分のドメインで発生しているのか、受信者側で発生しているのかを理解することができます。エラーの中には、特定のメールアプリケーションやその設定に特有のものもあるため、さらに問題を切り分けるには、別のメールクライアントからメールを送信してみてください。

2.受取人とのコミュニケーション

特定のドメインにメールを送信した後にエラーが発生した場合は、受信者と連絡を取ってください。受信者の受信トレイがメールの受信を制限している可能性があります。受信者に、あなたのドメインまたはメールアドレスを信頼済みリストに追加するよう依頼してください。

3.エラーレポートをITチームに転送する

それぞれのエラーには特定の意味があり、ここで読むことができる："SMTPエラーコードの説明".エラーの背後にある原因を理解できない場合は、IT専門家と詳細を共有してください。詳細には、エラーメッセージ、タイムスタンプ、受信者のアドレスを含める必要があります。

将来のリレー問題を防ぐベストプラクティス

リレーの問題を一度解決しただけでは十分ではありません。再発防止策を講じる必要があります。SMTPログを定期的に監視し、強力な認証プロトコルを実装し、メールサーバーソフトウェアを最新の状態に保つ。さらに、適切な電子メールセキュリティの実践についてユーザーを教育し、メールクライアントを正しく設定して、不正なリレーの試みを防止します。

1.メールサーバーの設定を常に最新の状態に保つ

電子メールのコンフィギュレーション設定は、変化するトレンドやポリシーに沿ったものでなければならない。メールサーバーの設定をタイムリーに更新することで、設定ミスやエラーのリスクを減らすことができます。

2.認定されたSMTPサーバーのみを使用する

認証済みサーバーを使用して、リレーメールが受信者の受信箱に届く前に詐欺に遭わないようにしましょう。認証済みSMTPサーバーは、メール拒否のリスクを最小限に抑えます。SMTPリレーに安全な認証方法を使用するようにリモートサーバーを設定します。

3.認証プロトコルを正しく実装する

DMARC、SPF、およびDKIMプロトコルを使用して、進行中のメールを認証します。これらを正しく設定できるか不安な場合は DMARCソリューションを利用することができます！

問題が解決しない場合の対処法

いろいろ試しても問題が解決しない場合は？以下の対策を取ることができます：

1.ITチームへのエスカレーション

エラーを修正できない場合は、IT部門に問題を転送してください。DNS関連の設定を追跡して修正するように設計されたツールがいくつかあります。IT専門家はそのようなツールを使って問題を解決します。

2.受信者のメールサポートチームへの連絡

ドメインに問題がない場合もあります。このエラーは受信者側で発生する可能性があります。受信者に連絡し、メールサポートチームと協力して問題を特定してください。

3.サードパーティセキュリティサービスの検討

高度なフィルタリング、認証、監視機能を使って、しつこい問題を解決しましょう。また、本物のサードパーティ・サービスを利用することで、メールの配信性を高めることができます。 

巻末資料 

エラー "550 5.7.367 Sender Not Authorized for Relay "は、よくあるメールリレーエラーのひとつです。この問題は解決可能であり、本質的な対策で防ぐことができます。電子メール認証プロトコルを効率的に維持し、サーバー設定を見直し、電子メールリレーエラーを認識し修正するツールを使用することで、信頼性の高い電子メール通信を確保することができます。

• について
• 最新記事

Ahona Rudra

ドメインとメールセキュリティのエキスパートPowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

• DMARC MSP 事例紹介：The Great Geek、PowerDMARCを活用して中小企業向けメールセキュリティサービスを拡充 - 2026年6月25日
• 「メールなりすましサービス（Spoofing-as-a-Service）」の仕組みと対策 - 2026年6月24日
• フィッシングの偵察：攻撃者が脆弱なドメインを特定し、標的とする方法 - 2026年6月24日