Microsoft 365のSPF・DKIM・DMARC設定。
Microsoft 365（Exchange Online）は、ホスト型のメール配信サービス（ESP）のように1つのウィザードでドメインを認証するのではなく、作業を2つのコンソールに分けています。SPFは本来の共有include（include:spf.protection.outlook.com）で、ドメインにある1つのSPFのTXTレコードにまとめます。DKIMは2つのCNAME「セレクター」レコードで、公開した後にMicrosoft Defender portalでオンにします。DMARCは3つ目の別のレコードで、Microsoftが作成することはありません。3つすべてのアライメントを一致させると、Exchange Onlineから、デフォルトのonmicrosoft.comの署名に頼らず、自社ドメインとして完全に認証された状態で送信できます。
Microsoft 365を認証すべき理由
Microsoft 365ドメインの認証は、メールが受信トレイに届くかどうかを左右します。さらにM365には、DMARCが気づかないうちに壊れるという特有の注意点があります。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。2025年5月からはMicrosoftも、Outlook.com/Hotmail/Live宛ての大量メールに同じ要件の適用を始めました。そのため、Microsoftの一般向け受信トレイに届くビジネスメールも認証が必要です。M365特有の注意点はこうです。初期状態のExchange Onlineは、送信メールにテナントのonmicrosoft.comドメインでDKIM署名します（d=contoso.onmicrosoft.com）。これは独自のFromドメイン（contoso.com）とアライメントが一致しません。MicrosoftのSPFはアライメントが一致するため、直接送信のメールならSPFだけでかろうじてDMARCに成功します。しかしメールが転送されると（メーリングリスト、.forwardルール、フィルタリングゲートウェイ）SPFは壊れ、DKIMは別のドメインで署名しているため、DMARCを支えるものが何も残りません。独自ドメインのDKIMを設定すれば、この穴を塞げるうえ、築いた送信レピュテーションが自社ドメインに蓄積されるようになります。
Microsoft 365におけるSPFの実情
Microsoft 365は本来の意味で「include」を使うサービスです。CNAMEで委任するESP（Mailchimp、Klaviyo）やアカウント単位の送信サービス（Amazon SES）とは異なり、ルートドメインのSPFレコードに追加する本物の共有includeが1つあります。include:spf.protection.outlook.comです。これをドメイン上の1つのSPFのTXTレコード内に公開します。例：v=spf1 include:spf.protection.outlook.com -all。M365のSPFが特に扱いやすい理由は2つあります。1つ目は、このincludeの解決先がip4:/ip6:の範囲と独自の-allのみを含むフラットなレコードで、入れ子のincludeがないことです。そのためSPFの10回のDNSルックアップのうち、消費するのは1回だけです（2～3回という通説がありますが、現在のレコードにサブのincludeはありません）。2つ目は、Exchange OnlineではデフォルトでSMTP MAIL FROM（エンベロープ/Return-Path）に自社ドメインが使われるため、SPFのアライメントが実際に自社ドメインと一致することです。つまりM365のincludeだけでDMARCの成功に寄与します。Return-Pathを自ら持つESPにはできないことです。Microsoftは、DKIMとDMARCの運用も前提としているため、-all（hard fail）を明確に推奨しています。注意点が2つあります。異なるのは政府向け/国別クラウドだけで、GCC HighとDoDはinclude:spf.protection.office365.us、21Vianet（中国）はinclude:spf.protection.partner.outlook.cnを使います。また、送信用サブドメインごとに独自のSPFレコードが必要です（contoso.comのレコードはmarketing.contoso.comをカバーしません）。
設定手順
- 1
ドメインを確認してDNSレコードを探す
admin.microsoft.comにサインインし、Settings → Domainsでドメインを選択して、DNS recordsタブを開きます。ネームサーバーをMicrosoftに委任している場合は、SPFとMX（yourdomain-com.mail.protection.outlook.com）がすでに公開されていることがあります。DNSがレジストラやホストにある場合、M365のこの画面にはSPFやDMARCの設定項目がないため、DNSホストで自分でレコードを追加します。
- 2
SPFレコードを公開（既存なら1つにまとめる）
DNSホストで、ルートドメイン（ホストは@）に、v=spf1 include:spf.protection.outlook.com -allというTXTレコードを1つだけ作成します。v=spf1のレコードがすでにある場合（Google Workspace、マーケティングツールなど）は、includeをその1つのレコードにまとめます。2つ目のSPFのTXTレコードを追加してはいけません。Microsoftは-all（hard fail）で終えることを推奨しています。GCC High/DoDはspf.protection.office365.us、21Vianetはspf.protection.partner.outlook.cnを使います。
- 3
DKIMタブを開く
独自のDKIMの設定はM365 admin centerにはありません。security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settingsに進み、DKIMタブを選択します。
- 4
2つのCNAME値を表示
独自ドメインをクリックします。未設定のドメインはStatus = NoDKIMKeysでトグルはDisabledです。トグルをEnableにスライドすると、CNAMEがまだ存在しないため「Client error」ダイアログが開き、StatusがCnameMissingに変わります。これは想定どおりで、失敗ではありません。「Publish CNAMEs」セクションに、selector1とselector2の正確なCNAMEターゲットが表示されます。これをコピーします（またはExchange Online PowerShellでGet-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME,Selector2CNAMEを実行します）。
- 5
DKIMセレクターのCNAMEを2つ追加
selector1._domainkeyとselector2._domainkeyをCNAMEレコードとして作成し、ポータルに表示された正確なターゲットを指定します。新しいドメイン（Microsoftが2025年5月に導入した形式）のターゲットはselector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoftのような形式です（<char>はnやrなど、Microsoftが割り当てるパーティション文字です）。それ以前に設定したドメインのターゲットはselector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.comです。ポータルに表示された形式を使ってください。2つの形式を1つのセレクターに混在させることはできません。TXTに変更しないでください。
- 6
DKIMをEnabledに切り替える
CNAMEが反映された後（通常は数分、最大48時間）、DKIMタブに戻ってドメインを選択し、トグルを再度Enableにスライドします。StatusがValidに変わり、「Rotate DKIM keys」が使えるようになります。以降、M365はonmicrosoft.comのデフォルトではなくd=yourdomain.comで署名するため、DKIMのアライメントが一致します。
- 7
DMARCレコードを追加
M365はDMARCを作成しません。ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comというTXTレコードを追加します。p=none（Microsoftの「take no action」の監視モード）から始めれば、SPFとDKIM両方のアライメントを確認する間も何も影響を受けません。ポリシーの引き上げはその後で行います。
- 8
テストメールを送信してヘッダーを確認
そのドメインのメールボックスからGmailの自分宛てにメールを送り、開いて⋮ → Show originalを選びます。SPF: PASS（自社ドメインを表示）、DKIM: PASS（onmicrosoft.comではなくd=yourdomain.com）、DMARC: PASSと表示されていれば成功です。その後、ドメイン診断ですべてのレコードが解決されることを確認します。
追加するレコード
正確な値はMicrosoft 365のセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:spf.protection.outlook.com -allルートドメインのSPF：SPFレコードは必ず1つだけにします。v=spf1のレコードがすでにある場合は、このincludeをそのレコードにまとめます。DNSルックアップを約1回消費します。 |
| CNAME | selector1._domainkey | selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftDKIM鍵1（自動ローテーション）。例です。正確なターゲットはDefender portalからコピーしてください。2025年5月より前に作成したドメインは、.n-v1.dkim.mail.microsoftではなく.onmicrosoft.comで終わります。 |
| CNAME | selector2._domainkey | selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftDKIM鍵2（2つ目のセレクターでMicrosoftが鍵をローテーションします）。例です。ポータルに表示された正確な値を使ってください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。M365が作成することはありません。1つのドメインにつき1つで、p=noneから始めます。 |
| MX | @ | contoso-com.mail.protection.outlook.com受信メールをExchange Onlineにルーティングします（優先度0）。認証レコードではありませんが、M365の設定の一部です。ドメイン内のドットはハイフンになります。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Microsoft 365の設定がこの上限のうち何回を消費するかは、次のとおりです。
Microsoft 365は10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Microsoft 365でDKIMはつまずきやすい部分です。何もしなくてもM365は「すでに署名している」ものの、そのドメインが正しくないからです。デフォルトでは、Exchange Onlineはテナントの初期onmicrosoft.comドメインで送信メールにDKIM署名します（d=contoso.onmicrosoft.com）。この署名自体は有効ですが、独自のFromドメインとアライメントが一致しないため、contoso.comのDMARCには何の役にも立ちません。解決するには、独自ドメインのDKIMを有効にします。selector1._domainkeyとselector2._domainkeyという2つのCNAMEレコードで、公開鍵をMicrosoftに委任するものです。貼り付けるTXTレコードではなくCNAMEなので、Microsoftが秘密鍵を保持し、以後は自分でDNSを変更しなくても2つのセレクターで鍵を自動的にローテーションします。ターゲットの形式は2025年5月に変わりました。新しい独自ドメインはselector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoftになり（<char>はnやrなど、Microsoftが割り当てるパーティション文字です）、それ以前に設定したドメインはselector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.comのままです。テナントに割り当てられた形式は、ポータル（またはExchange Online PowerShellのGet-DkimSigningConfig）で正確に確認できます。2つの形式を1つのセレクターに共存させることはできません。手順：Defender portal（Email authentication settings → DKIM）でCNAMEを表示し、両方をDNSホストで公開して反映を待ち、ドメインのDKIMトグルをEnabledに切り替えて、StatusにValidと表示されるようにします。鍵のデフォルトは1024ビットで、2048ビットはNew-DkimSigningConfig（-KeySize 2048を指定）で利用できます。トグルをEnabledにして初めて、M365はd=yourdomain.comで署名し、DKIMのアライメントが一致するようになります。
DMARC
DMARCは、ドメインに設定する別のポリシーTXTレコードで、Microsoft 365は作成しません。自分でDNSホストに追加します。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを公開します。p=noneはMicrosoftが推奨する「take no action」の監視モードで、配信には一切影響しません。その間に集計レポート（rua）を確認し、M365（と他の送信者）がSPFとDKIMに成功し、アライメントが自社ドメインと一致しているかを確かめます。Microsoft自身のガイダンスも、まずDKIM署名と監視モードのDMARCを早急に整え、その後でポリシーを引き上げることです。アライメントが安定したら、p=quarantine、次にp=rejectへと段階的に引き上げます。_dmarcレコードは組織ドメイン全体で1つだけにしてください。サブドメインは親のポリシーを自動的に継承します（特定のサブドメインは、独自の_dmarcレコードまたはsp=タグで上書きできます）。M365のSPFはアライメントが一致し、独自のDKIMを設定すればDKIMも一致するため、正しく設定したM365ドメインは両方のメカニズムでDMARCに成功します。これが転送にも耐える堅牢な構成です。
正しく設定できたか確認する
Defender portalの「Valid」バッジだけで判断せず、実際のメールで確認してください。そのドメインのメールボックスから自分宛てにテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASS、DKIM: PASS（d=yourdomain.com）、DMARC: PASSと表示されていれば成功です。失敗の典型的な兆候はd=yourtenant.onmicrosoft.comで、独自のDKIMがまだ有効になっていないことを示します。Defender portalのDKIMタブでは、そのドメインのStatus = Valid、Toggle = Enabledと表示されるはずです。次に、Qualisendのドメイン診断でドメインをチェックし、SPFレコード、2つのDKIMセレクターのCNAME、DMARCレコードがすべて正しく解決されることを確認します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Outlook.com / Exchange Onlineが、アライメントが一致し、認証に成功している送信元として表示されるはずです。
よくある注意点
- 適用範囲
M365で最大の注意点：独自ドメインのDKIMを有効にするまで、メールはd=yourtenant.onmicrosoft.comで署名され、アライメントは一致しません。そのためDMARCはDKIMの助けを得られず、メールが転送された時点で失敗します。SPFだけでは不十分です。
- DNS設定
DKIMのトグルを最初にEnableにスライドしたときに出る「Client error」ダイアログとCnameMissingのステータスは想定どおりで、バグではありません。ポータルがCNAMEの値を表示する仕組みです。2つのCNAMEを公開してから戻り、再度Enableに切り替えてください。
- DNS設定
DKIMのCNAMEターゲットの形式は2025年5月に変わりました。それ以降に設定した独自ドメインは<tenant>.<char>-v1.dkim.mail.microsoftを指し、古いものは<tenant>.onmicrosoft.comを指します。正確なターゲットをDefender portal（またはGet-DkimSigningConfig）からコピーしてください。新旧の形式を同じセレクターに混在させることはできません。
- 認証失敗の原因
ドメインのSPFのTXTレコードは必ず1つだけにしてください。Google Workspace、SendGridなどからすでに送信している場合は、include:spf.protection.outlook.comをその1つのレコードにまとめます。SPFのTXTレコードが2つあると、それ自体がPermErrorになります。
- 適用範囲
GoDaddyやIONOSが提供するM365では、デフォルトのSPFがinclude:secureserver.netになっていることがよくありますが、これはExchange Onlineのメールボックスを許可しません。解決先はinclude:spf.protection.outlook.comでなければなりません。
- DNS設定
M365のDKIMレコードはCNAMEです。DNSがCloudflareの配下にある場合は、各セレクターレコードを「DNS only」（グレーのクラウド）に設定してください。プロキシが有効なオレンジのクラウドのCNAMEはMicrosoftのホストに解決されず、DKIMの有効化に失敗します。
- DNS設定
Microsoftが指摘するSPFの構文ミスに注意してください。末尾にピリオドを付けない（include:spf.protection.outlook.com.は誤りです）、includeの後はイコールではなくコロン、コロンの後にスペースを入れない、の3点です。また、多くのレジストラはCNAME/ホスト欄にドメインを自動で付け足し、二重になることがあります。
- 適用範囲
送信用サブドメインごとに独自のSPFレコードとDKIMレコードが必要です。contoso.comのレコードはmarketing.contoso.comをカバーしません。サブドメインから送信する一括送信/マーケティングツールには、そのサブドメインのSPFレコードとDKIMレコード、そして通常は独自のDMARC対応が必要です。
SPFレコードを作成
以下ではMicrosoft 365があらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Microsoft 365のSPFに関するよくある質問
関連記事
ワークスペース・メールボックスの他のサービス
- Microsoft 365 (GoDaddy / IONOS)
- Migadu
- Namecheap Private Email
- Proton Mail
- Purelymail
- Rackspace Email
- Titan
- Yandex 360
公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。