メールの「差出人アドレス(From)」を見ています。自由に設定することができます。フィッシング行為が行われるケースがあります。なりすまされた企業やブランドにも大きな被害が発生することが考えられます。送信ドメイン認証の導入を進めてきました。送信ドメイン認証とは、DNSを利用して、ドメイン所有者が許可した者が送信したメールであるかを検証する技術です。2つが運用されています。送信ドメイン認証により、なりすましを判断することが技術的には可能になりました。メール送信者とメール受信者の間で取り決める仕組みが必要でした。なりすましと判断したメールをどのように取り扱うべきかをメール送信者が宣言し、メール受信者がそれを実行する仕組みを提供します。送信ドメイン認証の結果やなりすましメールの発生をメール受信者がメール送信者に対してレポートする仕組みを提供します。実装は世界中に存在するメールサーバーを保有する企業や組織が行わなければなりません。前述した通り、メール送信者とメール受信者に役割があるため、それぞれが実装を進める必要があります。自らのドメインで運用している企業または組織。オンプレミスのメールサーバーだけではなく、メール配信サービスを利用している場合もメール送信者となります。メール受信者メールボックスを運用している企業または組織。企業向けに関わらず少数のプロバイダが膨大な数のメールボックスを提供・運用する状況になりつつあります。電子メールの技術実装では「鶏が先か、卵が先か」問題がたびたび起こります。メール送信者とメール受信者のどちらかで実装が進まないと、仕様としては存在するが実際は動作しないという状況に陥ります。メール受信者の実装が大変ではないかと思います。対応して普及を進めています。なりすましメールへの対策に一定の効果があるのではないかと思います。DMARCを導入するさてここからは、メール送信者のお話です。運用を開始することができます。なりすましを防ぐ仕組みですが、実は電子メールには2つのFromが存在します。送信ドメイン認証やDMARCを正しく理解するために、まずはこの2つのFromについて説明します。いう通信プロトコル使って送受信されます。FROM」コマンドを使って送信サーバーは受信サーバーに「差出人アドレス」を送信します。このアドレスはメールの配送エラーを伝える「バウンスメール」と呼ばれるメールを受信します。これが1つめのFromです。続いて、「DATA」コマンドを使ってメールデータを送信します。メールデータは、ヘッダとボディ(本文)で構成されます。ヘッダの中には皆さんが目にする「差出人アドレス」が含まれます。これが2つめのFromです。いう2つの送信ドメイン認証を使用します。DMARCでの送信ドメイン認証の使い方を詳しく見ていきましょう。ドメインを認証します(*1)。ドメインを管理するDNSに公開します。これをSPFレコードと呼びます。メール受信者は、メールの送信元IPアドレスとSPFレコードを使用してドメインを認証します。メールサーバー間で渡される差出人アドレスなので、メールの利用者が意識して設定するものではありません。同じメールアドレスになります。サービス事業者のドメインであることが多いのではないかと思います。サービス事業者は利用者の代わりにメールの配送を行っており、その状況を把握するためにバウンスメールを受信する必要があるからです。対応していれば、メールの到達性などへの影響はありません。よる送信ドメイン認証を行うことを要求しています。対応することができます。設定する方法については以下ページを参照ください。CloudSPFの詳細については以下ページを参照ください。迷惑メール対策委員会SPFレコードの設定例を見てみましょう。以下のように設定をしています。対してなりすましを防ぎたかったのではないかと考えます。設定が必要になります。ドメインを認証します。ドメインを管理するDNSに公開します。これをDKIMレコードと呼びます。メール受信者は、電子署名とDKIMレコードを使用してドメインを認証します。ヘッダに電子署名を付与します。dタグという部分に送信ドメインを記述します。ドメインと同じではありません。同じドメインで作成された署名を「作成者署名」と呼びます。送信ドメイン認証を行うことを要求しています。DKIMに対応している場合でもメール配信サービスのドメインで署名されている場合は第三者署名になります。運用できるかを確認する必要があります。「作成者署名」に対応しています。実際に、どのようなメールヘッダが付与されるのか、例を見てみましょう。送信ドメイン(dタグ)が一致しているので「作成者署名」であることがわかります。DKIMに対応するには、電子署名を付与することができるメールサーバーが必要です。対応することができます。設定する方法については以下ページを参照ください。CloudDKIMの詳細については以下ページを参照ください。ドメイン設計には少し注意が必要です。以下のケースを考えてみましょう。メールを運用しています。してニュースレターを配信します。ニュースレターの配信にはメール配信サービスを利用します。会社のメールサーバーに戻ってきてしまいます。これではメール配信サービスが配送エラーを正しく管理することができません。バウンスメールをルーティングすれば、、、ちょっとまってください。これは絶対にやってはいけません。社員のアカウントで受信しているメールも全て、メール配信サービスに届くことになってしまいます。バウンスメールのルーティングを分離することが重要です。して運用することは許可しています。対応することができます。バウンスメールを受信する設定については以下ページを参照ください。Cloud送信ドメイン認証の結果を確認するここまでの作業で送信ドメイン認証を設定し、バウンスメールをメール配信サービスに返すことができました。次に、あなたが設定した送信ドメイン認証がメール受信者に正しく認証されているかを確認します。ヘッダを参照する方法です。メールヘッダを確認するには、以下の操作を行います。メールヘッダを確認したいメールを開きます。「メッセージのソースを表示」メニューをクリックします。別ウインドウでメッセージのソースコードが表示されます。ヘッダを探してください。以下の4か所を確認します。smtp.mailfrom=no-reply@smtps.jp;dkim=passDKIMの認証結果。設定に問題があります。(*2)である必要があります。spf=passSPFの認証結果。設定に問題があります。Envelope-From。サブドメインである必要があります。パラメータを使い、サブドメインの範囲で調整することはできます。レコードを公開します。