SPF/DKIM/DMARC設定を放置すると、自社のメールが「なりすまし」扱いされる？

2026年3月18日

GoogleとYahooは大きな方針転換を行いました。
Gmail宛に1日5,000件以上のメールを送信する送信者に対し、SPFまたはDKIMの設定を必須要件とし、大量送信者（1日5,000件以上）に対してはSPF・DKIMの両方およびDMARCの設定（p=none以上）を求める要件が導入されました。

さらにGoogleは非準拠メールへの対応を段階的に強化しており、未対応のメールが一時的・恒久的に拒否されるケースも出始めています。

これはもはや「大手企業だけの話」ではありません。
規模を問わず、メールを業務で使っているすべての組織が対応を迫られています。

本記事では、送信ドメイン認証（SPF/DKIM/DMARC）の仕組みと重要性を解説し、Microsoft 365 管理センターから設定状況を確認・対応する方法を、実際の操作手順を交えて紹介します。

SPF・DKIM・DMARCとは何か：三つの「証明書」

SPF（Sender Policy Framework）

「このドメインからのメールは、このサーバーが送ります」という宣言書です。

送信側はDNSに「TXTレコード」を登録し、自社のドメインからメールを送信できる正規のサーバーのIPアドレスを事前に申告します。
受信側のメールサーバーは届いたメールの送信元IPと照合し、正規の送信元かどうかを確認します。

SPFはDNSのTXTレコードを使って送信ドメインの正規メール送信元を識別し、未定義の送信元からのメールへの対処方法を指定するものです。

SPF単体の限界：
SPFは「エンベロープFrom（送信封筒）」のドメインのみを検証します。
ユーザーが目にする「表示上のFromアドレス」のなりすましは防げません。
そのためDKIMとDMARCが不可欠です。

SPFがチェックしているのは

「このメールを送ってきたサーバーは正しいか？」

つまり
“送信元の場所”のチェック
という感じですね。

DKIM（DomainKeys Identified Mail）

「このメールは確かに私の組織が送り、改ざんされていません」という電子署名です。

送信側がメールのヘッダー・本文に電子署名を付与し、受信側はDNSに公開された公開鍵で署名を検証します。
署名が一致すれば、メールが正規の送信元から改ざんなく届いたことが証明されます。

Microsoftの公式ドキュメントでは、DKIMは送信組織のドメインを使ってメールの重要な要素にデジタル署名することで、転送中の改ざんを検知する仕組みと説明されています。

・送信側がやっていること

メールを作る
内容（件名・本文など）に対して電子署名を付ける
その電子署名を検証するための「公開鍵」をDNSに公開しておく

・受信側がやること

メールを受信
DNSから公開鍵を取得
電子署名をチェック

一致すれば：
このメールは確かにそのドメインが送った
途中で内容が書き換えられていない

と判断できます。

DKIM単体の限界：
DKIMは署名ドメインとFromアドレスのドメインが一致しているかを保証しません。攻撃者が別ドメインでDKIMを設定して送信することも可能です。これを補うのがDMARCです。

DMARC（Domain-based Message Authentication, Reporting and Conformance）

「SPFとDKIMの検証結果に基づいて、失敗したメールをどう処理するか」を指定するポリシーです。

DMARCは「アライメント」という概念を導入し、SPFとDKIMの検証結果が「ヘッダーFromアドレスのドメイン」と一致するかを確認します。
一致しない場合のポリシー（none/quarantine/reject）をDNSに登録します。

DMARCは単体で認証する技術ではなく、SPF と DKIM の結果を使って判断する“司令塔”です。

流れはこうです

① メールが届く
② SPF / DKIM のチェックをする
③ その結果が「送信元のFromドメイン」と一致しているか確認
これが アライメント（整合性）

「見た目の送信者」と「実際の送信者」が同じか？ってことです。

例：
From: example.com（見た目）
実際の送信元（SPF/DKIM）：別ドメイン

これだと なりすましの可能性あり → NG！

ポリシー（どう処理するか）

DMARCの本体はここです。

ポリシー	動作
p=none	何もしない（モニタリング専用）。まず現状把握に使う
p=quarantine	認証失敗メールを迷惑メールフォルダへ隔離
p=reject	認証失敗メールを完全拒否（最も強力な保護）

DMARCの重要な特徴として、「レポート機能」があります。
受信サーバーから自社ドメインを使ったメール送信の結果レポートが届くため、不審な送信者の検知や設定ミスの発見に役立ちます。

レポート機能は、実は超重要です。
DMARCの強みです。

「誰が自社ドメインを使ってメールを送っているか全部見える」

受信側からこんな情報が届きます：

正規の送信か？
失敗しているメールは何か？
怪しい送信元はどこか？

DMARCを設定しないと

なりすましメールを止められない
自社ドメインが悪用される
正規メールも迷惑メール扱いされる

SPF・DKIM・DMARC を設定しましょう

SPF / DKIM / DMARCは、送信ドメインを守るための仕組みです。

技術	保護対象	単体での限界
SPF	送信IPの正当性	Fromアドレスとのアライメント未確認
DKIM	メール改ざんの検知	Fromアドレスとのアライメント未確認
DMARC	SPF・DKIMの結果とFromアドレスの一致確認・ポリシー適用	ARCが別途必要（転送時）

三つが連携することで、なりすましメール対策の中核となる保護が実現します。

なお、メール転送時の認証維持にはARC（Authenticated Received Chain）が有効な補助技術として利用されます。
詳細はMicrosoftの公式ドキュメントを参照してください。

参考：信頼できる ARC シーラーを構成する

Microsoft 365 管理センターで設定状況を確認する方法

Microsoft 365を利用している組織は、管理センターからSPF・DKIMの状態を確認・設定できます。

Step 1：SPFレコードの確認

SPFはDNSのTXTレコードで管理されるため、Microsoft 365の管理ポータルから直接編集することはできません。
DNSプロバイダー（ドメインレジストラー）の管理画面で設定します。

Microsoft 365 管理センター (https://admin.cloud.microsoft/) にサインイン
左メニューから [設定] → [ドメイン] を選択
確認したいカスタムドメインをクリック
[DNS レコード] タブを開き、「Exchange Online」セクションのSPFレコード（TXTレコード）が表示されているか確認

正しいSPFレコードの例：

v=spf1 include:spf.protection.outlook.com -all

SPFレコード（v=spf1で始まるTXTレコード）は論理的に1つに統合する必要があります（複数存在するとSPF検証が失敗します）。
他サービス（Salesforce, SendGridなど）でも同じドメインを使う場合は、include: を使って1つのレコードに統合してください。

Step 2：DKIMの有効化と確認

Microsoft 365では、DKIMの有効化はMicrosoft Defender ポータルから行います。

Microsoft Defender ポータル (security.microsoft.com) にサインイン
[メールとコラボレーション] → [ポリシーとルール] → [脅威ポリシー] → [メール認証の設定] → [DKIM] に移動
または直接 security.microsoft.com/dkimv2 にアクセス
カスタムドメインの一覧が表示される
「有効」のトグルがオフになっている場合は有効化する
表示される2つのCNAMEレコードをDNSプロバイダーに登録する

追加するCNAMEレコードの例：

selector1._domainkey.contoso.com → selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com → selector2-contoso-com._domainkey.contoso.onmicrosoft.com

CNAMEをDNSに登録後、数分〜数時間で反映されます。反映後にDefenderポータルでトグルをオンにしてください。

Step 3：DMARCレコードの設定

DMARCもDNSのTXTレコードで管理します。Microsoft 365の管理センターから設定画面への直接誘導はないため、DNSプロバイダーの管理画面で追加します。

設定する場所： _dmarc.yourdomain.com というホスト名にTXTレコードを追加

推奨ステップ：モニタリングから始める

# ステップ1：まず監視（最初はこれから始める）
v=DMARC1; p=none; rua=mailto:dmarc-report@yourdomain.com

# ステップ2：隔離ポリシーに移行（認証失敗メールを迷惑メールへ）
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-report@yourdomain.com

# ステップ3：完全拒否（最終目標）
v=DMARC1; p=reject; rua=mailto:dmarc-report@yourdomain.com

いきなり p=reject にすると、正規の自社メール（基幹システムからの通知メールなど）がブロックされる恐れがあります。必ず p=none で数週間レポートを確認してから段階的に強化してください。

よくあるトラブルと対処法

❌ 「メールが迷惑メールに入る」

原因として最も多いのは、DMARC未設定やアライメント不一致、DKIM未設定などが主な原因であり、SPFの~all設定も評価に影響する場合があります。
まずDefenderポータルでDKIMの有効化を確認しましょう。

❌ 「SPFのDNSルックアップ数が10を超える」

SPFは検証時のDNSルックアップ数に10回という上限があります。
include: を多用すると超過し、SPF検証が失敗します。
spflattenなどのツールを使って最適化するか、DKIMとDMARCを優先的に整備することを検討してください。

❌ 「メール転送するとDMARCが失敗する」

メール転送時にSPFが失敗するのは仕様です。
メール転送時の認証維持にはARC（Authenticated Received Chain）が有効な補助技術として利用されます。

参考：信頼できる ARC シーラーを構成する

❌ 「サードパーティ製メールサービスからの送信が認証失敗になる」

Salesforce・Mailchimp・Kintoneなど外部サービスからも自社ドメインでメールを送信する場合は、各サービスのDKIM設定を有効にし、SPFレコードに include: で追加する必要があります。

設定確認に使えるツール

ツール	用途	URL
MX Toolbox	SPF/DKIM/DMARC/MXレコードの総合チェック	mxtoolbox.com
Google Admin Toolbox	Googleが提供するDNSチェックツール	toolbox.googleapps.com