メールが迷惑メールに入ったり、拒否されたり、「未認証の送信者」と表示されたりするなら、最初に確認すべきは メール認証の設定 です。
つまり、次の 3 つの重要なレコードを検証することです:
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
- DMARC (Domain-based Message Authentication, Reporting, and Conformance)
これらの DNS レコードは、Gmail / Outlook / Yahoo のようなメールボックスプロバイダに対して、「このドメインは本当に送信を許可されているか」を伝えるものです。どれかが不足していたり壊れていたり、設定が弱すぎたりすると、メッセージへの信頼は一気に下がります。
この無料 2026 ガイドで学べる内容:
- SPF レコード の確認方法
- DKIM レコード の確認方法
- DMARC レコード の確認方法
- レコードが存在しても、なぜメールが迷惑メールに入るのか
- メール認証でよくあるミス
- 任意のドメインの到達性を最速で診断する方法
ビジネスドメイン、ニュースレター、サポート受信箱、アウトリーチキャンペーン、SaaS、コールドメール送信を運用しているなら、これは最も重要な技術チェックの一つです。
クイックアンサー: ドメインの SPF / DKIM / DMARC はどう確認する?
任意のドメインで SPF / DKIM / DMARC を確認する手順:
- ドメインの DNS TXT レコードを引く
- SPF レコード が存在し、有効であるかを確認する
- DKIM セレクター が有効な公開鍵に解決されるかを確認する
_dmarc.あなたのドメイン.comに DMARC ポリシー があるかを確認する- レコードがただ「存在する」だけでなく、正しく構成されている かを確認する
- それでも迷惑メールに入る場合は、実際のメールヘッダー を解析して、何が通って何が落ちたかを見る
初心者にとって最速の流れは、まず Email Health Checker でドメイン全体をスキャンし、引っかかった箇所だけ深掘りしていくやり方です。
2026 年に SPF / DKIM / DMARC が重要な理由
メールプロバイダは過去最高に厳しくなっています。
最近の受信箱は、本文だけを見るのではなく、ドメインの送信設定が信頼できるかを見ています。
SPF / DKIM / DMARC の構成がしっかりしていれば、次のメリットがあります:
- 受信箱への到達 が改善する
- メールスプーフィング のリスクが下がる
- ドメインがフィッシングに悪用されにくくなる
- 迷惑メール に入る確率が下がる
- Gmail / Outlook / Yahoo / 企業向けゲートウェイからの信頼が増す
- 時間とともに送信者レピュテーションが健全に育つ
次のいずれかを送っているなら:
- トランザクションメール
- 認証コード
- ニュースレター
- コールドアウトリーチ
- サポートからの返信
- パスワードリセットメール
- SaaS 通知
…もはやメール認証は「あった方が良い」ではなく必須です。
SPF / DKIM / DMARC とは? (シンプルに解説)
レコードを見る前に、それぞれが何をしているのかを押さえておくと役立ちます。
SPF: 誰がそのドメイン名でメールを送ってよいかを定義
SPF は、ドメインを名乗って送信できるメールサーバーやサービスを列挙する DNS TXT レコードです。
たとえば次のサービスを使っている場合:
- Google Workspace
- Microsoft 365
- Mailgun
- SendGrid
- Amazon SES
- Brevo
- Zoho Mail
…通常はこれらを SPF に含める必要があります。
SPF が守るもの: ドメインのなりすましによる送信。
SPF が 保証しない もの: 表示される From アドレスが、DMARC が要求する形で完全に整列していること。
DKIM: メールが署名されている証拠
DKIM は送信メールに暗号署名を付けます。
受信側のサーバーは DNS に保管された公開鍵を使って次のことを検証します:
- このメールは認可された送信者によって署名されている
- 道中で改ざんされていない
DKIM が守るもの: 改ざんと、有効な署名を持たない偽造メール。
重要: DNS に DKIM レコードがある = 実送信で DKIM がきちんと機能している、では ありません。
DMARC: SPF / DKIM が失敗したときに、受信側へ取るべき行動を伝える
DMARC は SPF と DKIM の上に成り立ちます。
受信サーバーに対して次のことを伝えます:
- 失敗したメールを 監視 するのか、隔離 するのか、拒否 するのか
- 集計レポート をどこへ送るか
- 認証されたドメインが、表示される From ドメインと整列しているか
DMARC ポリシー値:
p=none→ 監視のみp=quarantine→ 怪しいメールは迷惑メールへp=reject→ 失敗したメールは拒否
DMARC が守るもの: ドメインのスプーフィング、なりすまし、認証の弱い運用。
任意のドメインで SPF / DKIM / DMARC を確認する方法
最も簡単で実用的なワークフローはこれです。
ステップ 1: まずメール認証を一括チェック
レコードを 1 つずつ手動で見る前に、まず ドメイン全体の広いスキャン を行います。
Email Health Checker で、次の項目を一度に把握できます:
- SPF の状況
- DKIM の有無
- DMARC の有無
- MX の設定
- 認証の基本的な健康度
- 一般的なリスクのシグナル
これは最初のステップとして優れていて、深掘りの前に「致命的な見落とし」がないかを即座に教えてくれます。
なぜ大事か: 多くのドメインは、DMARC 未設定 / DKIM 未設定 / MX 不足 / SPF が壊れているといった、ごく初歩的な理由で失敗しています。
ステップ 2: SPF レコードの確認方法
「SPF レコードの確認方法」を本当に正しくやりたいなら、「存在するか?」だけ聞かないでください。有効か、きれいか、上限内に収まっているか を聞きましょう。
有効な SPF レコードの見た目
通常は次のように始まります:
v=spf1 include:_spf.google.com ~all
チェックポイント
v=spf1で始まっている- ドメインに SPF TXT レコードは 1 件のみ
- 現在の 送信プロバイダ がすべて含まれている
- 妥当なポリシーで終わっている:
~all(ソフトフェイル)-all(ハードフェイル)
- DNS ルックアップ 10 回の上限 を超えていない
よくある SPF のミス
- 複数の SPF レコード を公開してしまう
- 過去のメールプロバイダの
include:を残している +allのような緩すぎるルール- 10 ルックアップ上限 を超えている
- ESP を切り替えた後の SPF 更新忘れ
2026 年大の SPF 問題: 10 ルックアップ上限
これは到達性を陰でぶち壊す原因の代表格です。
SPF にネストされたプロバイダや転送サービス、SaaS ツールが多すぎると、許容ルックアップ数を超えて静かに失敗します。
SPF が複雑なら、SPF Flattening Tool で include チェーンを明示的な IP に展開すると、上限に収まります。
ステップ 3: DKIM レコードの確認方法
「DKIM レコードの確認方法」を調べているなら、まず押さえるべきはこれ:
DKIM はセレクターベース です。
つまり通常は次の 2 つが必要です:
- ドメイン
- 送信プラットフォームが使う セレクター
DKIM レコードはたいてい次のようなパスにあります:
selector1._domainkey.example.com
チェックポイント
- セレクターが正しく解決される
- TXT レコードが存在する
- 公開鍵 (
p=) が含まれている - レコードが正しくフォーマットされている
- 鍵の強度が十分
- そのプラットフォームが実際の送信メールに署名している
よくある DKIM のミス
- セレクターが間違っている
- レコードを公開しただけで、メールプロバイダ側で DKIM が有効になっていない
- DNS 内の TXT フォーマットが壊れている
- 弱い、または古い鍵長
- 鍵のローテーション手順を間違える
- 「レコードが存在する」=「DKIM が通る」と勘違いする
レコード自体をより深く技術的に検査したい場合は、DKIM Analyzer で鍵の強度、レコード構造、設定上の問題を調べられます。
ステップ 4: DMARC レコードの確認方法
「DMARC レコードの確認方法」を正しくやるなら、次の場所の TXT を見ます:
_dmarc.example.com
基本的な DMARC レコードはこんな形:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
チェックポイント
v=DMARC1で始まる- ポリシーが指定されている:
p=nonep=quarantinep=reject
- できればレポート送付先がある:
rua=mailto:...
- 任意でフォレンジックレポート:
ruf=mailto:...
- 整列設定があってもよい:
adkim=aspf=
- 任意で段階的ロールアウト:
pct=
よくある DMARC のミス
- DMARC レコードがそもそもない
- いつまでも
p=noneのまま - レポート用のメールボックスが用意されていない
- 構文が壊れている
- 整列の失敗を無視している
- 中身を理解せずに汎用レコードをコピペ
レコードの妥当性をすばやく確認し、監視止まりか実際に強制適用しているかを見るには、DMARC Checker を使ってください。
SPF / DKIM / DMARC があっても迷惑メールに入る理由
これは到達性の中で最も誤解されている部分の一つです。
ドメインに SPF / DKIM / DMARC が 存在していて も、メールは依然として迷惑メールに落ちることがあります。
なぜ?
存在 と 正しい構成 は同じではないからです。
ありがちな理由:
- SPF はあるが、10 ルックアップ上限を超えている
- SPF は通るが 整列に失敗 している
- DKIM レコードは存在するが、実際の署名で失敗 している
- 転送やリライトの後に DKIM が壊れる
- DMARC はあるが
p=noneのまま - ドメインのレピュテーションが悪い
- 送信元 IP のレピュテーションが悪い
- 本文がスパムフィルタを刺激する
- リンクが怪しく見える
- バウンス率が高い
- 苦情率が高い
- 逆引き DNS がない、または弱い
- 送信ボリュームの傾向が突然変わった
大事な真実
SPF + DKIM + DMARC は土台であって、到達性システムの全体ではありません。
これらは受信側の信頼を後押ししますが、悪い送信者レピュテーションやスパム的振る舞いを覆すものではありません。
メールが迷惑メールに入った理由を調べる方法
DNS レコードはきれいなのに、実際のメールが迷惑メールに行くなら、DNS だけ見ていてはダメです。
メールの生ヘッダー を調べる必要があります。
そこにこそ、受信側サーバーが実際に観測した内容が書かれています。
Email Header Analyser で次の項目を確認してください:
- SPF pass/fail
- DKIM pass/fail
- DMARC pass/fail
- Authentication-Results
- メールホップ / リレー経路
- 整列に関するヒント
- スパム経路の手がかり
ここを飛ばすと致命的: 多くの人は DNS レコードだけを見て、実際に届いたメッセージ を検査しません。隠れた問題はそこに現れます。
メール認証チェックの最速ワークフロー
2026 年に最もシンプルで実用的なワークフローを順番に:
- 広域スキャン … Email Health Checker
- DMARC ポリシーと適用度 … DMARC Checker
- DKIM 品質とセレクターの妥当性 … DKIM Analyzer
- SPF の構造とルックアップ数 … SPF Flattening Tool
- 実メールヘッダー … Email Header Analyser (まだ届かないなら)
これで次の 3 つのビューが揃います:
- DNS レベル のビュー
- ポリシーレベル のビュー
- 実メッセージレベル のビュー
この組み合わせは、単純な TXT ルックアップ 1 回より圧倒的に役立ちます。
SPF / DKIM / DMARC でやりがちな避けるべきミス
ビジネスドメイン / SaaS / コールドメール構成で、繰り返し見かけるパターンです。
SPF のミス
- 複数の SPF TXT レコード
include:ルックアップが多すぎる- 古いプロバイダを残したまま
+allや緩すぎるポリシー- プロバイダ変更後に SPF を更新しない
DKIM のミス
- セレクターが間違っている
- レコードを公開しただけで署名がオフ
- TXT のフォーマット崩れ
- 鍵が弱い
- 実送信メールでテストしない
DMARC のミス
- DMARC レコードなし
- 永遠に
p=none rua=レポート先なし- 整列を無視
- 構文崩れ
- 強制適用に向けて動かない
2026 年に向けた SPF / DKIM / DMARC のベストプラクティス
今年、より良い受信箱配信を狙うなら、最低限ここを目指しましょう:
- SPF レコードはきれいな 1 件のみ を公開する
- SPF は 10 ルックアップ上限以下 に保つ
- 古い、未使用のプロバイダを SPF から除外する
- 強い DKIM 鍵を使う
- DKIM が 実際の送信メール に署名していることを確認する
- 送信に使うすべてのドメインに DMARC を公開する
- 監視から始め、その後強制適用へ進む
- DMARC レポートを集める
- pass/fail だけでなく整列も確認する
- DNS や ESP を変えたら再テストする
- 違和感があるときはヘッダーを見る
- レピュテーションとバウンス傾向を継続監視する
このチェックリストはどんな人向け?
このガイドは次のような方に役立ちます:
- ビジネスサイト
- SaaS プロダクト
- サポート受信箱
- ニュースレターシステム
- トランザクションメール
- コールドアウトリーチキャンペーン
- 代理店が運用するクライアントドメイン
- 独自ドメインのメール転送
- EC の通知
- パスワードリセット / 認証システム
メールがビジネスにとって重要なら、認証も同じくらい重要です。テストに 使い捨てメール を使うなら、認証を理解しているとちゃんと届くプロバイダを選べるようになります。
まとめ
自社ドメインからメールを送るなら、SPF / DKIM / DMARC を確認する方法 を学ぶことは、最も ROI の高い技術スキルの一つです。
これを通じて:
- 受信箱への到達を改善する
- スプーフィングのリスクを下げる
- 迷惑メールに入る理由を診断する
- 隠れた DNS のミスをつかまえる
- メールプロバイダからの信頼を築く
最も重要な学びはこれです:
SPF / DKIM / DMARC のレコードを「持っている」だけでは不十分。有効で、整列していて、実際のメール挙動に対してテストされている必要がある。
ドメインは一見「設定済み」に見えても、本番で失敗することがあります。
だからこそ、もっとも賢いやり方はこうです:
- ドメインを確認する
- レコードを点検する
- ポリシーを検証する
- 実メッセージをテストする
これを地道に続ければ、到達性が悪化する前にほとんどの認証問題を捕まえられます。
よくある質問 (FAQ)
ドメインの SPF はどう確認する?
v=spf1 で始まる DNS TXT レコードを探します。SPF レコードが 1 件のみ で、現在の送信プロバイダが含まれており、10 ルックアップ上限 を超えていないことを確認してください。
ドメインの DKIM はどう確認する?
DKIM の確認には ドメイン と、通常は送信プラットフォームが使う セレクター が必要です。DKIM TXT レコードは有効な公開鍵と適切なフォーマットを持つ必要があり、加えて実際の送信メールが署名されているかも確認すべきです。
ドメインの DMARC はどう確認する?
DMARC を確認するには _dmarc.あなたのドメイン.com の TXT レコードを探します。v=DMARC1 で始まり、p=none / p=quarantine / p=reject のいずれかのポリシーを持つ必要があります。レポート用の rua= も強く推奨されます。
SPF / DKIM / DMARC の最強チェッカーは?
最良のフローは「単一のチェック」ではなく、次の組み合わせです:
- ドメイン単位のメール認証スキャン
- DMARC のダイレクトな検証
- DKIM レコードの検査
- SPF 構造のレビュー
- 実メールヘッダーの解析
これで DNS のビューと実メッセージのビューの両方が手に入ります。
SPF / DKIM / DMARC があるのに、なぜ迷惑メールに入る?
レコードが存在しても、受信箱配信は 保証されない からです。次のような理由で迷惑メール扱いになります:
- 整列の失敗
- DKIM 署名の壊れ
- SPF 構造の弱さ
- ドメインや IP のレピュテーション悪化
- スパムフィルタを刺激する内容
- 苦情やバウンスの高い率
- 強制適用していない DMARC ポリシー
DMARC は SPF と DKIM が必要?
DMARC は SPF と DKIM の両方が正しく設定されているとき、もっとも力を発揮します。技術的には SPF か DKIM のどちらかが整列付きで通れば DMARC を通すことは可能ですが、両方に乗せた方がはるかに堅牢で、推奨されます。
SPF の 10 ルックアップ上限とは?
SPF の評価では DNS ルックアップを最大 10 回 までしか実行できません。include: の使いすぎでこれを超えると、SPF が失敗し、到達性に悪影響を及ぼし得ます。
DMARC は p=none か p=reject か?
導入初期は監視のために p=none が便利です。しかし長期的に p=none のままだと保護が弱くなります。認証が安定してきたら、多くのドメインは p=quarantine や p=reject を目指すべきです。
SPF / DKIM / DMARC があれば到達性は十分?
いいえ。これらは必須ですが、到達性は他にも次のものに依存します:
- ドメインのレピュテーション
- IP のレピュテーション
- 内容の品質
- 苦情率
- バウンス率
- 送信の振る舞い
- リスト衛生
- インフラ品質
認証は土台であって、システム全体ではありません。
あわせて読みたい
Your temp mail is ready right now
No signup, no password. A disposable inbox waiting the moment you open the page.
Get My Free Temp Mail →