Microsoft 365でのDMARC設定：日本企業のための実務ガイド

Microsoft 365は自社のインフラを通じてメールを送信するため、ドメインのSPFレコードでこれを許可する必要がございます。通常はMicrosoft 365のSPF includeを用います。多くのプロジェクトが見落とすのがDKIMです。Microsoft 365は既定では共有のonmicrosoft.comドメインで署名しており、これは自社ドメインにアライメントいたしません。そのため、Microsoft管理センターで自社のカスタムドメインに対してDKIMを有効化し、提示される2つのCNAMEレコードを公開する必要がございます。DMARCで有効となるのはアライメントの取れたSPFまたはDKIMのみですので、カスタムドメインでのDKIM有効化は、確実に認証を通過させたいのであれば省略できない手順です。

SPFとDKIMを整えたら、まずp=noneでDMARCレコードをDNSに公開し、集約レポートが返ってくるようレポート送信先を設定いたします。そしてそのレポートを読み込みます。Microsoft 365からのメールは認証を通過するはずですが、レポートは同時に、自社ドメインとして送信している他のすべてのサービス、すなわちマーケティングプラットフォーム、ヘルプデスクツール、人事・会計システム、そして国内向けのSaaSまでを明らかにいたします。この棚卸しこそがプロジェクトの実質であり、その規模は担当チームの想定を上回ることがほとんどです。

SPFは1回のチェックにつきDNSルックアップを10回までしか許容いたしません。Microsoft 365単体であれば問題ございませんが、それぞれ独自のSPF includeを持つ複数のSaaS送信元を加えていくと、レコードは静かにこの上限を超えてしまいます。上限を超えると、SPFは恒久的なエラーを返し、正規のメールが認証に失敗し始めます。これが、Microsoft 365のDMARCプロジェクトがp=noneで止まる最も一般的な理由です。堅牢な解決策は、アライメントをDKIMに委ねたうえで、SPFの制限を管理して回避するよりも、制限そのものを取り除くことです。特許取得済みのValimail Instant SPFは、フラット化することなくドメインを単一のルックアップに解決するため、送信元をいくつ追加してもレコードは有効なまま保たれます。

すべての正規の送信元がアライメントを保って認証を通過するようになったら、段階的にp=noneから移行いたします。pctタグを一部のメールに適用したp=quarantineを設定し、レポートを確認しながら割合を引き上げてまいります。quarantineで安定したら、p=rejectへ移行いたします。この段階的な道筋は、Microsoft 365であっても変わりません。Microsoft 365は、いずれも先に認証を通過させるべき複数の送信元のうちの一つにすぎないからです。手間の大半は送信元の棚卸しとアライメントに費やされ、最後のポリシー変更自体は容易です。

Google、Yahoo、Yahoo! JAPAN、Apple、そしてMicrosoft自身を含む主要なメールプロバイダーが、いまや一括送信者に認証を求めており、日本のクレジットカード・セキュリティガイドラインもDMARCを規制領域へと押し広げております。カスタムドメインのDKIMを有効化してこなかった、あるいはincludeの過多で静かにSPFを壊してしまったMicrosoft 365環境の日本企業は、この両面で無防備な状態にございます。Microsoft 365を正しく認証し、SaaS環境の拡大に応じてSPFレコードを健全に保ち続けること、それこそが自動化DMARCプラットフォームの役割です。

Microsoft 365はDMARCの失敗レポートを送出しないため、集約データだけでは、自社ドメインとして送信する内部サービスすべての所有者を明らかにすることはできません。そして、この所有者の特定こそが強制運用を頓挫させる要因です。ValimailのMailbox ConnectorはMicrosoft 365のメタデータを読み解いてこれらの送信元を特定し、5,500を超える送信サービスを自動的に名称で識別する受信側のRUF+方式を補完いたします。同じプラットフォームが、Instant SPFによってSPFの10ルックアップ制限を取り除き、FedRAMP認証を受けた唯一のDMARCベンダーであり、そのCTOはBIMIワーキンググループの議長、IETF DMARCグループの共同議長を務め、ARC標準の共同著者でもあるチームによって運営されております。日本のMicrosoft 365環境にとって、これはp=rejectに到達するプロジェクトと、p=noneで頓挫するプロジェクトとの分かれ目です。

SPFレコードでMicrosoft 365を許可し、Microsoft管理センターで自社のカスタムドメインに対してDKIMを有効化して2つのCNAMEレコードを公開し、レポート送信先を設定したうえでp=noneのDMARCレコードを公開いたします。集約レポートを読み込み、アライメントに失敗している送信元を修正し、quarantineを経てp=rejectへ引き上げてまいります。

Microsoft 365は既定では共有のonmicrosoft.comドメインで署名しており、これは自社ドメインにアライメントせず、DMARCの要件を満たしません。管理センターで自社のカスタムドメインに対してDKIMを有効化し、Microsoftが提示するCNAMEレコードを公開することで、署名がアライメントし、認証を通過するようになります。

SPFは1回のチェックにつきDNSルックアップを10回までしか許容いたしません。Microsoft 365に、それぞれ独自のincludeを持つ複数のSaaS送信元を加えると、この上限を超えることがございます。上限を超えるとSPFは恒久的なエラーを返し、正規のメールが認証に失敗いたします。レコードを管理し、アライメントをDKIMに委ねることが堅牢な解決策でございます。

はい。Microsoft 365は複数の送信元のうちの一つにすぎません。すべての正規の送信元がアライメントを保って認証を通過するようになったら、pctタグを用いてp=noneからp=quarantineを経てp=rejectへ引き上げてまいります。作業の中心は送信元の棚卸しとアライメントであり、最後のポリシー変更は容易でございます。

はい。主要なメールプロバイダーがいまや一括送信者に認証を求めており、日本のクレジットカード・セキュリティガイドラインもDMARCを規制領域へと広げております。アライメントの取れたDKIMを持たない、あるいはSPFレコードが壊れているMicrosoft 365環境は無防備であり、強制運用はいまや当然の水準でございます。