自分のドメインの名前で、知らないフィッシングメールが送られることがあります。これを止めるのが SPF / DKIM / DMARC です。3つの役割と、安全な設定手順をやさしく解説します。
3つの役割
| 設定 | 役割（ひとことで） |
|---|---|
| SPF | 「このドメインのメールを送ってよいサーバーはこれ」とDNSで宣言 |
| DKIM | メールに電子署名を付け、「途中で改ざんされていない・正規の送信元」を証明 |
| DMARC | SPF/DKIMが失敗したらどう扱うかの方針を宣言し、レポートも受け取る（3つをまとめる中心の設定） |
どれもDNSに置くテキスト（TXTレコード）です。example.com の場合、次のような形になります（値は例です）。
| 設定 | 置く場所 | 値の例 |
|---|---|---|
| SPF | example.com | v=spf1 include:_spf.mail-service.example ~all |
| DKIM | セレクタ名._domainkey.example.com | v=DKIM1; k=rsa; p=（送信サービスが発行する公開鍵） |
| DMARC | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
SPFの include: には、利用しているメール送信サービスが案内する値を入れます。DKIMの公開鍵も送信サービスが発行するので、自分で作る必要はありません。
どう検証されるのか（仕組み）
受信側（Gmail等）は、届いたメールに対して SPF と DKIM をチェックし、その結果を DMARCの方針 に照らして「通す／隔離する／拒否する」を決めます。
つまり **SPFとDKIMだけでは“判定はするが何もしない”**ことがあり、DMARCの方針があって初めて「なりすましを止める」効力が出ます。
見落としやすい「ドメインの一致（アラインメント）」
DMARCの判定で大事なのが、ドメインの一致です。受信者がメールソフトで目にする差出人（ヘッダの From）のドメインと、SPF または DKIM で確認されたドメインが一致して、初めて DMARC は合格になります。
SPFが確認するのは、目に見える差出人ではなく、配送の裏側で使われる送信元アドレスのドメインです。そのため、攻撃者が自分のドメインでSPFを通したうえで、差出人欄にだけあなたのドメインを書くことができます。SPFが合格でも、差出人のドメインと一致せず、DKIMでも一致が確認できなければ、DMARCは不合格と判定します。DMARCが差出人のなりすましを止められるのは、この一致を確かめるからです。
安全な設定手順
SPF を1本だけ正しく
送信に使う正規サーバー（自社・メール配信サービス等）を漏れなく許可。SPFレコードはドメインに1本にまとめる（複数あると無効になりやすい）。
DKIM 署名を有効化
利用しているメール送信基盤でDKIMを有効にし、公開鍵をDNSに登録。正規メールに署名が付く状態にする。
DMARC は p=none から始める
いきなり拒否にしない。まず p=none（監視のみ）＋レポート受信で、正規メールが落ちないかを確認する。
段階的に強める
レポートで正規配信の漏れを潰したら、p=quarantine → p=reject へ。最終的に「なりすましは拒否」を達成する。
手順1の「1本だけ」には仕様上の理由があります。SPFの仕様（RFC 7208）は、1つのドメインにSPFレコードが複数あると、判定を permerror（恒久的なエラー）にすると定めています。同じ仕様は、include などによるDNSの参照を評価全体で10回までに制限していて、超えた場合も permerror です。メール配信サービスを追加するたびに、別のレコードを足すのではなく、既存の1本に追記します。
よくある設定ミス
| ミス | 起きること | 直し方 |
|---|---|---|
| SPFレコードが2本ある | SPFが permerror になる | 1本にまとめる |
include の重ねすぎ | DNSの参照が10回を超えて permerror | 使っていないサービスの include を外す |
| 配信サービスでDKIMを有効にしていない | そのサービスから送ったメールがDMARCで不合格になる | サービス側でDKIMを有効にし、DNSに登録する |
| DMARCを p=none のまま放置 | なりすましは届き続ける | レポートを確認して reject まで上げる |
| メールを送らないドメインに何も設定しない | 使っていないドメイン名義のなりすましを止められない | v=spf1 -all と DMARC の p=reject を置く |
自分のドメインで確認する方法
- SPF / DKIM / DMARC チェッカーにドメインを入れ、3つのレコードの有無と問題点を確認する
- コマンドで直接見る場合は
dig +short TXT example.com（SPF）とdig +short TXT _dmarc.example.com（DMARC）を実行する - 自分のドメインから Gmail 宛てにメールを送り、Gmail の「メッセージのソースを表示」で
SPF・DKIM・DMARCがすべてPASSになっているかを見る - DMARCのレポート（rua）が届き始めたら、心当たりのない送信元がないかを週に一度見る
所有を確認したサイトなら、サイト総合セキュリティ診断でもWeb側の設定とあわせて点検できます。
具体例：自分のアドレスから届くなりすましメール
「自分のアドレスから自分宛てに脅迫メールが届いた」という相談は、IPAなどが注意喚起している典型的な例です。多くはアカウントの乗っ取りではなく、差出人欄を書き換えただけのなりすましです。差出人欄は送る側が自由に書けるため、DMARCを reject まで上げていないドメインでは、こうしたメールが受信箱まで届くことがあります。見分け方と対応は次の記事で解説しています。
- 自分のアドレスから迷惑メールが届いたとき（乗っ取りかどうかを5分で確かめる）
- 自分のドメインを名乗るなりすましメールが届いたとき（ヘッダの読み方と、SPF・DKIM・DMARCでの止め方）
仕様の更新（2026年5月）
DMARCの仕様は、2026年5月に RFC 9989 として改訂されました（それまでの RFC 7489 は廃止）。p=none・p=quarantine・p=reject の3つの方針はそのままです。変わった点は、適用する割合を指定する pct タグがなくなり、代わりにテスト中かどうかを示す t タグができたこと、存在しないサブドメインへの方針を指定する np タグが加わったことです。すでに設定済みのレコードがすぐ使えなくなる変更ではありませんが、新しく書くときは pct を使わないようにします。
当サイトの視点：守るのは“あなたの利用者”でもある
SPF/DKIM/DMARC は自分のメールが届くためだけでなく、あなたのドメインを騙るフィッシングから“あなたの利用者”を守る仕組みでもあります。フィッシングは結局、認証情報や鍵を盗むための手段です。多くのドメインがSPF/DKIMだけで止まり、DMARCを強制(reject)まで上げていないのが実情です。p=none で満足せず、レポートを見て段階的に reject まで上げてこそ効果が出ます。
出典（一次情報）
- IETF RFC 7208「Sender Policy Framework (SPF)」 — datatracker.ietf.org（レコードは1本、DNS参照は10回まで）
- IETF RFC 6376「DomainKeys Identified Mail (DKIM) Signatures」 — datatracker.ietf.org
- IETF RFC 9989「Domain-Based Message Authentication, Reporting, and Conformance (DMARC)」（2026年5月、RFC 7489 を廃止） — datatracker.ietf.org
- Google「メール送信者のガイドライン」 — support.google.com（2024年2月1日からの要件、1日5,000通以上の送信者の要件）
次に読む
分類番号
CWE は脆弱性の原因となる弱点の種類を、MITRE ATT&CK は攻撃者の手口を分類した番号体系です。どちらも MITRE が管理し、脆弱性情報や検知ルールの分類に広く使われています。
ATT&CK（攻撃の手口）
© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ATT&CK Terms of Use
よくある質問
QSPF / DKIM / DMARC は何のため？
あなたのドメインから送られたメールが“本物か”を受信側（Gmail等）が検証できるようにするためです。これが無いと、第三者があなたの名を騙るなりすましメール（フィッシング）を送っても止められず、ドメインの信頼も傷つきます。
Q3つの違いは？
SPFは『このドメインのメールを送ってよいサーバー』を宣言、DKIMは『改ざんされていない証拠の電子署名』、DMARCは『SPF/DKIMが失敗したらどう扱うかの方針＋レポート受信』です。DMARCがSPF/DKIMの結果をまとめて、実際の効果を持たせます。
Q設定で気をつけることは？
正規の配信（メール配信サービス等）を漏らさず許可してから強めること。とくにDMARCは、いきなり拒否(p=reject)にすると正規メールも弾く恐れがあるため、まず p=none（監視のみ）でレポートを見て、p=quarantine→p=reject と段階的に上げます。
QDMARCの p=none とは？
認証に失敗したメールも、受信側に特別な扱いを求めない設定です。なりすましを止める効果はありませんが、レポート（rua）を受け取って、自分のドメイン名義で誰がメールを送っているかを把握できます。正規の送信元をすべて確認したら、p=quarantine（迷惑メールフォルダへ）、p=reject（受け取り拒否）へ上げます。
QSPFの「-all」と「~all」の違いは？
どちらもSPFレコードの最後に置き、列挙したサーバー以外から送られたメールの扱いを示します。-all は「認めない（fail）」、~all は「おそらく認めない（softfail）」です。DMARCを使うなら、最終的な扱いはDMARCの方針で決まるため、正規の送信元を確認するまでは ~all で始めても構いません。
QSPFの「DNS参照10回まで」の制限とは？
SPFの仕様（RFC 7208）は、include・a・mx・ptr・exists と redirect による DNS の参照を、評価全体で10回までに制限しています。超えると判定は permerror（恒久的なエラー）になり、SPFが失敗扱いになります。複数のメール配信サービスを include で並べると超えやすいので、使っていないサービスの include を外して数を減らします。
QGmailは SPF・DKIM・DMARC を必須にしている？
Googleは2024年2月1日から、個人のGmailアカウントにメールを送るすべての送信者に SPF か DKIM の設定を求めています。1日に5,000通以上送る送信者には、SPF と DKIM の両方、DMARC（方針は p=none でもよい）、送信者アドレスのドメインと SPF か DKIM のドメインの一致を求めています。