【2026年版】DMARC・DKIM・SPFの設定方法を完全解説|中小企業のメール認証ガイド
メールの送信元を偽装する「なりすましメール」は、中小企業にとって深刻な脅威です。取引先を装った請求書詐欺、社長になりすました送金指示――こうした攻撃を技術的に防ぐのが、SPF・DKIM・DMARCというメール認証の仕組みです。
2024年2月にGoogleとYahooが大量送信者向けにDMARC対応を義務化して以降、メール認証は「やったほうがいい」から「やらなければメールが届かない」時代に変わりました。しかし、日本企業のドメインの約60%はいまだDMARC未設定というデータもあります。
この記事では、SPF・DKIM・DMARCの基本的な仕組みから、Microsoft 365・Google Workspaceでの具体的な設定手順、そしてDMARCポリシーを段階的に強化するロードマップまでを解説します。
SPF・DKIM・DMARCの違いを図解で解説
メール認証には3つの技術があり、それぞれ役割が異なります。3つすべてを組み合わせることで、なりすましメールを効果的にブロックできます。
SPF(Sender Policy Framework)
SPFは「このドメインからメールを送信してよいサーバーはどれか」をDNSに宣言する仕組みです。
受信サーバーは、メールの送信元IPアドレスがSPFレコードに含まれているかを確認します。含まれていなければ「なりすましの可能性がある」と判断します。
DNSレコードの例(TXTレコード):
example.co.jp. IN TXT "v=spf1 include:spf.protection.outlook.com ~all"
DKIM(DomainKeys Identified Mail)
DKIMは「メールが送信途中で改ざんされていないこと」を電子署名で証明する仕組みです。
送信サーバーがメールにデジタル署名を付加し、受信サーバーがDNSに公開された公開鍵で署名を検証します。署名が一致しなければ、メールが途中で書き換えられた可能性があると判断します。
DNSレコードの例(CNAMEレコード):
selector1._domainkey.example.co.jp. IN CNAME selector1-example-co-jp._domainkey.example.onmicrosoft.com.
DMARC(Domain-based Message Authentication, Reporting & Conformance)
DMARCは「SPFまたはDKIMの認証に失敗したメールをどう扱うか」を送信側ドメインが指定する仕組みです。さらに、認証結果のレポートを受け取ることで、自社ドメインがどのように使われているかを可視化できます。
DNSレコードの例(TXTレコード):
_dmarc.example.co.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.jp; ruf=mailto:dmarc-forensic@example.co.jp;"
3つの関係を整理
| 技術 | 検証対象 | 役割 |
|---|---|---|
| SPF | 送信元IPアドレス | 許可されたサーバーからの送信か確認 |
| DKIM | メール本文と署名 | 送信途中で改ざんされていないか確認 |
| DMARC | SPF/DKIMの結果 | 認証失敗時のポリシーを指定+レポート受信 |
SPFとDKIMが「検査官」、DMARCが「判決を下す裁判官」と考えるとわかりやすいでしょう。
なぜ今DMARCが必須なのか
Googleの送信者ガイドライン義務化
2024年2月以降、Googleは1日5,000通以上のメールを送信するドメインに対してDMARC設定を義務化しました。未対応のドメインからのメールは、Gmailで迷惑メールに分類されるか、受信拒否される可能性があります。
Yahooも同様のポリシーを導入しており、メールマーケティングやメルマガを配信している企業にとっては対応が必須です。
取引先・グループ会社からの要求
大手企業やグループ会社から「DMARC対応をしてほしい」と要請されるケースが増えています。サプライチェーン攻撃の防止が目的で、取引条件にメールセキュリティ要件が含まれることも珍しくなくなりました。
なりすましメールの被害拡大
IPA(情報処理推進機構)の「情報セキュリティ10大脅威」でも、ビジネスメール詐欺(BEC)は常に上位にランクインしています。DMARC未設定のドメインは、攻撃者にとって「なりすましやすいドメイン」であり、自社だけでなく取引先にも被害が及びます。
Microsoft 365でのSPF・DKIM・DMARC設定手順
ステップ1:SPFレコードの設定
Microsoft 365を利用している場合、以下のSPFレコードをDNSに追加します。
example.co.jp. IN TXT "v=spf1 include:spf.protection.outlook.com -all"
include:spf.protection.outlook.comはMicrosoft 365の送信サーバーを許可する指定です- 他のメール送信サービス(メルマガ配信ツール等)を併用している場合は、そのサービスのincludeも追加します
- SPFのlookup回数は10回が上限です。超える場合はサブドメイン分割を検討してください
ステップ2:DKIMの有効化
- Microsoft 365 Defender ポータル(https://security.microsoft.com)にアクセス
- メールとコラボレーション → ポリシーとルール → 脅威ポリシー → メール認証の設定 を開く
- DKIM タブで対象ドメインを選択し、「有効」に切り替える
- 表示される CNAMEレコード2つ をDNSに追加する
selector1._domainkey.example.co.jp. IN CNAME selector1-example-co-jp._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.co.jp. IN CNAME selector2-example-co-jp._domainkey.example.onmicrosoft.com.
DNSの反映(最大48時間)を待ってから、再度Defenderポータルで有効化を実行します。
ステップ3:DMARCレコードの設定
DNSに以下のTXTレコードを追加します(まずはモニタリングモードで開始)。
_dmarc.example.co.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.co.jp; pct=100"
Google WorkspaceでのSPF・DKIM・DMARC設定手順
ステップ1:SPFレコードの設定
Google Workspaceの場合、以下のSPFレコードをDNSに追加します。
example.co.jp. IN TXT "v=spf1 include:_spf.google.com -all"
ステップ2:DKIMの有効化
- Google管理コンソール(https://admin.google.com)にアクセス
- アプリ → Google Workspace → Gmail → メールの認証 を開く
- 対象ドメインを選択し、「新しいレコードを生成」をクリック
- DKIM鍵のビット長は 2048ビット を推奨
- 表示されたTXTレコードをDNSに追加する
google._domainkey.example.co.jp. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
DNSの反映後、管理コンソールで「認証を開始」をクリックします。
ステップ3:DMARCレコードの設定
Microsoft 365と同様に、DNSにTXTレコードを追加します。
_dmarc.example.co.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.co.jp; pct=100"
DMARCポリシーのロードマップ(none → quarantine → reject)
DMARCポリシーは段階的に強化することが重要です。いきなり p=reject にすると、正規のメールまでブロックしてしまうリスクがあります。
フェーズ1:モニタリング(p=none)— 1〜2か月
"v=DMARC1; p=none; rua=mailto:dmarc@example.co.jp; pct=100"
- メールの配信には影響を与えず、レポートだけを収集します
- 自社ドメインからどのサーバーがメールを送信しているかを把握します
- 想定外の送信元(社内システム、外部SaaS、メルマガツール等)がないか確認します
フェーズ2:隔離(p=quarantine)— 2〜3か月
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.jp; pct=25"
- 認証失敗メールを迷惑メールフォルダに振り分けます
pct=25で全体の25%から開始し、問題がなければ50%→100%と段階的に上げます- レポートで誤検知がないか継続監視します
フェーズ3:拒否(p=reject)— 最終目標
"v=DMARC1; p=reject; rua=mailto:dmarc@example.co.jp; pct=100"
- 認証失敗メールを完全にブロックします
- ここまで到達すれば、自社ドメインを使ったなりすましメールは受信者に届かなくなります
- BIMI(ブランドロゴ表示)にも対応可能になります
目安として、p=noneの導入から p=reject の達成まで4〜6か月を見込んでください。
よくある設定ミスと対処法
1. SPFレコードが複数存在する
ドメインに2つ以上のSPF(v=spf1)レコードがあると、認証が失敗します。複数のサービスを利用している場合は、1つのレコードに include: をまとめてください。
# NG: 2つのSPFレコード
example.co.jp. IN TXT "v=spf1 include:spf.protection.outlook.com -all"
example.co.jp. IN TXT "v=spf1 include:_spf.google.com -all"
# OK: 1つにまとめる
example.co.jp. IN TXT "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
2. SPFのDNSルックアップ回数が10回を超える
SPFの仕様では、DNSルックアップ回数の上限は10回です。include: の連鎖が深い外部サービスを複数使うと超過しやすくなります。対策としては、不要なincludeを削除するか、メルマガ配信はサブドメイン(例:mail.example.co.jp)から送信するように変更します。
3. DKIMの署名が有効化されていない
DNSにCNAMEレコードを追加しただけでは不十分です。Microsoft 365 DefenderポータルやGoogle管理コンソールで「有効化」を明示的に実行する必要があります。
4. DMARCレポートを確認していない
p=none を設定したまま放置しているケースが非常に多いです。レポートを分析しなければ、ポリシーを強化できません。無料のDMARCレポート分析ツール(DMARC Analyzer、Postmark DMARC等)を活用しましょう。
5. 転送メールでDMARCが失敗する
メーリングリストやメール転送を使っている場合、SPFアライメントが失敗することがあります。この場合、DKIMが正しく設定されていればDKIM側のアライメントで認証が通ります。DKIM設定を確実に行うことが重要です。
まとめ
メール認証(SPF・DKIM・DMARC)は、自社のドメインを守るだけでなく、取引先への信頼を証明する手段でもあります。
- SPFで送信元サーバーを制限する
- DKIMでメールの改ざんを防止する
- DMARCで認証失敗時のポリシーを明示し、レポートで監視する
- ポリシーは none → quarantine → reject と段階的に強化する
設定自体はDNSレコードの追加が中心ですが、「既存のメール送信サービスを漏れなく把握する」「レポートを分析してポリシーを段階的に上げる」といった運用面こそが成功の鍵です。
情シス365では、メール認証の設定から運用監視まで、中小企業のメールセキュリティ対策をトータルでサポートしています。「DMARCを設定したいが、どこから手をつければいいかわからない」「レポートの見方がわからない」という方は、ぜひお気軽にご相談ください。