Microsoft 365 (GoDaddy / IONOS)のSPF・DKIM・DMARC設定。
Microsoft 365（Exchange Online）のドメイン認証は、複数の要素を自分で組み合わせて構成します。SPFでは共有のincludeを1つルートドメインのレコードに追加し、DKIMでは正確なターゲットをMicrosoft Defender portalで生成する2つのCNAMEレコードを使い、さらにDMARCポリシーレコードを加えます。いずれも、ドメインを管理しているDNS管理画面（ここではGoDaddyまたはIONOS）で公開します。多くのM365テナントがつまずくのは次の点です。無料の*.onmicrosoft.comドメインには自動でDKIM署名が付きますが、カスタムドメイン（yourdomain.com）には付きません。カスタムドメインのDKIM署名は手動で有効にする必要があり、そのままでは独自ドメインのメールがSPFだけに頼ることになって、転送された時点でDMARCに失敗します。このガイドでは、GoDaddy/IONOSとM365を組み合わせた実際の手順を最初から最後まで説明します。SPFのinclude（GoDaddyのリセラー特有の事情を含む）、DefenderでのDKIM CNAMEの生成、レコードタイプを間違えずに公開する方法、DMARCの追加までを扱います。
Microsoft 365 (GoDaddy / IONOS)を認証すべき理由
Microsoft 365のドメインにとって、認証は形式的な作業ではなく、受信トレイに届くか迷惑メールフォルダーに入るかを左右します。2024年2月以降、GmailとYahooは、大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoft自身も2025年5月に、Outlook.comとHotmail宛ての大量送信者に同じ要件の適用を始めました。要件を満たさないメールは、流量を制限されるか、そのまま拒否されます。M365にはこれに加えて特有の注意点があります。Microsoftはonmicrosoft.comドメインには自動でDKIM署名を付けるため、テナント側はDKIMが「何もしなくても機能する」と思い込み、実際のブランドドメインで有効にしないままになりがちです。実際には機能していません。2つのセレクターのCNAMEを公開してDefenderの署名トグルをオンにするまで、カスタムドメインのメールにはyourdomain.comとアライメントが一致するDKIM署名が付きません。その場合、DMARCにはSPF経由でしか成功せず、転送やメーリングリストを経由すると失敗します。Return-Pathが変わる一方で、本来なら残るはずの署名が最初から存在しないためです。カスタムドメインのDKIMを有効にすれば、この穴をふさげます。SPFとDKIMの両方でyourdomain.comとのアライメントが一致し、DMARCに安定して成功するようになり、築いたレピュテーションは自社ドメインに蓄積されます。
Microsoft 365 (GoDaddy / IONOS)におけるSPFの実情
Microsoft 365は、SPFのincludeで実際に認証するサービスです。ルートドメインにある1つのSPF TXTレコードにinclude:spf.protection.outlook.comを追加すれば、この1つのincludeでExchange Onlineの送信IPがすべて許可されます。Microsoftが推奨するレコードはv=spf1 include:spf.protection.outlook.com -allで、hard failです。~allを使うのはテスト中だけにしてください。このincludeはネストしたincludeのないip4/ip6の範囲のフラットな一覧に解決されるため、許容された10回のSPF DNSルックアップのうち消費するのはちょうど1回で、低コストかつ安定しています。GoDaddyとIONOSでは、サービス固有の注意点が2つあります。（1）「Microsoft 365 from GoDaddy」を購入した場合、GoDaddyの設定手順と自動管理のDNSでは、代わりにv=spf1 include:secureserver.net -allが指定されます。ただし、secureserver.netは実際にはGoDaddy独自の共有メール用includeで、Microsoftのものではありません。送信が実際にExchange Onlineを経由しているなら、Microsoftのサーバーを実際に許可するのはspf.protection.outlook.comです。現在のGoDaddyの手順で指定されているほうを使い、両方を重ねて入れず、残すincludeがMicrosoftの範囲に解決されることを確認してください。IONOSが再販するM365では、通常は引き続きspf.protection.outlook.comを使います。（2）意図しないSPFレコードがすでに存在している場合があります。GoDaddyはパーキング中のドメインに既定でinclude:secureserver.netのSPFを設定しており、IONOSのメールでも事前に作成されていることがあります。SPFレコードは1つのドメインにつき必ず1つだけです。2つ目のTXTを公開せず、Microsoftのincludeを既存のv=spf1の行にまとめてください。そうしないと、すべてのSPFチェックが「permerror」で失敗します。
設定手順
- 1
M365でドメインが確認済みであることとテナントプレフィックスを確認
Microsoft 365 admin center（admin.microsoft.com -> Settings -> Domains）で、yourdomain.comが追加され、Healthy/Verifiedと表示されていることを確認します。テナントのonmicrosoft.comプレフィックス（contoso.onmicrosoft.comの「contoso」の部分）を控えておきます。これはDKIMのターゲットに含まれます。DefenderでDKIMを有効にするには、Global AdministratorまたはSecurity Administratorの権限が必要です。また、M365をMicrosoftから直接購入したのか、「Microsoft 365 from GoDaddy」やIONOS連携プランとして購入したのかを最初にはっきりさせてください。これによって、使用するSPFのincludeと、DNSが自動管理されるかどうかが決まります。
- 2
GoDaddyまたはIONOSのDNSエディターを開く
GoDaddy：account.godaddy.comにサインインしてDomainsに移動し、yourdomain.comを選択してManage DNS（Domain Settings -> DNS）を開きます。IONOS：サインインしてMenu -> Domains & SSLを開き、対象のドメインを見つけて、歯車またはActionsのコントロールをクリックし、DNSを選択します。どちらも既存のレコードの一覧とAdd Recordボタンが表示されます。
- 3
SPFレコードを公開（既存なら1つにまとめる）
Host/Nameを@（ルートドメイン）、値をv=spf1 include:spf.protection.outlook.com -allとしてTXTレコードを追加します。SPFレコード（v=spf1で始まるTXT）がすでにある場合は、2つ目を作らずに既存のレコードを編集し、-all/~allの前にinclude:spf.protection.outlook.comを挿入します。「Microsoft 365 from GoDaddy」のリセラー経由の手順ではinclude:secureserver.netを使います。includeは1つだけ残し、実際の送信がExchange Onlineならspf.protection.outlook.comを使ってください。TTLは1時間で問題ありません。
- 4
メールをExchange OnlineにルーティングするMXとautodiscoverのレコードを追加
admin centerのドメインページに、DNS管理画面で追加すべき正確なDNSレコードをMicrosoftが一覧表示します。MXレコード（yourdomain-com.mail.protection.outlook.comを指す、優先度0）と、CNAMEレコードのautodiscover -> autodiscover.outlook.comを追加します。これらは受信とクライアント設定のためのものです。SPF/DKIM/DMARCとは別物ですが、実際にM365のメールボックスを設定するには必要です。IONOSの場合は、後述の注意点にあるMXとautodiscoverの制限を確認してください。
- 5
2つのDKIM CNAMEターゲットを生成
Defender portalのsecurity.microsoft.com/authentication（Email & collaboration -> Policies & rules -> Threat policies -> Email authentication settings）に移動し、DKIMタブを開いてカスタムドメインをクリックします。トグルをEnabledにスライドしてみます。詳細フライアウトの「Create DKIM keys」を使う方法もあります。最初の試行では意図的にClient errorまたは「CNAME record doesn't exist」のダイアログが表示され、鍵ペアが生成されます。ドメインの詳細フライアウトを開き直すと、Publish CNAMEsセクションに2組のホストと値が表示されます（Status = CnameMissing）。新しいドメインでは...<char>-v1.dkim.mail.microsoftで終わる現行の形式が使われ、古いテナントでは...onmicrosoft.com形式が表示される場合があります。両方を正確にコピーしてください。Exchange Online PowerShellでGet-DkimSigningConfigを実行し、Selector1CNAME/Selector2CNAMEを読み取る方法もあります。
- 6
2つのDKIM CNAMEレコードを公開
GoDaddy/IONOSに戻り、CNAMEレコードを2つ追加します。Host/Nameはselector1._domainkeyとselector2._domainkeyです。入力するのはセレクターのみです。GoDaddyとIONOSはyourdomain.comを自動で付加するため、完全なFQDNは貼り付けないでください。「Points to」にはDefenderのフライアウトに表示された2つのターゲットを入力します。レコードタイプは必ずCNAMEにし、TXTにはしないでください。これが最も多い失敗の原因です。両方を保存します。
- 7
DKIM署名を有効化
CNAMEが解決されるまで数分（場合によっては数時間）待ち、DefenderのDKIMタブでドメインのフライアウトに戻って「Sign messages for this domain with DKIM signatures」をEnabledにスライドします。成功すると、Statusが「Signing DKIM signatures for this domain」に変わり、Rotate DKIM keysが使えるようになります。エラーになる場合は、CNAMEがまだ反映されていないか、レコードのタイプまたはホストが間違っています。先にDNSを修正してから再試行してください。
- 8
DMARCポリシーレコードを追加
Host/Nameを_dmarc、値をv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとしてTXTレコードを追加します。p=none（監視のみ）で始めれば、M365のメールがアライメントの一致したSPFとDKIMに成功することを確認している間、何も影響を受けません。_dmarcレコードはドメイン全体で1つだけにしてください。
- 9
実際のメールで認証を確認
yourdomain.comのメールボックスからGmailアドレス宛てにテストメールを送り、開いてShow originalを使います。SPF: PASS、DKIM: PASS、DMARC: PASSと表示され、すべてonmicrosoft.comではなくyourdomain.comになっていれば成功です。その後、チェックツールでドメインをチェックし、すべてのレコードが解決され、DKIMが署名していることを確認します。
追加するレコード
正確な値はMicrosoft 365 (GoDaddy / IONOS)のセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:spf.protection.outlook.com -allSPFレコードは1つだけにし、既存のv=spf1の行にまとめます。「Microsoft 365 from GoDaddy」では代わりにinclude:secureserver.netが指定されますが、実際の送信がExchange OnlineであればMicrosoftを許可するincludeはspf.protection.outlook.comです。 |
| MX | @ | yourdomain-com.mail.protection.outlook.com優先度0。正確なトークンはM365 admin centerのドメインページに表示されます。受信メールをExchange Onlineにルーティングします。 |
| CNAME | autodiscover | autodiscover.outlook.comOutlookとモバイルクライアントの自動設定用です。IONOSのMX共存に関する注意点を参照してください。 |
| CNAME | selector1._domainkey | selector1-yourdomain-com._domainkey.contoso.a-v1.dkim.mail.microsoft例です。正確なターゲットはDefenderのDKIMフライアウトからコピーしてください（contosoはテナントプレフィックス、aはMicrosoftが割り当てる動的な文字）。TXTではなく、必ずCNAMEにします。 |
| CNAME | selector2._domainkey | selector2-yourdomain-com._domainkey.contoso.a-v1.dkim.mail.microsoft2つ目のセレクターで、鍵の自動ローテーションに必要です。古いテナントでは代わりに...contoso.onmicrosoft.comのターゲットが表示されます。Defender portalに表示されているものを使ってください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comp=noneで始め、後からquarantine/rejectへ引き上げます。_dmarcレコードは1つのドメインにつき1つです。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Microsoft 365 (GoDaddy / IONOS)の設定がこの上限のうち何回を消費するかは、次のとおりです。
Microsoft 365 (GoDaddy / IONOS)は10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Microsoft 365のカスタムドメインのDKIMは、selector1._domainkeyとselector2._domainkeyの2つのCNAMEレコードで設定します。どちらもMicrosoftがホストする公開鍵を指すため、生の鍵やTXTレコードを貼り付ける必要はありません。秘密鍵はMicrosoftが保持し、署名が有効になると2つのセレクターを使って自動でローテーションします。正確なターゲットはテナントごとに異なり、Defender portal（security.microsoft.com/authentication -> DKIM tab -> 対象のドメイン -> 詳細フライアウトのPublish CNAMEsセクション）またはExchange Online PowerShellのGet-DkimSigningConfigで確認する必要があります。2025年5月頃以降に追加されたカスタムドメインには、現行のターゲット形式selector1-yourdomain-com._domainkey.<tenantprefix>.<dynamicchar>-v1.dkim.mail.microsoftが適用されます。動的な文字（a/n/rなど）はMicrosoftが割り当てるもので、設定はできません。それ以前に有効化したドメインでは、従来のselector1-yourdomain-com._domainkey.<tenantprefix>.onmicrosoft.com形式が維持されます。自社ドメインについてDefender portalに表示されている形式を使ってください。Microsoftはどちらも受け付けますが、一方の形式を手作業でもう一方に変換したり、2つのセレクターで形式を混在させたりしないでください。GoDaddy/IONOSでは、絶対に守るべきルールが2つあります。1つ目は、レコードのタイプをTXTではなくCNAMEにすることです。TXTにしてしまうことが、「DKIMを有効にできない」の最も多い原因です。2つ目は、署名トグルをオンにする前に公開することです。先にオンにすると、DefenderがCnameMissingと報告して署名を拒否します。onmicrosoft.comドメインは自動で署名されるため、これらの作業は不要です。ただし、その署名はブランドドメインから送信するメールには何の効果もありません。
DMARC
DMARCは、_dmarc.yourdomain.comに設定する1つのTXTポリシーレコードです。SPFやDKIMとは独立していますが、この2つを結び付ける役割を担います。まずv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comを公開し、監視のみのモードで始めます。M365のメールがyourdomain.comとアライメントが一致した状態でSPFとDKIMの両方に成功することを確認している間、配信には何も影響しません。Exchange Onlineでは、SMTPのMAIL FROM（Return-Path）がyourdomain.comに設定され、カスタムドメインのDKIMを有効にするとd=yourdomain.comで署名されます。そのため両方の認証方式のアライメントが一致し、DMARCに問題なく成功します。1～2週間、集計レポート（rua）を確認します。Microsoftが、アライメントが一致して成功している送信元として表示され、正規のサードパーティ送信者（CRMやマーケティングツールなど）が失敗していないことを確かめてから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。yourdomain.comで送信するサービスがいくつあっても、_dmarcレコードは必ず1つだけにしてください。GoDaddyとIONOSでは重複レコードも作成できてしまいますが、_dmarcレコードが2つあると無効な設定になります。
正しく設定できたか確認する
Defenderの「Signing DKIM signatures for this domain」のバッジだけで判断せず、実際のメールで確認してください。yourdomain.comのメールボックスからGmailアカウント宛てにテストメールを送り、開いて3点メニュー -> Show originalを選びます。SPF: PASS、DKIM: PASS、DMARC: PASSと表示され、DKIM署名のd=がyourtenant.onmicrosoft.comではなくyourdomain.comになっていれば成功です。プレーンテキストのレポートが必要な場合は、check-auth@verifier.port25.com宛てに送信して返信を読む方法もあります。DNS側では、両方のセレクターのCNAMEが実際にMicrosoftのターゲットに解決されることを確認します（dig/nslookup selector1._domainkey.yourdomain.com CNAME）。GoDaddyでよくある間違いは、レコードが気付かないうちにTXTとして保存され、何にも解決されないことです。Qualisendの送信ドメイン認証チェックとドメイン診断でドメインをチェックし、SPFレコードが1つだけでOutlookのincludeのルックアップが1回であること、両方のDKIMセレクターが稼働していること、DMARCが有効であることを確認します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Microsoftが、アライメントが一致して成功している送信元として表示されるはずです。
よくある注意点
- DNS設定
DKIMレコードのタイプはTXTではなくCNAMEにする必要があります。GoDaddyとIONOSはどちらもAdd Recordのドロップダウンの既定値が別のタイプになっており、TXTとして保存したセレクターは何にも解決されません。これがDefenderで「DKIMを有効にできない」場合の最も多い原因です。
- DNS設定
Defenderの署名トグルをオンにする前に、2つのセレクターのCNAMEを公開してください。最初のトグル操作は失敗するのが正常です（Client errorまたは「CNAME record doesn't exist」のダイアログ）。この操作で鍵が生成され、CNAMEの値が表示されるだけです。CNAMEが解決される前に有効にしようとすると、StatusはCnameMissingのままで、署名はオンになりません。
- 適用範囲
カスタムドメインのDKIMは既定でオフです。Microsoftが自動で署名するのは*.onmicrosoft.comドメインだけなので、テナント側はDKIMが対応済みだと誤解しがちです。yourdomain.comのメールは、有効にするまで署名されないままで、転送時にDMARCに失敗しやすい状態が続きます。
- 認証失敗の原因
SPFレコードは1つのドメインにつき1つだけです。GoDaddyはパーキング中のドメインに既定でinclude:secureserver.netのSPFを設定しており、IONOSが再販するメールでも事前に作成されていることがあります。Microsoft用に2つ目のv=spf1のTXTを追加するとpermerrorになります。代わりにinclude:spf.protection.outlook.comを既存の行にまとめてください。
- 適用範囲
GoDaddyとIONOSは、Host/Name欄にドメインを自動で付加します。selector1._domainkey、@、_dmarcだけを入力し、完全なyourdomain.comのFQDNは入力しないでください。入力するとselector1._domainkey.yourdomain.com.yourdomain.comが作成されてしまいます。
- DNS設定
IONOSでは、1つのドメインにMXレコードと最上位のautodiscover CNAMEを同時に持たせることができません。これはExchange Onlineの制限として文書化されています。ルートドメインのautodiscover CNAMEを省略するか、IONOSの回避策に従ってサブドメインに作成してください。SPF/DKIM/DMARCには影響しません。
- 適用範囲
「Microsoft 365 from GoDaddy」を購入した場合、DNSは自動管理されている可能性が高く、GoDaddyが指定するSPFのincludeはspf.protection.outlook.comではなく独自のinclude:secureserver.netです。手動の編集が上書きされることもあります。IONOS連携のM365でも同様にレコードが自動で書き込まれることがあります。手動で編集する前にゾーンの管理主体を確認し、実際の送信がExchange Onlineなら、SPFのincludeがMicrosoftのサーバーを実際に許可していることを確かめてください。
- 適用範囲
いきなりDMARCをp=rejectにしないでください。p=noneで始め、Microsoftとすべての正規の送信者がアライメント一致かつ成功と表示されるまで集計レポートを読んでから、quarantine、rejectへと引き上げます。そうしないと、自社のメールを自ら遮断してしまうおそれがあります。
SPFレコードを作成
以下ではMicrosoft 365 (GoDaddy / IONOS)があらかじめ選択されています。他に利用している送信プラットフォームを追加し、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 (GoDaddy / IONOS)のSPFに関するよくある質問
関連記事
ワークスペース・メールボックスの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。