SPF を設定して、スプーフィングを防止する

ヒント

Microsoft 365 Defender for Office 365 プラン 2 の機能を無料で試すことができることをご存知でしたか? Microsoft Defender ポータル試用版ハブで 90 日間のDefender for Office 365試用版を使用します。 こちらからサインアップできるユーザーと試用版の使用条件の詳細について参照してください。

この記事では、ドメイン ネーム サービス (DNS) レコードを更新して、Office 365のカスタム ドメインで Sender Policy Framework (SPF) 電子メール認証を使用できるようにする方法について説明します。

SPF は、カスタム ドメイン(実際の送信元) から来た送信メールを検証するのに役立ちます。 これは、全体的に推奨している SPF、 DKIM、DMARC 認証において電子メール認証方法を設定する最初の手順です。

前提条件

重要

小規模企業の場合、または IP アドレスや DNS 構成に慣れていない場合は、インターネット ドメイン レジストラー (GoDaddy、Bluehost、web.com など) に電話して、SPF (およびその他の電子メール認証方法) &の DNS 構成に関するヘルプを求めます。

カスタム URL を使用していない場合 (Office 365 に使用されている URL が onmicrosoft.com で終わっている場合) は、Office 365 サービスで SPF が既に設定されています。

では、始めましょう。

Office 365 の SPF TXT レコードは、カスタム ドメインまたはサブドメインの外部の DNS で作成されます。 レコードを作成するには、いくつかの情報が必要です。 次の情報を収集します。

  • カスタム ドメインの SPF TXT レコード (存在する場合)。 手順に関しては、「Office 365 の DNS レコードの作成に必要な情報を収集する」をご覧ください。

  • メッセージング サーバーに移動して、(すべてのオンプレミス メッセージング サーバーからの必要な) 外部 IP アドレスを発見します。 たとえば、131.107.2.200 などです。

  • SPF TXT レコードに含める必要があるサードパーティ製のすべてのドメインに使用するドメイン名。 一部のバルク メール プロバイダーは、顧客用のサブドメインを設定しています。 たとえば、会社 MailChimp に servers.mcsv.net を設定するなどです。

  • SPF TXT レコードで使う強制ルールを決定します。 -all ルールが推奨されます。 その他の構文オプションの詳細については、「 Microsoft 365 の SPF TXT レコード構文」を参照してください。

重要

カスタム ドメインを使用するには、Office 365 では、Sender Policy Framework (SPF) TXT レコードを DNS レコードに追加してスプーフィングを防止する必要があります。

SPF TXT レコードを作成または更新する

  1. 以下の表の SFP 構文について、十分に理解しておいてください。

    要素 もし今使っているとしたら... お客様に共通のことでは? 追加対象
    1 いずれかの電子メール システム (必須) 共通。 この値で始まるすべての SPF レコード v=spf1
    2 Exchange Online 共通 include:spf.protection.outlook.com
    3 Exchange Online 専用のみ 共通ではない ip4:23.103.224.0/19
    ip4:206.191.224.0/19
    ip4:40.103.0.0/16
    include:spf.protection.outlook.com
    4 Office 365 Germany、Microsoft Cloud Germany のみ 共通ではない include:spf.protection.outlook.de
    5 サード パーティ製の電子メール システム 共通ではない include:<domain_name>

    <> domain_nameは、サード パーティの電子メール システムのドメインです。
    6 オンプレミスの電子メール システム。 たとえば、Exchange Online Protectionと別の電子メール システムなどです。 共通ではない 各追加メール システムで次のいずれかを使用します。

    ip4:<IP_address>
    ip6:<IP_address>
    include:<domain_name>

    <> IP_addressと<domain_name>は、ドメインに代わってメールを送信する他のメール システムの IP アドレスとドメインです。
    7 いずれかの電子メール システム (必須) 共通。 この値で終わるすべての SPF レコード <enforcement rule>

    これは、いくつかの値のどれか 1 つかもしれません。 値 -all をお勧めします。

  2. まだ行っていない場合は、表の構文を使用して SPF TXT レコードを作成します。

    たとえば、Office 365 で完全にホストされている場合、つまり、オンプレミスのメール サーバーを使っていない場合は、SPF TXT レコードには、次のように 1 行目、2 行目、7 行目が含まれます。

    v=spf1 include:spf.protection.outlook.com -all

    上記は、SPF TXT レコード の最も一般的な例です。 このレコードは、Microsoft データセンターが米国、ヨーロッパ (ドイツを含む)、または他の場所にあっても、ほぼすべてのユーザーに対して機能します。

    ただし、Microsoft Cloud Germany の一部であるドイツOffice 365購入した場合は、2 行目ではなく 4 行目の include ステートメントを使用する必要があります。 たとえば、ドイツOffice 365で完全にホストされている場合、つまり、オンプレミスのメール サーバーがない場合、SPF TXT レコードには行 1、4、7 が含まれており、次のようになります。

    v=spf1 include:spf.protection.outlook.de -all

    Office 365 で既に展開し、カスタム ドメインの SPF TXT レコードをセットアップしている状態で Office 365 Germany に移行する場合は、SPF TXT レコードを更新する必要があります。 これを行うには、include:spf.protection.outlook.com をinclude:spf.protection.outlook.deに変更します。

  3. SPF TXT レコードを構成した後、DNS でレコードを更新する必要があります。 ドメインに配置できる SPF TXT レコードは 1 つのみです。 SPF TXT レコードが存在する場合、新しいレコードを追加するのではなく、既存のレコードを更新しなければなりません。 「Office 365 の DNS レコードを作成する」に移動し、DNS ホストのリンクをクリックします。

  4. SPF TXT レコードをテストします。

サブドメインの処理方法とは?

サブドメインは、上位ドメインの SPF レコードを継承しないので、サブドメインごとに、別々のレコードを作成する必要があることに注意してください。

存在しないサブドメインからのメールを、攻撃者が送信することを防ぐために、すべてのドメインとサブドメインに対して追加のワイルドカード SPF レコード (*.) が必要です。 例:

*.subdomain.contoso.com. IN TXT "v=spf1 -all"

SPF のトラブルシューティング

SPF TXT レコードで問題が発生していますか? 「トラブルシューティング: Microsoft 365 の SPF のベスト プラクティス」を参照してください。

SPF メール認証は、実際に何を行いますか?

SPF は、ユーザーのためにメールを送信できるメール サーバーを識別します。 基本的には、SPF を DKIM、DMARC、その他の Office 365 でサポートされているテクノロジと併用することによって、スプーフィングとフィッシング詐欺を防止できます。 SPF は TXT レコードとして追加され、DNS はこのレコードを使って、カスタム ドメインの代わりにメールを送信できるメール サーバーを識別します。 受信側のメール システムは、この SPF TXT レコードを参照して、カスタム ドメインからのメッセージが、承認されたメッセージング サーバーからのものであるかどうかを判別します。

たとえば、カスタム ドメイン contoso.com が Office 365 を使用しているとします。 ユーザーのドメインの正当なメール サーバーとして Office 365 メッセージング サーバーを一覧表示する SPF TXT レコードを追加します。 受信側のメッセージング サーバーが joe@contoso.comからメッセージを取得すると、サーバーは contoso.com のSPF TXT レコードを検索し、メッセージが有効かどうかを調べます。 受信サーバーで、SPF レコードに一覧表示されている Office 365 メッセージング サーバー以外のサーバーからメッセージを取得していることが検出された場合、受信メール サーバーはそのメッセージを迷惑メールとして拒否できます。

また、カスタム ドメインに SPF TXT レコードが含まれていないと、一部の受信サーバーはメッセージを完全に拒否することがあります。 これは、受信サーバーが、承認されたメッセージング サーバーからのメッセージであることを検証できないためです。

既に Office 365 のメールを設定している場合、SPF TXT レコードとして Microsoft のメッセージング サーバーが DNS に含まれています。 ただし、場合によっては DNS で SPF TXT レコードを更新する必要があります。 たとえば、次のような場合です。

  • 以前は、SharePoint Online を使用している場合、カスタム ドメインに別の SPF TXT レコードを追加する必要がありました。 この作業を行う必要はなくなりました。 この変更により、SharePoint Online の通知メッセージが [迷惑メール] フォルダーに振り分けられるリスクが軽減されます。 参照の制限数である 10 に達し、"参照制限を超えました"、"ホップが多すぎます" などのメッセージを示すエラーが表示される場合は、SPF TXT レコードを更新します。

  • Office 365 とオンプレミスの Exchange を使用したハイブリッド環境の場合。

  • DKIM と DMARC をセットアップする場合 (推奨)。

SPF の詳細情報

高度な例については、サポートされている SPF 構文、スプーフィング、トラブルシューティング、および SPF をサポートOffice 365方法の詳細な説明については、「MICROSOFT 365 でのスプーフィングとフィッシングを防ぐための SPF のしくみ」を参照してください。

次の手順: DKIM と DMARC

SPF はスプーフィングの防止に役立ちますが、SPF では保護できないスプーフィング テクニックがあります。 それらから保護するには、SPF のセットアップ後に、DKIM と DMARC を Office 365 用に構成する必要があります。

DKIM メール認証の目標は、メールの内容が改ざんされていないと証明することです。

DMARC メール認証の目標は、SPF と DKIM の情報が From アドレスと確実に一致していることを確認することです。

サポートされている SPF 構文の高度な例や詳細については、「Office 365 において SPF がスプーフィングとフィッシングを防ぐしくみ」をご覧ください。

信頼できる ARC シーラーを構成する

このドキュメントに関してフィードバックがある場合は、[フィードバック] の下にある [このページ] を選択してください。