DMARC を使用してメールを検証する
ヒント
Microsoft 365 Defender for Office 365 プラン 2 の機能を無料で試すことができることをご存知でしたか? Microsoft Defender ポータル試用版ハブで 90 日間のDefender for Office 365試用版を使用します。 こちらからサインアップできるユーザーと試用版の使用条件の詳細について参照してください。
Domain-based Message Authentication, Reporting, and Conformance (DMARC) は、Sender Policy Framework (SPF) および DomainKeys Identified Mail (DKIM) と併用することで、メールの送信者を認証できるようになります。
DMARC は、お客様のドメインから送信されたメッセージを、送信先のメール システムが信頼できるようにするものです。 SPF および DKIM と共に DMARC を使用すると、組織ではメールのスプーフィングやフィッシングに対抗する保護を強化できます。 DMARC は、電子メールを受信するシステムが、ドメインからの SPF チェックまたは DKIM チェックに失敗したメッセージに対して、どのように対応するかを判断する際に役に立ちます。
ヒント
Microsoft 365 用の DMARC レポートを提供しているサードパーティ ベンダーを確認するには、「Microsoft Intelligent Security Association (MISA)」(Microsoft インテリジェント セキュリティ アソシエーション) カタログを参照してください。
ヒント
私たちのステップバイステップガイドを見たことがありますか? 構成 1-2-3s と、急いで管理者のためのフリルなし。 Microsoft Online Email ルーティング アドレス (MOERA) とパークされたドメインの DMARC レポートを有効にする手順に関するページを参照してください。
SPF と DMARC が連携して Microsoft 365 の電子メールを保護するしくみ
メール メッセージには、複数の発信者や送信者のアドレスが含まれている場合があります。 これらのアドレスは、さまざまな目的に使用できます。 たとえば、次のアドレスについて考えてみましょう。
「Mail From」アドレス: 送信者を識別し、メッセージの配信に問題が発生した場合に、配信不能通知などの通知の返送先を伝達します。 メールの差出人のアドレス は、メール メッセージの封筒部分に表示され、メール アプリケーションでは表示されません。5321.MailFrom アドレスまたは逆方向パス アドレスとも呼ばれます。
「From」アドレス: From アドレスとして、ユーザーの電子メール アプリケーションに表示されるアドレス。 差出人アドレスにより、電子メールの作成者を識別します。 つまり、メッセージを書いた個人またはシステムのメールボックスになります。 差出人アドレスは、5322.From アドレスともいいます。
SPF は、特定のドメインに対する認証済みの送信側 IP アドレスのリストに DNS TXT レコードを使用します。 通常、SPF チェックは 5321.MailFrom アドレスに対してのみ実行されます。 SPF を単独で使用する場合、5322.From アドレスは認証されないため、ユーザーが SPF チェックに合格したが、送信者アドレスから 5322 というスプーフィングされたメッセージを受け取るシナリオが可能になります。 たとえば、次のような SMTP トランスクリプトを考えてみます。
S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .
このトランスクリプトでは、送信者のアドレスは次にようになります。
アドレスからのメール (5321.MailFrom): phish@phishing.contoso.com
From アドレス (5322.From): security@woodgrovebank.com
SPF を構成した場合、受信サーバーは アドレスからのメールに対してチェックを実行しますphish@phishing.contoso.com。 メッセージがドメイン phishing.contoso.com の有効なソースから送信された場合は、SPF チェックをパスします。 電子メール クライアントには From アドレスのみが表示されるため、このメッセージは から security@woodgrovebank.com送信されたとユーザーに表示されます。 SPF だけでは、woodgrovebank.com の有効性は認証されません。
DMARC を使用すると、From アドレスに対するチェックを受信側サーバーも実行するようになります。 前述の例では、woodgrovebank.com の所定の場所に DMARC TXT レコードが存在していれば、From アドレスに対するチェックは失敗します。
DMARC TXT レコードとは
SPF の DNS レコードと同様に、DMARC のレコードは、スプーフィングとフィッシングの防止に役立つ DNS テキスト (TXT) レコードです。 DMARC TXT レコードは DNS で発行します。 DMARC TXT レコードは、メール作成者の IP アドレスを、送信側ドメインの所有者とされる名前と照合して、メール メッセージの発信元を確認します。 この DMARC TXT レコードにより、承認済みの送信メール サーバーを識別します。 送信先メール システムでは、メッセージが承認済みの送信メール サーバーから発信されたことを確認できます。
Microsoft の DMARC TXT レコードは、次のような内容になります。
_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"
Microsoft 365 用の DMARC レポートを提供している他のサードパーティ ベンダーについては、MISA カタログを参照してください。
受信メール用に DMARC の設定
Microsoft 365 で受信するメールの DMARC を設定するために必要な手順はありません。 それはすべて考慮されています。 DMARC チェックをパスしないメールに対する処理について知る必要がある場合は、「Microsoft 365 が DMARC に失敗した受信メールを処理する方法」を参照してください。
Microsoft 365 からの送信メール用に DMARC を設定する
Microsoft 365 を使用しているもののカスタム ドメインを使用していない場合 (つまり、onmicrosoft.com を使用する場合)、SPF のセットアップは既に完了しており、Microsoft 365 により自動的に送信メールに DKIM 署名が生成されます。この署名の詳細については「DKIM と Microsoft 365 の既定の動作」をご覧ください。 organizationに DMARC を設定するには、onmicrosoft.com ドメインの DMARC TXT レコードを作成し、Office 365 Admin センター>設定>ドメイン>を使用して DNS に発行 onmicrosoft.com ドメイン>の [レコードの追加] をクリックする必要があります。
カスタム ドメインを所有している場合や、Microsoft 365 と合わせてオンプレミスの Exchange サーバーも使用している場合は、送信メール用に手動で DMARC を設定する必要があります。 カスタム ドメイン用に DMARC を設定する手順は次のとおりです。
手順 1:ドメインに対する有効なメールのソースを特定する
既に SPF のセットアップが済んでいる場合は、この演習を完了していることになります。 DMARC には、さらにいくつかの考慮事項があります。 ドメインに対するメールのソースを特定するときには、以下の 2 つの問いに答える必要があります。
どの IP アドレスにドメインからメッセージを送信するか。
自分の代わりにサード パーティから送信されるメールについて、5321.MailFrom ドメインと 5322.From ドメインが一致しているか。
手順 2: ドメイン用に SPF をセットアップする
すべての有効な送信者の一覧が用意できると、「SPF を設定して、スプーフィングを防止する」手順を実行できるようになります。
たとえば、contoso.com が Exchange Online からメールを送信するとします。このとき、オンプレミスの Exchange サーバーの IP アドレスが 192.168.0.1、Web アプリケーションの IP アドレスが 192.168.100.100 だと仮定すると、SPF TXT テキストレコードは次のようになります。
contoso.com IN TXT " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"
ベスト プラクティスとして、SPF TXT レコードでは、サード パーティの送信者についても考慮に入れておく必要があります。
手順 3: カスタム ドメイン用に DKIM をセットアップする
SPF のセットアップ後には、DKIM をセットアップする必要があります。 DKIM では、電子メール メッセージのメッセージ ヘッダー内にデジタル署名を追加することができます。 DKIM をセットアップする代わりに、ドメインに対して Microsoft 365 で既定の DKIM 構成の使用を許可すると、DMARC が失敗することがあります。 このエラーは、既定の DKIM 構成が、5321.MailFrom アドレスとしてカスタム ドメインではなく初期設定の onmicrosoft.com ドメインを使用するために発生する可能性があります。 これにより、ドメインから送信されたすべてのメールの 5321.MailFrom アドレスと 5322.From アドレスとの間に不一致が生じることになります。
メールを代理で送信するサード パーティの送信者が存在しているときに、そのサード パーティが送信するメールの 5321.MailFrom アドレスと 5322.From アドレスが一致していないと、そのメールに対する DMARC は失敗します。 これを回避するには、そのサード パーティの送信者について、具体的にドメインの DKIM をセットアップする必要があります。 これにより、このサード パーティのサービスからのメールを Microsoft 365 で認証できるようになります。 ただし、そのようにすると、サード パーティが送信したメールを本人が送信したメールであるかのように検証することを他者 (Yahoo、Gmail、Comcast など) にも許可するようになります。 これには、顧客がどこにメールボックスを配置していてもドメインとの信頼を構築できるようになるという利点があります。それと同時に、メッセージはドメインの認証チェックをパスしているため、Microsoft 365 は偽装を理由にメッセージをスパムとしてマークしなくなります。
サード パーティの送信者がドメインを偽装できるように DKIM をセットアップする方法を含め、ドメインの DKIM をセットアップする手順については、「DKIM を使用して、カスタム ドメインから送信される送信電子メールを検証する」を参照してください。
手順 4: ドメイン用の DMARC TXT レコードを作成する
ここでは、Microsoft 365 で最もよく使用される構文オプションを示します。ただし、ここに記載されていない別の構文のオプションもあります。 ドメイン用の DMARC TXT レコードは、次に示す形式で作成します。
_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100"
ここで、
domain は、保護対象にするドメインです。 既定では、このレコードは、ドメインとすべてのサブドメインからのメールを保護します。 たとえば、_dmarc.contoso.com を指定すると、DMARC は、このドメインとすべてのサブドメイン (housewares.contoso.com や plumbing.contoso.com など) からのメールを保護します。
TTL は、常に 1 時間に相当する必要があります。 TTL に使用される単位は、ドメインのレジストラーに応じて hours (1 時間)、minutes (60 分)、または seconds (3,600 秒) のいずれかになります。
pct=100 は、このルールがメールの 100% に使用される必要があることを示します。
policy では、DMARC に失敗した場合に受信側サーバーが従う必要のあるポリシーを指定します。 ポリシーは、なし (none)、検疫 (quarantine)、または拒否 (reject) に設定できます。
どのオプションを使用するかについては、「Microsoft 365 で DMARC を実装する際のベスト プラクティス」の概念をよく理解してください。
例:
ポリシーをなし (none) に設定する
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none"ポリシーを検疫 (quarantine) に設定する
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=quarantine"ポリシーを拒否 (reject) に設定する
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=reject"
レコードの作成後には、ドメイン レジストラーでレコードを更新する必要があります。
DMARC メール
注意
メールは毎日送信されない場合があります。
この例の DMARC TXT レコード: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1"では、 rua アドレスを確認できます。 このアドレスは、分析のために "集計フィードバック" を送信するために使用されます。これは、レポートの生成に使用されます。
ヒント
Microsoft 365 用の DMARC レポートを提供している他のサードパーティ ベンダーを確認するには、MISA カタログを参照してください。 DMARC 'rua' アドレスの詳細については、「IETF.org の 'ドメインベースのメッセージ認証、レポート、適合 (DMARC)'」を参照してください。
Microsoft 365 で DMARC を実装する際のベスト プラクティス
メール フローの残りの部分に影響を与えることなく、DMARC を段階的に実装できます。 次の手順に従って、ロールアウト 計画を作成して実装します。 次の手順に進む前に、最初にサブドメイン、その他のサブドメイン、最後にorganizationの最上位ドメインで各手順を実行します。
DMARC の実装による影響を監視する
まず、サブドメインまたはドメインに単純な監視モード レコードを使用することから始めます。このレコードでは、そのドメインを使用して確認するメッセージについての統計を送信するように DMARC レシーバーに要求します。 監視モード レコードとは、ポリシーをなし (p=none) に設定したDMARC TXT レコードのことです。 多くの企業は、p=none の DMARC TXT レコードを発行しています。それより制限の厳しいポリシーを発行することで、どれだけのメールが失われるかについて、明確にはわからないためです。
これは、メッセージング インフラストラクチャに SPF や DKIM を実装する前でも実行できます。 ただし、SPF と DKIM を実装して併用するまでは、DMARC を使用した効果的なメールの検疫や拒否はできません。 SPF と DKIM を導入すると、DMARC によって生成されるレポートには、それらのチェックをパスしなかったメッセージに対してパスしたメッセージの発信元と数が示されます。 それらのチェックの適用対象になる (または適用対象にならない) 正当なトラフィックの量を簡単に確認できます。また、あらゆる問題のトラブルシューティングも簡単になります。 さらに、どれだけの偽装メッセージが送信されているかや、偽装メッセージの送信元についても、次第にわかるようになります。
DMARC に失敗したメールの検疫を外部のメール システムに要求する
すべて、または大部分の正当なトラフィックが SPF と DKIM で保護されるという確信が持てるようになり、DMARC の実装による影響を理解したら、検疫ポリシーを実装してください。 検疫ポリシーとは、ポリシーを検疫 (p=quarantine) に設定した DMARC TXT レコードのことです。 このようにすることで、DMARC レシーバーに対して、DMARC に失敗したドメインからのメッセージを顧客の受信トレイではなく、ローカルのスパム フォルダーと同等のフォルダーに入れるように指示します。
DMARC に失敗したメッセージを受け取らないように外部システムに要求する
最後の手順は、拒否ポリシーの実装です。 拒否ポリシーとは、ポリシーを拒否 (p=reject) に設定した DMARC TXT レコードのことです。 これにより、DMARC レシーバーに対して、DMARC チェックに失敗したメッセージを受け取らないように指示します。
サブドメイン用に DMARC を設定する方法
DMARC は、DNS で TXT レコードとしてポリシーを発行することによって実装され、階層構造になっています (たとえば、サブドメインに対して別のポリシーが明示的に定義されていない限り、contoso.com に発行されたポリシーが sub.domain.contoso.com に適用されます)。 これは、より広い範囲をカバーするために、より少ない数の高レベル DMARC レコードを指定できる場合があるため、便利です。 サブドメインがトップ レベル ドメインの DMARC レコードを継承しないようにするには、明示的なサブドメイン DMARC レコードを構成するように注意する必要があります。
また、
sp=reject値を追加することにより、サブドメインがメールを送信してはならないときに DMARC にワイルドカード タイプのポリシーを追加できます。 例:_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
DMARC 拒否
DMARC p=reject は、DMARC に失敗したメールを 拒否 するようにサービス プロバイダーに通知するために、ドメイン所有者によって DMARC TXT レコードに設定されるポリシーです。
これは、OReject が既定として設定されている場合、拒否されたメールが Enterprise の検疫とコンシューマーの迷惑メール Email フォルダーに送信されたためです (コンシューマーの検疫がないため)。 ただし、DMARC p=rejectでは、電子メールは拒否されます。
構成は、Microsoft Defender ポータル、または PowerShell の New-AntiPhishPolicy コマンドレットまたは Set-AntiPhishPolicy コマンドレットExchange Online使用して実行できます。 詳細については、次の記事を参照してください。
- なりすまし保護と送信者 DMARC ポリシー
- EOP でのスパム対策ポリシーの構成
- 詳細については、「Microsoft Defender for Office 365 のフィッシング対策ポリシーを構成する」を参照してください。
Microsoft 365 が DMARC に失敗した送信メールを処理する方法
メッセージが Microsoft 365 から送信され、DMARC に失敗し、ポリシーを p=quarantine または p=reject に設定していると、メッセージは「送信メッセージにおける危険度の高い配信プール」によってルーティングされます。 送信メールの上書きはありません。
DMARC 拒否ポリシー (p=reject) を発行すると、どの顧客も Microsoft 365 ではドメインを偽装できなくなります。メッセージは、サービスを通じたメッセージ送信の中継時に、ドメインの SPF または DKIM をパスできないためです。 ただし、DMARC 拒否ポリシーを発行していても、すべてのメールが Microsoft 365 で認証されている場合、前述の説明どおりに受信メールの一部はスパムとしてのマークが付けられます。それ以外のメールは、SPF を発行していない場合に、サービスを通じて送信を中継しようとすると拒否されます。 これは、DMARC TXT レコードの作成時に、ドメインの代理としてメールを送信するサーバーの一部の IP アドレスとアプリを含め忘れている場合などに発生します。
Microsoft 365 が DMARC に失敗した受信メールを処理する方法
送信側ドメインの DMARC ポリシーが である場合、p=rejectExchange Online Protection (EOP) は既定でメッセージを拒否します。 送信者 DMARC ポリシーで、および を受け入れるか、または受け入p=quarantinep=rejectれないようにフィッシング対策ポリシーを構成し、 と に対して個別のアクションをp=quarantinep=reject指定できます。 詳細については、「 なりすまし保護と送信者 DMARC ポリシー」を参照してください。
フィッシング対策ポリシーが DMARC ポリシーを受け入p=quarantinep=rejectれないように構成されている場合、DMARC に失敗したメッセージはスパムとしてマークされ、拒否されません。 ユーザーは、次の方法で受信トレイにこれらのメッセージを引き続き取得できます。
- ユーザーが、自分のメール クライアントを使用して、個別に安全な送信者を追加します。
- 管理者は、スプーフィング インテリジェンス分析やテナントの許可/ブロック リストを使用して、なりすまし送信者からのメッセージを許可できます。
- 管理者が、該当する送信者のメッセージを許可するすべてのユーザーに向けて Exchange メール フロー ルール (トランスポート ルールとも呼ばれる) を作成します。
- 管理者は、organizationの DMARC ポリシーに失敗した拒否されたメールに対して、すべてのユーザーに対して Exchange メール フロー ルールを作成します。
詳細については、「信頼できる差出人リストの作成」を参照してください。
Microsoft 365 でオーセンティケーテッド レシーブド チェーン (ARC) を活用する方法
Microsoft 365 でホストされているすべてのメール ボックスでは、向上したメッセージの配信率と強化されたスプーフィング対策保護と共に、ARC の利点が得られます。 ARC では、元のサーバーから受信者のメールボックスへと電子メールがルーティングされると、すべての関与する仲介役、つまりホップからの電子メール認証の結果が保持されます。 ARC 以前、転送ルールまたは自動署名などの電子メール ルーティングの仲介役によって実行される変更は、受信者のメールボックスで電子メールが受信される時間によって DMARC の失敗を引き起こす場合があります。 ARC を使用すると、認証の結果の暗号化保存により、Microsoft 365 では電子メールの送信者の真正性を検証することができます。
Microsoft が ARC Sealer の場合、現在、Microsoft 365 では ARC を使用して認証の結果を検証します。しかし、将来的にはサードパーティの ARC Sealer のサポートを追加する予定です。
DMARC 実装のトラブルシューティング
ドメインの MX レコードを構成したときに、最初のエントリを EOP 以外にすると、DMARC の失敗はドメインに強制されなくなります。
お客様の場合でも、ドメインのプライマリ MX レコードが EOP を指していないと、DMARC による利点は得られなくなります。 たとえば、MX レコードがオンプレミスのメール サーバーを指していて、コネクタを使用することで EOP にメールをルーティングしていると、DMARC は機能しなくなります。 このシナリオでは、受信側ドメインは認証済みドメインのいずれかになりますが、EOP はプライマリ MX ではありません。 たとえば、contoso.com がそれ自体の MX をポイントしていて、セカンダリ MX レコードとして EOP を使用しているとすると、contoso.com の MX レコードは次のようになります。
contoso.com 3600 IN MX 0 mail.contoso.com
contoso.com 3600 IN MX 10 contoso-com.mail.protection.outlook.com
すべて、またはほとんどのメールは、最初にプライマリ MX である mail.contoso.com にルーティングされてから、EOP にルーティングされます。 場合によっては、MX レコードとして EOP をリストすることさえなく、単にメールをルーティングするようにコネクタを接続していることもあります。 EOP は、DMARC 検証を行うための最初のエントリである必要はありません。 オンプレミスまたは O365 以外のすべてのサーバーが DMARC チェックを実行することを確認するために、検証だけを行います。 DMARC TXT レコードを設定するときに顧客のドメイン (サーバーではなく) に対して DMARC を強制できますが、実際に強制するのは受信サーバーだけです。 EOP を受信サーバーとして設定すると、EOP は DMARC 強制を行います。
詳細情報
DMARC の詳細情報が必要ですか。 以下のリソースが役に立ちます。
スパム対策メッセージ ヘッダーには、Microsoft 365 が DMARC チェックに使用する構文とヘッダー フィールドが含まれています。
M3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group) の「DMARC TRAINING SERIES」。
dmarcian のチェックリストを使用する。
DMARC.org のソースに直接アクセスする。
関連項目
Microsoft 365 において Sender Policy Framework (SPF) を使用して、スプーフィングを防止する方法
Microsoft 365 で SPF を設定して、スプーフィングを防止する