SPF・DKIM・DMARCとは、メールの送信元ドメインが本物かどうかを受信側がDNSの情報で検証するための3つの仕組みで、自社ドメインをかたるなりすましメール対策の土台です。SPFは「どのIPアドレスが送信してよいか」、DKIMは「本文とヘッダーが改ざんされていないか」、DMARCは「その2つの結果を差出人アドレスと突き合わせてどう扱うか」をそれぞれ担当します。
3つとも設定しないと効果が出ないうえ、順序を間違えると正規のメールが迷惑メール扱いになります。以下、Microsoft 365とGoogle Workspaceそれぞれの手順、SPFの10ルックアップ制限、DMARCの「アライメント」という誤解されやすい仕組み、p=noneからp=rejectへ移行する計画、digコマンドでの確認の順に進めます。
この記事でわかること
- SPF・DKIM・DMARCがそれぞれ何を検証し、なぜ3つ揃って初めて機能するのか
- SPFの10ルックアップ制限がinclude連鎖で破綻する仕組みと回避策
- Microsoft 365（CNAME 2本）とGoogle Workspace（TXT 1本）のDKIM有効化手順
- DMARCレコードの各タグの意味と、none → quarantine → rejectの移行計画
- 集約レポート（rua）XMLの読み方、外部送信SaaSの扱い、digでの確認方法
3つの仕組みの役割と、両方が必要な理由
| 仕組み | 検証するもの | DNSレコードの場所 | 照合されるドメイン | 単体での弱点 |
|---|---|---|---|---|
| SPF | 送信サーバーのIPアドレスが許可リストにあるか | ドメイン直下のTXT（example.com） | エンベロープ送信者（Return-Path、MAIL FROM）のドメイン | 転送されるとIPが変わって失敗する。差出人（From）ヘッダーは見ていない |
| DKIM | ヘッダーと本文の電子署名が公開鍵で検証できるか | セレクター._domainkey.example.comのTXT（またはCNAME） | 署名のd=タグのドメイン | メーリングリストで件名や本文が書き換えられると失敗する。署名者が誰でもよい |
| DMARC | SPFかDKIMのどちらかが「合格」かつFromヘッダーのドメインと一致（アライメント）しているか | _dmarc.example.comのTXT | 受信者に見えるFromヘッダーのドメイン | SPF・DKIMの設定が前提。レポートを読まないと効果を確認できない |
SPFとDKIMだけでは、なりすましは止まりません。SPFが見るのはReturn-Pathのドメインで、受信者が目にするFromヘッダーとは別物です。攻撃者は自分のドメインでSPFに合格しつつ、Fromヘッダーに@example.comを書けます。DKIMも同様で、攻撃者自身のドメインの鍵で署名すればDKIM自体は合格します。DMARCは「合格したSPFまたはDKIMのドメインが、Fromヘッダーのドメインと一致しているか」を要求することで、この抜け道を塞ぎます。これがアライメントです。
逆に正規のメールでは、転送でSPFが壊れてもDKIMが残り、メーリングリストでDKIMが壊れてもSPFが（転送されなければ）残るため、両方あることで正規メールの合格率が上がります。DMARCが「どちらか一方の合格」で通す設計なのはこのためです。
SPFレコードの書き方と10ルックアップ制限
SPFはドメイン直下にv=spf1で始まるTXTレコードを1つだけ置きます。送信サービスが提供するinclude:を並べ、末尾に「それ以外の扱い」を書きます。
; Microsoft 365 のみで送信
example.com. IN TXT "v=spf1 include:spf.protection.outlook.com -all"
; Google Workspace のみで送信
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
; Microsoft 365 + Google Workspace + 自社サーバー(固定IP)
example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:_spf.google.com -all"
; メールを一切送らないドメイン（パーク中のドメインも必ず置く）
example.net. IN TXT "v=spf1 -all"末尾の-allは「リスト外は失敗」、~allは「リスト外はソフトフェイル（疑わしい）」です。DMARCの評価ではソフトフェイルも失敗も等しく「SPF不合格」なので、DMARCを運用する前提なら差は小さくなります。送信元の棚卸しが終わるまでは~all、DMARCレポートで未知の正規送信元が出なくなったら-allに変える、という順序をおすすめします。
10ルックアップ制限は、受信サーバーがSPFを評価する際にDNS問い合わせを伴うメカニズム（include、a、mx、ptr、exists、redirect）を合計10回までしか追わない、というRFC 7208の規定です。11回目以降が必要になるとレコード全体が「permerror」となり、SPFの評価結果が「不合格」相当になります。厄介なのは、includeの先にあるincludeも数えられる点です。たとえば_spf.google.comは内部で複数のネットブロック用レコードをincludeしているため1つで4回消費し、マーケティングツールやヘルプデスクSaaSを3つ足すだけで上限に達します。ip4:やip6:は問い合わせを伴わないので数えません。
回避策は3つあります。使っていないincludeを消す（過去に試用したSaaSの残骸が多い）、大量送信系のSaaSはnews.example.comのようなサブドメインから送らせて親ドメインのSPFに入れない、そしてSPFよりDKIMで認証させる（DKIMはルックアップ制限と無関係）です。includeの中身をIPアドレスに展開する「フラット化」は、SaaS側のIPが変わった瞬間に壊れるため、自動更新の仕組みなしにはおすすめしません。
v=spf1で始まるTXTレコードが同じドメインに2つ以上あると、それだけでpermerrorになります。Google WorkspaceとMicrosoft 365を併用しているドメインで「それぞれの手順書どおりに1つずつ追加した」結果、両方とも無効になっている例を何度も見ました。必ず1つのレコードにまとめてください。
Microsoft 365でのDKIM有効化手順
Microsoft 365は初期ドメイン（contoso.onmicrosoft.com）のメールには最初からDKIM署名を付けますが、カスタムドメインは管理者が有効化するまで署名されません。手順は、Microsoft Defenderポータル（security.microsoft.com）の「メールとコラボレーション → ポリシーとルール → 脅威ポリシー → メール認証の設定 → DKIM」タブでドメインを選び、署名を有効にします（メニュー名は執筆時点）。有効化の前に、次の2本のCNAMEをDNSに登録しておく必要があります。
selector1._domainkey.example.com. IN CNAME selector1-example-com._domainkey.contoso.onmicrosoft.com.
selector2._domainkey.example.com. IN CNAME selector2-example-com._domainkey.contoso.onmicrosoft.com.値の規則は「selector1-＋カスタムドメインのドットをハイフンに置換したもの＋._domainkey.＋テナントの初期ドメイン」です。正確な値はDKIMタブで対象ドメインを開くと表示されるので、手で組み立てずにコピーします。セレクターが2つあるのは、Microsoft 365が定期的に鍵をローテーションするときに、片方で署名しながらもう片方の鍵を差し替えるためです。公開鍵そのものはMicrosoft側のDNSにあり、自社DNSにはCNAMEで参照先を置くだけなので、鍵の更新で自社側の作業は発生しません。
PowerShellで状態を確認・操作する場合はExchange Online PowerShellを使います。
Connect-ExchangeOnline
# 現在の状態と、登録すべきCNAMEの値を表示
Get-DkimSigningConfig -Identity example.com |
Format-List Enabled, Selector1CNAME, Selector2CNAME, KeySize, RotateOnDate
# 署名設定がまだ存在しない場合は作成（CNAME登録前は -Enabled $false）
New-DkimSigningConfig -DomainName example.com -KeySize 2048 -Enabled $false
# CNAMEがDNSに反映されたら有効化
Set-DkimSigningConfig -Identity example.com -Enabled $true
# 1024ビットの古い鍵を2048ビットに切り替える
Rotate-DkimSigningConfig -Identity example.com -KeySize 2048CNAMEがまだ引けない状態で有効化しようとすると、ポータルにもPowerShellにもCNAMEが見つからない旨のエラーが出ます。DNSに登録して数分〜数時間待ち、後述のdigで参照先が引けることを確認してから再実行します。
Google WorkspaceでのDKIM設定手順
Google Workspaceは、DKIMを設定するまで*.gappssmtp.comという汎用ドメインで署名します。この署名はDKIM自体は合格しますが、自社ドメインとアライメントしないため、DMARCの観点では「未署名」と同じです。手順は、管理コンソール（admin.google.com）の「アプリ → Google Workspace → Gmail → メールの認証」でドメインを選び、「新しいレコードを生成」を押します（メニュー名は執筆時点）。鍵長は2048ビット、セレクターの接頭辞は既定のgoogleのままで問題ありません。
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...（省略）...IDAQAB"生成されたTXT値をDNSに登録し、管理コンソールに戻って「認証を開始」を押します。ステータスが「認証中」から「認証済み」に変わるまで、DNSの反映を待って最大48時間程度かかります。2048ビットの公開鍵は255文字を超えるため、DNSサービスによっては値を複数の文字列に分割して登録する必要があります。多くのDNS管理画面は自動で分割しますが、手動分割が必要な場合は、途中で改行や空白を入れずに"..." "..."の形にします。セカンダリドメインやエイリアスドメインで送信する場合は、ドメインごとに同じ手順を繰り返します。
DMARCレコードの書き方とp=none → quarantine → rejectの移行計画
DMARCは_dmarc.サブドメインのTXTレコードで、「不合格のメールをどう扱うか（ポリシー）」と「結果をどこに報告するか」を宣言します。最初は必ずp=noneから始めます。
; 監視フェーズ
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"
; 段階的に強制するフェーズ（10%から）
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]; adkim=r; aspf=r"
; 最終形
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; adkim=r; aspf=r"| タグ | 意味 | 推奨値と理由 |
|---|---|---|
| p | ドメイン本体のポリシー（none / quarantine / reject） | none → quarantine → rejectの順に上げる |
| sp | サブドメインのポリシー。省略時はpと同じ | SaaSにサブドメインを使わせる場合は、そのサブドメイン自身に_dmarcを置く |
| rua | 集約レポートの送り先 | 個人ではなく専用メールボックスまたは解析サービスのアドレス |
| ruf | 失敗レポート（個別メールの情報）の送り先 | 大手プロバイダーはほぼ送らないので省略可。送る場合は個人情報の扱いに注意 |
| adkim / aspf | アライメントの厳しさ。r（緩和）は組織ドメインの一致、s（厳格）は完全一致 | rで開始。sはサブドメイン送信を潰すので、必要性が明確な場合だけ |
| pct | ポリシーを適用する割合 | quarantineへ移行するとき10 → 50 → 100と上げる。rejectでは100 |
アライメントの「緩和（relaxed）」は、mail.example.comとexample.comのように組織ドメインが同じなら一致とみなします。SaaSにサブドメインを割り当てて送信させる運用は、この緩和モードがあるから成り立っています。
spタグを省略すると、pの値がそのままサブドメインにも適用されます。親ドメインをp=rejectにした時点で、_dmarcレコードを持たないサブドメイン（SaaSに送信させているnews.example.comなど）からのメールも拒否対象になります。サブドメインに送信を任せる場合は、そのサブドメイン自身に_dmarc.news.example.comを置き、SPFとDKIMを揃えてから親を強化してください。
移行の目安は、p=noneで2〜4週間レポートを集め、自社の正規送信元（Microsoft 365やWorkspace、SaaS、複合機、基幹システム）がすべてSPFまたはDKIMでアライメント合格していることを確認してからquarantineに上げます。pct=10で1〜2週間、問題がなければ100にし、さらに1か月ほど「正規メールが隔離された」という報告が出なければrejectにします。この間、部署が勝手に契約しているSaaSからの送信が必ず見つかります。それらをSaaS台帳に載せ、DKIM設定を済ませてから次の段階に進んでください。
ruaの宛先を別ドメイン（解析サービスのドメインなど）にする場合は、受け取る側のドメインにexample.com._report._dmarc.受信ドメインというTXTレコード（値はv=DMARC1）が必要です。解析サービスはこれを用意済みで、案内される値をそのまま使えばよいのですが、自社の別ドメインで受ける場合は自分で置きます。
集約レポート（rua）の読み方
集約レポートは、受信側（Google、Microsoft、Yahooなど）が1日1回、圧縮したXMLをメールで送ってくるものです。送信元IPごとに件数と評価結果がまとまっており、個々のメールの本文や宛先は含まれません。
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result><selector>selector1</selector></dkim>
<spf><domain>bounce.saas-vendor.example</domain><result>pass</result></spf>
</auth_results>
</record>この例で注目すべきは、auth_resultsのSPFがpassなのにpolicy_evaluatedのSPFがfailになっている点です。SPFはReturn-Pathのドメイン（bounce.saas-vendor.example）に対しては合格したが、Fromヘッダー（example.com）とアライメントしていないため、DMARC上は不合格と扱われています。それでもDKIMがexample.comの鍵で署名されアライメントしているので、DMARC全体としては合格（dispositionがnone）です。SaaSからの送信ではこのパターンが正常形で、DKIMを自社ドメインで設定していないSaaSはdkimのdomainがベンダーのドメインになって不合格になります。
送信元が5つを超えるとXMLを手で読むのは現実的ではないので、レポート解析サービス（無料枠のあるものが複数あります）か、自前のパーサーに集約します。見るべきは「自社が知らないIPからDMARC合格しているメール（第三者が正規に見せかけている可能性）」と「自社の正規送信元なのに不合格になっているメール（設定漏れ）」の2種類です。
外部送信サービス（SaaS）の対応
自社ドメインをFromにしてメールを送るSaaSは、DMARCを強制した瞬間に不合格になります。対応方針を送信の性質で分けます。
| 送信元の種類 | 推奨する認証方法 | 理由 |
|---|---|---|
| メール配信・MAツール（大量送信） | 専用サブドメイン（news.example.com）＋ベンダー提供のDKIM CNAME | 親ドメインのSPFルックアップを消費せず、評判（レピュテーション）も分離できる |
| ヘルプデスク・CRM・請求書送付（1対1の業務メール） | ベンダー側の「カスタムドメイン認証」でDKIMを自社ドメインに設定 | Return-Pathはベンダー側のままでも、DKIMのアライメントで合格できる |
| フォーム通知・アラート系の少量送信 | 可能ならMicrosoft 365やWorkspaceのSMTPリレー経由に変更 | SPFもDKIMも既存設定で合格し、SaaSごとの設定が不要になる |
| 複合機・NAS・基幹システム（社内機器） | Microsoft 365のコネクタまたはWorkspaceのSMTPリレーサービス経由 | 固定IPをSPFに足す方法は回線変更で壊れる。リレーなら送信元管理を一元化できる |
Gmail・Yahoo・Outlook.comなどの大手プロバイダーは、大量送信者に対してSPF・DKIM両方の設定とDMARCのアライメントを要求する方針を段階的に導入しています（執筆時点）。顧客向けメールの到達率に直結するため、マーケティング部門にはこの点を伝えると協力を得やすくなります。
確認方法：digコマンドと受信ヘッダー
DNSレコードはdig（macOS / Linux）で直接確認します。WindowsならPowerShellのResolve-DnsName -Name _dmarc.example.com -Type TXTかnslookup -type=TXT _dmarc.example.comで同じことができます。
$ dig +short TXT example.com
"v=spf1 include:spf.protection.outlook.com -all"
$ dig +short CNAME selector1._domainkey.example.com
selector1-example-com._domainkey.contoso.onmicrosoft.com.
$ dig +short TXT selector1-example-com._domainkey.contoso.onmicrosoft.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
$ dig +short TXT google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A" "MIIBCgKCAQEA..."
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"Microsoft 365のDKIMは、CNAMEの参照先まで引けてv=DKIM1で始まる値が返ることを確認します。Google WorkspaceのDKIMは、2048ビット鍵が2つの文字列に分割されて返るのが正常です。
実際の署名と評価は、GmailやOutlook.comの個人アカウント宛にテストメールを送り、Gmailなら「メッセージのソースを表示」、Outlookなら「メッセージのソースを表示」でヘッダーを開いて確認します。Authentication-Resultsヘッダーに次のように3つともpassと、header.fromが自社ドメインで記録されていれば完了です。
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1 header.b=Ab12Cd34;
spf=pass (google.com: domain of [email protected] designates 40.107.0.10 as permitted sender) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.comつまずきポイント
DMARCレポートのSPFが「permerror」になる
ルックアップ数の超過か、SPFレコードの重複です。dig +short TXT example.comでv=spf1が2行返るなら重複、1行ならincludeを1つずつdigで辿って数えます。10を超えていたら、使っていないincludeの削除とサブドメインへの分離で減らします。permerrorの間はそのドメインのSPFが全メールで不合格扱いなので、DKIMが未設定の送信元は迷惑メール判定を受けやすくなります。
CNAMEを登録したのにMicrosoft 365がDKIMを有効化できない
DNS管理画面のホスト名欄にドメイン名まで入力してしまい、selector1._domainkey.example.com.example.comという名前で登録されているケースがほとんどです。DNS管理画面がドメイン名を自動で補うタイプかどうかを確認し、ホスト名欄にはselector1._domainkeyだけを入れます。dig +short CNAME selector1._domainkey.example.comで参照先が返るまで、ポータル側の有効化は失敗し続けます。
DKIMはpassなのにDMARCがfailになる
署名のd=がベンダーのドメイン（*.gappssmtp.comやSaaSのドメイン）になっていて、Fromの自社ドメインとアライメントしていない状態です。Google Workspaceなら「メールの認証」の設定が未完了、SaaSならベンダー側の「カスタムドメイン認証」が未設定です。Authentication-Resultsヘッダーのheader.i=やheader.d=を見れば、どのドメインで署名されたかが分かります。
p=rejectにしたら、社外のメーリングリスト経由のメールが届かなくなった
メーリングリストが件名に[ML-name]を付けたり署名を追記したりするとDKIMが壊れ、リスト配信サーバーのIPはSPFに含まれないため、両方不合格になってrejectされます。対策はリスト側にあり、Fromを書き換える設定（From rewriting）やARC対応をしているリストでは問題が起きません。自社側でできるのは、影響を受ける外部リストを事前に洗い出すこと、そして自社が運営するリスト（Google GroupsやMicrosoft 365グループ）ではFrom書き換えを有効にしておくことです。この損失を許容できない業界団体経由のやり取りが多い会社では、rejectではなくquarantineで止める判断もあります。
よくある質問
DMARCは必須ですか？
法的な義務ではありませんが、Gmailなど大手プロバイダーの大量送信者向け要件（執筆時点）ではp=none以上のDMARCが求められており、未設定だと顧客向けメールの到達率に影響します。なりすまし対策としても、SPFとDKIMだけではFromヘッダーの偽装を止められないため、p=noneでレポートを受け取るところまでは全ドメインで設定しておくべきです。
SPFとDKIMの両方が必要な理由は？
壊れ方が違うからです。SPFは転送で送信IPが変わると失敗し、DKIMはメーリングリストで本文や件名が変更されると失敗します。DMARCはどちらか一方がアライメント付きで合格すれば通すため、両方を設定しておくと正規メールが誤って拒否される確率が下がります。SaaSからの送信はReturn-Pathがベンダー側になりがちで、DKIMがなければDMARCに合格できません。
p=rejectにするとメールが届かなくなりますか？
自社の正規送信元がすべてSPFかDKIMでアライメント合格していれば、届かなくなるのはなりすましメールだけです。届かなくなるのは、DKIM未設定のSaaS、SPFに載っていない複合機、本文を書き換えるメーリングリスト経由のメールです。p=noneで集約レポートを数週間読み、未知の正規送信元がゼロになってからquarantine、rejectと段階的に上げれば、業務への影響はほぼ出ません。
まとめ
設定の順番は「SPFを1本に整理 → Microsoft 365 / WorkspaceのDKIMを有効化 → DMARCをp=noneで公開 → レポートで送信元を棚卸し → SaaSのDKIMを設定 → quarantine → reject」です。技術的に難しい作業はなく、時間がかかるのは「自社ドメインで送っているシステムを全部見つける」工程です。集約レポートを受け取る専用メールボックスと、送信元を記録する台帳を最初に用意しておくと、移行判断のたびに調べ直さずに済みます。メールを送らないドメインにもv=spf1 -allとp=rejectを置き、なりすましに使われる余地をなくしてください。
次に読む
- Google Workspace管理者が最初にやるセキュリティ設定10項目：Gmailのなりすまし保護設定とDKIMの位置づけ
- SaaS管理の始め方：DMARCレポートで見つかった未知の送信元を台帳に載せる
- ランサムウェア対策の実践：メール経由の侵入を防ぐ対策の全体像