メール認証手法：SPF、DKIM、DMARCがドメインをどのように保護するか

メール認証方式とは、主にSPF、DKIM、DMARCといったプロトコルのことで、受信サーバーがメッセージが実際にあなたのドメインから送信されたものであることを確認できるようにするものです。これらがなければ、誰でもあなたの送信者アドレスを偽造することができ、正当なメールがスパムフォルダに振り分けられる可能性が高くなります。

適切に設定すれば、これらの手法はブランドのなりすましを防ぎ、正当なメールを受信トレイに確実に届けるだけでなく、ドメインがどのように利用されているかを正確に把握できるようになります。Google、Yahoo、Microsoft、Appleが大量送信者に対する認証を義務付けている現在、この設定はもはや任意のものではありません。本ガイドでは、主なメール認証手法、それぞれの仕組み、配信率に与える影響、および実装方法について解説します。

複数のドメインを運用しているチームやメール配信サービスを提供しているチームにとって、難しいのはレコードを一度公開することではありません。新しいCRM、マーケティングプラットフォーム、ヘルプデスク、あるいは地域ごとのドメインが追加されるたびに、 SPF、DKIM、DMARC の基盤が変化するたびに、可視性を維持し続けることです。

メール認証とは何ですか？

メール認証とは、メッセージが主張するドメインから実際に送信されたものであり、転送中に偽造されていないことを確認するための一連の手法です。主にSPF、DKIM、DMARCといったこれらの手法は、DNSのTXTレコードとして公開されています。受信サーバーが受信メッセージを検証する際、これらの DNSレコード を参照してドメインの所有権を確認し、メッセージを配信するか、スパムフォルダに振り分けるか、あるいは拒否するかを決定します。

知っておくと役立つ情報

認証は、しばしば3つの関連する概念と混同されがちです。認証は、メッセージの送信者が誰であるかを確認するものです。認可は、送信者が何を行うことが許可されているかを決定するものです。暗号化は、転送中のコンテンツを保護するものです。送信者の評判は、ドメインの送信履歴や苦情発生率を反映したものです。これら4つすべてが配信率に影響を与えますが、認証は他の3つが築かれる基盤となるものです。

主要なメール認証手法：SPF、DKIM、DMARC

これらは、電子メール認証を機能させるための手法であり、それぞれが認証プロセスの異なる部分を担っています。

SPF、DKIM、DMARCは、身元確認の3つの層と考えてください。SPFは、送信サーバーがあなたのドメインからメールを送信する権限を持っていることを確認します。DKIMは、メッセージが送信中に改ざんされていないことを確認します。DMARCは、これらの結果が「From」アドレスと一致しているかを確認し、一致しない場合にプロバイダーがどのように対応すべきかを指示します。

SPF (Sender Policy Framework)

Sender Policy Framework（SPF）は、防御の第一の層です。SPFは、特定のドメインからメールを送信できる許可されたIPアドレスを指定することで、なりすましを防止します。SPFは、受信者が目にする「From」アドレスではなく、メッセージのエンベロープである「Return-Path」に焦点を当てているため、MAIL FROMドメイン内の送信者のみを確認し、受信者が目にする「From」アドレスは考慮しません。一致するIPアドレスは通過し、それ以外は失敗となります。

DKIM (DomainKeys Identified Mail)

SPFは送信サーバーを検証するのに対し、DKIMは送信中にコンテンツが改ざんされていないことを検証します。これは暗号鍵を用いてデジタル署名を追加する仕組みです。つまり、送信元のサーバーが各メッセージに秘密鍵で署名を行い、 DKIM署名 を生成してヘッダーに添付し、受信サーバーはDNSから対応する公開鍵を取得して検証を行います。署名が一致し、コンテンツが改ざんされていない場合、DKIMの検証に合格し、そのメッセージが主張されたドメインから真正に送信されたものであり、送信途中で改ざんされていないことが確認されます。

DMARC（ドメインベースのメッセージ認証、報告および適合性）

DMARCは、これらすべてを統合するプロトコルです。DMARCは、受信メールがSPFまたはDKIMの検証に合格しているか、またそれらの検証で使用されたドメインが「From」アドレスと一致しているかを確認します。この一致要件こそが、SPFやDKIMだけでは見逃されてしまうなりすましメールをDMARCが効果的に検知できる理由であり、また検証に失敗した場合に受信システムが取るべき措置を規定しています。

DMARCポリシーのオプションは、あらかじめ定められた順序で実行されます：

• p=none: 監視のみ。すべての送信者における認証結果の集計レポートを受け取る一方で、メッセージ自体には影響がありません。これが推奨される初期設定です。
• p=隔離: 失敗したメッセージはスパムまたは迷惑メールフォルダに振り分けられます。正当な送信者からのメッセージがすべて正常に通過することを確認できたら、この設定を使用してください。
• p=reject: 失敗したメッセージは受信サーバーでブロックされます。これは最も厳格なレベルであり、ドメインをなりすましから完全に保護します。

また、DMARCでは2種類のレポートが生成されます。1つは、すべての送信者に関する結果をまとめたRUA集計レポート、もう1つは、失敗に関するメッセージレベルの詳細情報を提供するRUFフォレンジックレポートです。これらはいずれも、DMARCレコードに指定されたアドレス宛てにXML形式で配信されます。

その他の手法：ARC、MTA-STS、TLS-RPT、およびBIMI

中核となる3つのプロトコルで、ほとんどのニーズをカバーしています。さらに4つのプロトコルが、特定のシナリオ（転送、暗号化トランスポート、トランスポート可視性、ブランド表示）に対する保護機能を拡張しています。

ARC（認証済み受信チェーン）

メーリングリストやチケットシステム、その他の仲介サービスを通じてメールを転送する場合、転送されたメッセージがSPFやDKIMの検証に失敗することがあります。 ARC は、各中継ポイントで元の認証結果を保持することでこの問題を解決します。メッセージが信頼できる仲介サーバーを通過する際、ARCは各ステップでの結果を記録し、暗号的に署名されたチェーンを作成します。これにより、転送によって元の署名が破損した場合でも、最終サーバーはこのチェーンを検証することで、メールが当初認証されていたことを確認できます。これは DMARCの失敗の一般的な原因となっています。

MTA-STS（メール転送エージェント厳密トランスポートセキュリティ）

MTA-STS は、メールサーバー間のSMTP接続を暗号化することを義務付けており、これにより、攻撃者が中間者攻撃（Man-in-the-Middle）によって通信を傍受したり、平文にダウングレードしたりすることを防ぎます。設定されると、送信サーバーに対して TLS 暗号化を使用してメールをあなたのドメインに配信するよう指示し、安全な接続が確立できない場合は配信を拒否します。

ホスト型MTA-STSおよびTLS-RPTサービスは、ポリシーファイルの手動でのホスティングやトランスポートレポートの解析が不要になるため、導入を簡素化します。これにより、コンプライアンス対策として暗号化された通信を必要とする金融、医療、公共部門の組織を支援します。

TLS-RPT（SMTP TLS レポート）

TLS-RPT を使用すると、ドメイン所有者は TLS 暗号化に関連する配信の問題を可視化でき、メッセージが安全に配信できなかったタイミングを確認できます。MTA-STS と併用することで、チームはダウングレード攻撃、ポリシーの設定ミス、証明書の不具合をより迅速に特定できるようになります。これがない場合、暗号化の失敗は黙って発生し、安全な接続が確立できなかったという兆候は一切現れません。

BIMI（メッセージ識別用ブランド指標）

BIMI は、受信者の受信トレイにおいて、認証済みのメッセージの横に検証済みのブランドロゴを表示し、その正当性を視覚的に証明します。この機能を利用するには、ドメインに DMARCポリシー として、少なくとも p=quarantine以上の設定が必要です。このロゴはブランド認知度を高め、受信者が本物のメールを即座に識別できるよう支援し、開封率の向上につながります。また、BIMI以上の設定が必要です。このロゴはブランド認知度を高め、受信者が本物のメールを即座に識別できるようになるため、開封率の向上につながります。また、BIMIは ロゴのなりすまし の標的となります。

Gmailで青いチェックマークを表示するには「Verified Mark Certificate（VMC）」が必要ですが、VMCを活用したホスト型BIMIを利用すれば、手動での設定作業を軽減できます。設定の準備ができている方は、こちらの BIMIレコードの公開方法 の手順を解説しています。

メール認証の仕組み

認証は、送信側サーバーと受信側サーバーの間で一連の自動チェックとして実行されます。エンドツーエンドの流れは次のようになります。

1. 送信者がメッセージを送信します。 あなたのメールサーバーは、あなたのドメインに代わってメールを送信します。
2. 受信サーバーはDNSに問い合わせを行います。 受信サーバーは、送信元のドメインのDNSレコードを検索し、SPF、DKIM、およびDMARCの設定を確認します。
3. SPFチェック。 サーバーは、送信元のIPアドレスがドメインのSPFレコードに許可されたアドレスとして登録されているかどうかを確認します。一致すれば合格となります。
4. DKIM チェック。 サーバーはDNSからDKIM公開鍵を取得し、メッセージヘッダーの暗号署名を検証します。改変されていないコンテンツに対する有効な署名であれば、検証に合格します。
5. DMARCのアラインメントおよびポリシーチェック。 DMARCは、SPFまたはDKIMに合格したドメインが、表示されている「From」ドメインと一致しているかどうかを確認します。一致しない場合、そのドメインのポリシー（none、quarantine、またはreject）が適用されます。
6. 最終的な配信決定。 プロバイダーは、メッセージを配信、隔離、または拒否し、DMARC集計レポートをドメイン所有者に送信します。

メール認証が重要な理由とは？

認証を省略すると、5つの分野にわたってビジネス上の重大なリスクが生じ、それらは相互に悪影響を及ぼし合う傾向があります。認証の脆弱性が、単発の問題としてのみ発生することはほとんどありません。

ブランドの評判を守ります

認証を行うことで、詐欺師があなたのドメインを利用して詐欺メッセージを送信することを防ぐことができます。 攻撃者があなたのドメインを偽装すると、受信者はその フィッシング攻撃を をあなたのブランドと結びつけてしまうのです。たとえあなたがそれとは何の関係もなかったとしても。これを防ぐことは、顧客の信頼を維持する上で極めて重要です。

フィッシングおよびなりすましを防止します

SPF、DKIM、DMARCは連携して、メッセージが受信者に届く前に送信者の身元を確認するため、信頼されているブランドになりすますことがはるかに困難になります。これらの検証がなければ、攻撃者は自由に送信者アドレスを偽造し、ビジネスメール詐欺キャンペーンを展開することができます。 フィッシングとスプーフィングの区別 の区別はここで重要です。なぜなら、認証は、フィッシングを説得力のあるものにするスプーフィングに対処する手段だからです。

メールの配信能力の向上

認証済みのメールは、GmailやOutlookなどのメールプロバイダーによってスパムとして判定される可能性が低いため、正当なメッセージが受信トレイに届くようになります。現在、多くのプロバイダーでは DKIMおよびDMARC を配信の必須条件としており、これらの基準を満たすことで受信トレイへの到達率が向上します。

コンプライアンス要件を満たす

Google、Yahoo、Microsoft、Appleはいずれも、1日あたり5,000通以上のメールを送信するドメインに対してSPF、DKIM、DMARCの採用を義務付けており、Googleは2025年11月以降、基準を満たさないメールを拒否するという形で厳格に適用しています。

金融、医療、教育、小売、公共部門などの規制対象業界において、認証は、より広範なコンプライアンスおよびリスク管理プログラムの推進にも寄与しています。Google、Microsoft、PCI DSS、GDPRに準拠したプログラム、および各地域の政府による規制要件では、SPF、DKIM、DMARCが「ベストプラクティス」ではなく、不可欠な管理措置として扱われる傾向が強まっています。

可視性と制御を提供します

特にDMARCは、自社のドメインがメール送信にどのように利用されているかについてレポートを提供します。これらのレポートにより、不正な送信者、認証の失敗、なりすまし試行などが明らかになり、これらは対応すべき重要なデータとなります。認証が行われない場合、送信インフラ全体におけるメールのパフォーマンスやセキュリティ状況を把握することはできません。

戦略的優位性として機能する

メール受信サービスプロバイダーは、適切に認証された送信者をますます優遇するようになっています。この点を適切に実施している組織は、受信者からの信頼を強め、配信トラブルを減らし、送信インフラを悪用から保護することができるため、そうしていない競合他社よりも優位に立つことができます。

メール認証の実装方法

実装には、受信サーバーがドメインから送信されるすべてのメッセージの有効性を確認するために使用するDNSレコードの設定が必要です。最初のTXTレコードの設定から完全な適用に至るまで、5つの手順を順を追って進めてください。

1. 送信インフラを監査してください。 ドメインを代表してメールを送信するすべての送信元（プライマリメールサーバー、マーケティングオートメーション、CRM、ヘルプデスク、請求システム、およびトランザクション処理プロバイダーなど）を洗い出してください。認証エラーの多くは見落とされた送信元に起因するため、このステップによって導入環境の健全性が決まります。
2. SPFレコードを公開してください。 承認されたすべてのIPアドレスおよび送信サービスを一覧にした単一のTXTレコードを作成してください。各項目は10件の検索制限にカウントされ、制限を超えるとすべてのメッセージでSPF検証に失敗します。
3. DKIM署名を設定します。 プロバイダまたはメールサーバーを通じて鍵ペアを生成します。秘密鍵は送信サーバーに残され、送信メールに署名を行います。公開鍵はTXTレコードとしてDNSに登録され、受信者が各署名を検証できるようになります。
4. DMARCレコードを追加してください。 適用を開始する前に結果を確認できるよう、監視専用の p=none ポリシーから始めて DMARC TXT レコードを公開してください。基本的なレコードは、v=DMARC1; p=none; rua=mailto:[email protected]; fo=1 のようになります。
5. テストと検証を行います。 ステップ1で特定したすべての送信元からテストメールを送信し、「Authentication-Results」ヘッダーを確認して、SPF、DKIM、DMARCの判定結果を確認する。

よくある間違い

SPFやDMARCレコードのサンプルをそのままDNSにコピーすること。上記の例はテンプレートであり、そのまま使用できるレコードではありません。使用していないサービスが含まれたSPFレコードは、10件というルックアップ上限を無駄に消費してしまいます。また、誰も管理していないレポート用メールボックスを指すDMARCレコードでは、集計データがどこにも送信されません。公開する前に、自社の送信元およびレポート用アドレスに合わせて、それぞれを調整してください。

SaaSプラットフォームの蓄積に伴い、検索上限を超えて増加するレコードに対しては、 SPFフラット化ツール が自動的に制限範囲内に収めてくれます。レコードが公開されたら、 ドメインアナライザー を使用して、SPF、DKIM、DMARCの設定全体を数秒で検証してください。

よくある認証エラーとその対処法

通常、送信環境が変化した際に問題が発生します。新しいSaaSツール、地域ごとの送信元、転送サービス、DNSの設定変更などは、すべてSPF、DKIM、DMARC、および転送時のセキュリティに影響を及ぼします。以下に、最も一般的なシナリオとその対処法を示します。

メール認証のベストプラクティス

レコードを公開することは第一歩に過ぎません。長期にわたって強力な認証を維持するには、いくつかの習慣を継続的に実践する必要があります。

監視から始め、その後で強制する

配信に影響を与えずにデータを収集するには、p=none から開始してください。レポートを分析して正当な送信者をすべて特定し、設定ミスを修正した後、信頼度が高まるにつれて、段階的に p=quarantine および p=reject へと移行してください。

SPFレコードを最新の状態に保ち、制限範囲内に収める

送信サービスを追加または削除するたびに、SPFレコードを更新してください。レコードが古いままだと、正当なメールが配信失敗となるためです。スタックが拡大するにつれて、10件というルックアップの上限に注意してください。この上限を超えると、 SPFチェック がすべてのメッセージに対して失敗する原因となります。多数のSaaSプラットフォームを運用している組織は、SPFの複雑さを継続的に監視し、送信元が増えるにつれて障害が発生しないよう、自動管理やフラット化を活用すべきです。

DKIMキーを定期的に更新する

DKIMキーをローテーションすることで、キーが漏洩するリスクを軽減できます。ベストプラクティスとしては、6～12か月ごとにローテーションを行うことですが、秘密鍵が漏洩した疑いがある場合は直ちにローテーションを行う必要があります。

よくあるご質問

メールサービスプロバイダーを利用する場合、SPF、DKIM、DMARCは必要ですか？

はい。多くのメール配信サービス（ESP）は、多数の顧客間で送信インフラを共有しているため、デフォルトの設定ではお客様のドメインが完全に認証されない場合があります。SPF、DKIM、DMARCレコードはお客様ご自身で公開していただき、DKIM署名の設定についてはメール配信サービス（ESP）がサポートします。

どのプロトコルを最初に設定すればよいでしょうか？

SPF、次にDKIM、そしてp=noneのDMARCの順です。DMARCはSPFまたはDKIMの結果に基づいて機能するため、他の2つが導入されていない状態でDMARCだけを先に公開しても、照合する基準が何もありません。

認証と暗号化の違いは何ですか？

認証は、メッセージの送信者が誰であるか、およびメッセージが改ざんされていないかを確認します。暗号化は、転送中のコンテンツを保護します。MTA-STSとTLS-RPTは暗号化の側面を、SPF、DKIM、およびDMARCは身元の確認を担当します。

転送したメールの認証が失敗するのはなぜですか？

メーリングリストやチケットシステムを経由して転送すると、元のSPFやDKIMの署名が破損する可能性があります。ARCは各中継ポイントで元の結果を保持するため、ARCをサポートする受信サーバーは引き続きそのメッセージを信頼することができます。

認証が有効になるまでどれくらいかかりますか？

DNSの変更は、TTLに応じて数分から数時間以内に反映されます。送信元全体で有意義なDMARCレポートデータを蓄積するには、数日から数週間かかります。

p=reject に直接進んでもいいですか？

この設定は強く推奨されません。p=none での監視期間を設けないと、どの正当な送信者が送信に失敗しているのかが判別できず、安易に拒否設定に切り替えると、自社の請求書や取引関連のメールがブロックされてしまう可能性があります。

• について
• 最新記事

マイサム・アル・ラワティ

サイバーセキュリティの専門家、CEO（ PowerDMARCのCEO

マイサムは技術起業家であり、サイバーセキュリティの専門家であり、15年以上の業界経験を持つPowerDMARCのCEO兼創設者である。Maithamはマンチェスター大学でグローバルMBAを取得し、CISSP、CISM、CRISC、ISC2 CCSPなど様々な専門資格を持つ。

最新記事 by Maitham Al Lawati(全て見る)

• メール認証手法：SPF、DKIM、DMARCがドメインをどのように保護するか - 2026年8月9日
• DMARCポリシーとは？「なし」、「隔離」、「拒否」 - 2026年7月27日
• Dmarcコンプライアンス：その概要、重要性、および確認方法 - 2026年7月21日