SPF 対 DKIM：その違いとは？両方必要なのか？

はじめに

SPFの検証に失敗するケースの多くは、レコードの設定ミスによるものではなく、メールが転送されたことが原因です。

あるIT管理者がSPFを正しく設定し、検証に合格したことを確認して作業完了としたところ、あるユーザーがサードパーティのリレーを経由してメッセージを転送しました。受信サーバーは、許可リストにないIPアドレスを検知し、検証に失敗しました。管理者がレコードを確認したところ、問題はないように見えました。問題はレコードそのものではなく、SPFの仕組みにあるのです。

SPFだけでは電子メールの認証には不十分であり、SPFとDKIMは同じ目的を果たすものではありません。それぞれのプロトコルは、電子メール配信プロセスの異なる層を保護しています。どちらかを削除してしまうと、転送インフラや攻撃者が、それぞれ異なる方法や理由で悪用できる脆弱性が生じてしまいます。

このブログ記事では、SPFとDKIMの違い、転送処理によって一方は機能しなくなるのに対しもう一方は機能し続ける理由、そしてDMARCが機能するために両方が必要な理由について解説します。

SPFとは何か、その仕組みは？

SPF（Sender Policy Framework）は、ドメイン所有者が、そのドメインに代わってメールを送信する権限を持つメールサーバーを指定できるメール認証プロトコルです。

このドメインは、DNSにSPFレコードを TXTエントリ として公開します。受信メールサーバーがメッセージを受信すると、送信元のドメインをこの公開レコードと照合し、送信サーバーが許可されていることを確認します。 

この結果に基づき、受信側はメッセージを受け入れるか、フラグを立てるか、または拒否するかを決定します。SPFは、スパマーや攻撃者が送信者アドレスを偽造することを防ぎ、 メールのなりすましやフィッシングを。SPFは、DKIMやDMARCと連携してメッセージの正当性を検証します。 

SPFの確認項目

SPFは、メッセージを送信するサーバーが、送信元として主張しているドメインのメールを送信する権限を持っているかどうかを確認します。これは、受信サーバーが着信接続を受け入れた瞬間、メッセージ本文を処理する前に行われます。

ただし、SPFは受信者が実際に目にする「From」アドレスを確認するわけではありません。SPFが確認するのは、エンベロープ送信者（Return-PathやMAIL FROMとも呼ばれる）のみであり、これはSMTP通信の舞台裏で使用されるアドレスです。 

つまり、攻撃者はエンベロープドメインのSPFを通過させつつも、受信トレイには偽造された「From」アドレスを表示させることが可能です。DMARCは、SPFの結果を目に見える「From」ドメインと紐付けることで、この脆弱性を解消するのに役立ちます。

受信サーバーは2つの入力を受け取ります： 

1. 送信元のIPアドレス
2. 差出人のドメイン

その後、DNSでそのドメインのSPFレコードを検索します。そして、レコードに定義された手順に従って処理を進めます。具体的には、 ip4、 ip6、 a, mx,および include。送信元IPが許可された送信元と一致する場合、SPFは合格となります。これが終了タグの all メカニズムまで一致が見つからない場合、結果は当該メカニズムの設定方法によって異なります。

SPFは単純な「はい」または「いいえ」を返すわけではありません。以下のいずれかの結果を返します：

• 合格: サーバーの認証に成功しました。
• 失敗 (-all): 権限がありません。このメールを拒否したいのです。
• SoftFail (~すべて): おそらく権限がありません。受け入れますが、不審なものとマークします。
• 中立 (?all): どちらの主張もしていません。
• なし: ドメインにSPFレコードが存在しません。
• PermError / TempError: レコードが破損しているか、DNSの問題により検索がブロックされました。

受信サーバーは、この結果をDKIMやDMARCと併せて一つの指標として扱い、メッセージが配信、警告、または拒否される前に、そのメールの正当性を判断します。 

DKIMとは何か、その仕組みは？

DKIM（DomainKeys Identified Mail）は、ドメインから送信されるすべてのメッセージに暗号署名を付加する電子メール認証プロトコルです。送信サーバーは秘密鍵を使用してメッセージに署名し、その署名をメールのヘッダーに追加します。ドメイン側は、対応する公開鍵をDNSのTXTレコードとして公開します。 

受信サーバーがメッセージを受信すると、その公開鍵を取得して署名を検証します。有効な署名があれば、次の2点が確認されます： 

1. そのメッセージは、記載されたドメインから実際に送信されたものです
2. 輸送中に内容に変更は生じませんでした。 

DKIMは、メッセージの改ざんや送信者のなりすましを防ぐために存在し、SPFやDMARCと連携してメッセージの正当性を確認します。 

DKIMが署名する対象

DKIMは、各メッセージの2つの部分、つまり指定されたヘッダーフィールドとメッセージ本文に署名を行います。エンベロープや接続元のIPアドレス、あるいはこれら2つの領域以外の要素には署名を行いません。これが2つのプロトコルの違いです。SPFはエンベロープと送信サーバーを検証するのに対し、DKIMはメッセージそのものに署名を行うのです。

署名は生のテキストには適用されません。送信サーバーは、本文と指定されたヘッダーをハッシュ化し、そのハッシュを自身の秘密鍵で暗号化します。その結果はDKIM-Signatureヘッダーに格納され、サーバーはこれをメッセージに追加します。そのヘッダー内には、何が署名されたのかを受信者に正確に伝えるためのいくつかのタグが含まれています：

• h= 署名に含まれるヘッダーフィールド（From、To、Subject、Dateなど）を一覧表示します。
• bh= には、メッセージ本文のハッシュ値が格納されます。
• b= には、署名そのもの、つまり署名されたヘッダーの暗号化されたハッシュが格納されています。
• c= 正規化を設定します。これにより、空白や書式がどの程度厳密に一致する必要があるかが決まります。

「From」ヘッダーには常に署名が付いています。DKIMではこれが必須となっています。その理由は、署名を、受信者が実際に目にするドメインと結びつけることが目的だからです。

h= に記載されていないものは保護されません。ヘッダーがそのリストに含まれていない場合、署名を無効にすることなく、転送中に変更される可能性があります。本文は、オプションの l= タグによって署名が本文の先頭部分のみを対象とするように制限されていない限り、完全に保護されます。そのため、一般的に l= の使用は推奨されません。署名された長さの後に追加されたコンテンツは、署名されずに通過してしまいます。

受信サーバーがDKIMを確認する際、本文のハッシュとヘッダーのハッシュを再計算し、公開鍵を使用してb=を復号し、これらを比較します。両者が一致すれば、署名は有効であり、メッセージの署名付き部分は改ざんされずに届いたことになります。

SPF 対 DKIM

SPFとDKIMは、それぞれ異なる問題を解決します。SPFは、どのサーバーがあなたのドメインのメールを送信することを許可されているかを認証するものであり、一方DKIMは、暗号署名を用いて、メッセージが改ざんされておらず、実際にあなたのドメインから送信されたものであることを証明するものです。ここでは、SPFとDKIMの違いについて簡単に説明します。

どちらのプロトコルも、相手が何を知っているかを知らない。

SPFは、メッセージが認証済みのサーバーから送信されたことを確認できますが、そのメッセージがサーバーを離れてしまえば、SPFはその後の状況について把握できません。 

同様に、DKIMはコンテンツが無傷で届いたこと、および署名を行ったドメインが秘密鍵を管理していたことを確認できますが、そもそもそのサーバーに送信の権限があったかどうかについては何も示していません。

受信サーバーが両方の結果を評価する場合、その意味は次のとおりです：

DMARCは両方の結果を読み取り、 From ドメインとの整合性に基づいて、公開されたポリシーを適用します。そのため、これら2つのプロトコルは競合するのではなく、互いに補完し合うように設計されています。

なぜSPFは転送時に機能しないのに、DKIMは機能するのでしょうか？

SPF転送の問題

SPFは、 メールが転送されると。これは、正当なメッセージがSPF検証に失敗する最も一般的な理由の一つであり、プロトコルの仕組みそのものに起因しています。

SPFは、接続元のサーバーのIPアドレスを、エンベロープ送信者のドメインのSPFレコードと照合します。転送を行うと、この照合が成立しなくなります。サーバーがメッセージを転送すると、次の3つのことが起こります：

1. 転送サーバーが新しい接続元IPアドレスとなります。
2. エンベロープ送信元は、依然として元の送信元のドメインを指しています。
3. 元のドメインのSPFレコードに転送サーバーが記載されていないため、チェックの結果は「失敗」となります。

たとえば、あなたのドメインから送信されたメッセージが、最初のホップでSPFの検証を通過したとします。その後、受信側のサーバーがそのメッセージを、同窓生用アカウントやメーリングリストなどの別のアドレスに転送します。この2番目の宛先では、接続元のIPアドレスは転送サーバーのものになりますが、Return-Pathには依然としてあなたのドメインが表示されます。あなたのSPFレコードはそのサーバーを承認していないため、メッセージ自体は本物であっても、SPF検証は失敗してしまいます。

これは主に次のような場合に現れます：

• メーリングリスト
• GmailまたはOutlookのアカウント単位の自動転送ルール
• 卒業生または役割に基づく転送先アドレス
• メールを中継するスパムフィルターおよびゲートウェイ

転送メールが拒否されない理由は、次の2つです：

1. SRS（Sender Rewriting Scheme）： 転送サーバーは、メッセージを中継する前に、Return-Path を自身のドメインに書き換えます。その後、SPFは転送元のドメインに対して検証を行いますが、そのドメインは当該サーバーを承認しているため、検証は通過します。信頼できる転送サービスの多くは、SRSを自動的に適用しています。
2. DKIMとDMARC： 転送者が署名済みのコンテンツを変更しない限り、DKIM署名は転送後も有効です。したがって、転送されたメッセージでSPFが失敗した場合でも、DKIMは通過し得るため、DMARCではこの2つのうち1つが一致していれば十分です。これが、SPFのみに依存すべきではない主な理由です。

なぜDKIMは転送時にも機能し続けるのか

DKIMは、メッセージの経路ではなくメッセージ自体に署名を行うため、転送を経ても有効性を維持します。署名はDKIM-Signatureヘッダー内に格納されているため、メールが各ホップを経由するたびに一緒に移動します。メッセージがいくつのサーバーを経由して転送されたとしても、最終的な宛先に到達した時点で署名は依然として残っています。

検証は、接続元のサーバーにも依存しません。受信側は、署名ドメインのDNSからそのドメインの公開鍵を取得し、それを使って署名を検証します。メッセージを送信したIPアドレスは関係ありません。これはSPFとは正反対の仕組みです。SPFは接続元のIPアドレスをチェックするため、転送が行われるとIPアドレスが変更され、検証に失敗してしまいます。

フォワーダーが署名付きの内容を変更せずにメッセージを転送する限り、本文のハッシュとヘッダーのハッシュは一致したままであり、DKIMの検証に合格します。

DKIMは単純な転送には耐えますが、あらゆるケースに対応できるわけではありません。中継者が署名済みのコンテンツを変更すると、署名は無効になります。最もよくある例はメーリングリストで、そこではしばしば：

• 本文にフッターまたは配信停止リンクを追加する
• 件名に [リスト名] のようなタグを追加してください
• 署名内に含まれるヘッダーを書き換えるか、挿入する

これらのいずれかの変更が行われるとハッシュが変化し、署名は無効になります。 ARC（Authenticated Received Chain） はまさにこのようなケースのために作成されたもので、メッセージがそれを変更する仲介者を経由する際にも、元の認証結果が保持されるようになっています。

これが、DMARCの下で転送メールにおいてDKIMが重要となる理由です。DMARCは、SPFまたはDKIMのいずれかが有効であり、かつ「From」ドメインと整合している場合に合格となります。転送されたメッセージでは通常SPFが失敗するため、DKIMが鍵を握るのです DMARCの一致 を支える重要な要素となります。署名ドメインは転送後も変わらないため、整合性も維持されます。SPFのみに依存している場合、自社ドメインからの転送メールでもDMARC検証に失敗し、スパムフォルダに振り分けられる可能性があります。

SPF、DKIM、DMARCはどのように連携して機能するのでしょうか？

SPFとDKIMはそれぞれ異なる問題を解決しますが、単独では何も強制しません。DMARCは、これら2つのチェック結果を特定のアクションに結びつけ、受信者が実際に目にするドメインに紐づける役割を果たします。

受信サーバーが受信メッセージを解析すると、次のような処理が行われます：

1. SPFが先に実行されます： サーバーはエンベロープ送信者、すなわち MAIL FROM アドレスを読み取り、受信者が目にするFromヘッダーではなく、その送信IPをSPFレコードと照合します。IPが許可されている場合、SPFは通過します。そうでない場合、失敗します。
2. 次にDKIMが実行されます： サーバーは DKIM-Signature ヘッダーを読み取り、セレクタとドメインタグを使用してDNSから公開鍵を検索し、メッセージの内容に対して暗号署名を検証します。有効な署名があれば、そのメッセージが秘密鍵を管理するドメインから送信されたものであり、転送中に改ざんされていないことが確認されます。
3. DMARCの評価は最後に実行されます： 保険契約の記録を取得し、整合性を確認します：
   1. SPFを通過したドメインは、送信元ドメインと一致していますか？ 
   2. 次の DKIM署名内の タグは、送信元ドメインと一致していますか？ 

どちらかが一致すれば、DMARCは合格となります。その後、公開されているポリシーに基づいて、そのメッセージの処理が決定されます。

「アライメント」が実際に何を意味するのか

SPFは、エンベロープ送信者に記載されたすべてのドメインを通過させることができます。DKIMは、有効な署名鍵を持つすべてのドメインを通過させることができます。これら単独でのチェックでは、「From」ヘッダー（表示されるフィールド）の正当性は確認されません。 [email protected] と表示される「From」ヘッダーが正当であるかを、単独では確認できません。DMARCは、認証されたドメインと「From」ドメインを照合することで、その検証を追加します。

アライメントには2つのモードがあります：

1. デフォルトのリラックスモードでは、組織ドメインの一致だけで十分であり、 mail.yourcompany.com が yourcompany.comと一致すれば十分です。 
2. 厳格モードでは、ドメインが完全に一致する必要があります。厳格モードでは、すべての送信元が正確に設定されていない限り、サブドメインの配信に問題が生じるため、多くの組織では緩和された設定を採用しています。

正規メールとなりすましメールの結果

正しく設定された正規のメッセージの場合：

• 送信元のIPアドレスがSPFレコードと一致しています → SPF検証に合格
• DKIM署名が有効です、 d= 送信元ドメインと一致 → DKIM 検証に合格
• どちらの結果も、「送信元ドメイン → DMARC 合格」という状況と一致しています
• あなたの p=reject ポリシー → メッセージが配信される

有効な署名鍵を持たない不正なサーバーから送信された偽装メッセージの場合：

• 許可されていないIP → SPF検証に失敗
• 有効な署名がありません → DKIM 検証に失敗しました
• どちらの結果も、「送信元ドメイン → DMARC 検証に失敗」という状況とは一致しません
• あなたの p=reject ポリシー → メッセージは受信トレイに届く前に拒否される

そのため、DMARCの下では、SPFとDKIMを併用する方が、どちらか一方だけを使用するよりも効果的です。DMARCは、どちらかの検証に合格すれば通過判定となるため、転送メールでSPFの検証に失敗した場合でも、DKIMの検証に合格していれば、正当なメッセージはDMARCを通過できます。なりすましメールで両方の検証に失敗した場合は、DMARCがポリシーに基づいて対応します。

ドメインが p=quarantine または p=reject となり、かつSPFとDKIMの両方が通過し整合が取れている場合、 BIMIの適用要件も満たしています。BIMIとは、GmailやApple Mailなどの対応メールボックスに、認証済みのブランドロゴを表示する規格です。

SPFとDKIMの両方が必要ですか？

はい、SPFとDKIMの両方が必要です。 

DKIMを使用せずにSPFのみを実行しているドメインでは、メッセージレベルの完全性検証が行われません。送信中に内容が改ざんされていないことを確認する手段がありません。また、DMARCを提供するためのDKIMとの連携も行われていないため、SPFが失敗した場合（転送されたメールでは必ず失敗します）、DMARCには代替手段がありません。ユーザーの職場の受信箱と個人アカウントの間でたった1つの転送ルールが設定されているだけで、完全に正当なメールであっても認証が機能しなくなってしまいます。

GoogleとYahooは2024年2月に、これら両方を必須とした。

Googleでは、1日あたり5,000通以上のメールを送信するすべての大量送信者に対し、SPF、DKIM、およびDMARCレコードの設定を義務付けています。Yahoo!では、SPFまたはDKIMのいずれか1つに加え、DMARCの設定が必須ですが、いずれか1つだけを導入した場合、Googleの要件も同時に満たせなくなります。両プラットフォームの受信者にメールを送信する場合、すべての要件を一度に満たすには、両方の設定を行うしかありません。

5,000通という閾値を下回る場合でも、これらの要件は事実上、主要なメール受信プロバイダー全体における配信基準となっています。 

それぞれがカバーしている、もう一方がカバーできない点：

RFC 7208の規定により、転送されたメールではSPF検証が意図的に失敗します。転送サーバーのIPアドレスが元のIPアドレスに置き換わるため、そのIPアドレスが許可リストに含まれていないと、実際には問題がないにもかかわらず検証に失敗します。一方、DKIMはIPアドレスの変更を問題としません。署名はメッセージと共に転送され、内容が変更されていない限り、どのサーバーを経由したかに関わらず検証に成功します。

DKIMは、メッセージが改ざんされていないこと、および署名ドメインが秘密鍵を管理していることを確認しますが、メッセージを送信したサーバーにネットワークレベルの送信権限があるかどうかについては何も示しません。その確認はSPFが行います。

どちらのサーバーも、もう一方のサーバーが何を知っているかは把握していません。両方を運用することで、受信サーバーはメールを解析する際、情報の一部ではなく、全体像、正当な経路、そして完全なコンテンツを把握できるようになります。

SPFとDKIMの設定方法：ステップバイステップガイド

ドメインにまだSPFとDKIMが設定されていない場合でも、設定手順は簡単です。以下の手順に従えば、両方のプロトコルを設定し、検証することができます。 

ステップ1：SPFレコードを作成する

まず、あなたのドメインからメールを送信する権限を持つすべてのサービスを以下のようにリストアップしてください：

1. メインのメールサーバー
2. マーケティングプラットフォーム
3. CRM
4. ヘルプデスクツール
5. トランザクションメールのプロバイダー、およびお客様に代わってメールを送信するその他のサービス。

各承認済みサービスには、 include: SPFレコード内のメカニズム、または ip4: または ip6:を使用して直接IP範囲を指定することも可能です。レコードの末尾には -all でレコードを終了し、リストにないIPはすべて許可されていないことを受信サーバーに通知します。

IP範囲を直接追加する前に ip4: または ip6:を使用してIP範囲を直接追加する前に、その範囲が正しい送信サービスに属していることを確認してください。 PowerDMARCのWHOIS IP検索 を使用すれば、レコードに反映される前にIPの所有者を確認できます。 

基本的なSPFレコードは、次のような形式になります：

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

サービスを追加する際は、DNS 照会回数に注意してください。RFC 7208 では、SPF 評価における照会回数は 10 回までに制限されています。各 インクルード: メカニズムは少なくとも1回を消費し、ネストされたincludeも同様の制限にカウントされます。多くのドメインでは、4つや5つのサードパーティ送信者を同時に稼働させると、予想以上に早く制限に達してしまいます。

PowerDMARCの無料 SPFジェネレーター を使って、構文を手動で記述することなくレコードを作成し、 PowerSPF を使用すれば、送信インフラが変更されても、自動的に10ルックアップの上限内に収めることができます。

ステップ2：DKIMキーの生成と公開

ユーザーに代わって送信を行う各サービスについて、DKIMキーペアが必要です： 

1. 送信サーバーが送信メールに署名するために使用する秘密鍵
2. 受信サーバーが検証できるように、DNSに公開された対応する公開鍵。

Google Workspace や Microsoft 365 などのサービスが DKIM 署名に対応している場合、それらのサービスから公開鍵レコードとセレクタ名が提供されます。このレコードを DNS の selector._domainkey.yourdomain.com にレコードを公開し、サービスの管理コンソールで署名を有効にしてください。

鍵を自身で生成する環境では、少なくとも2048ビットのRSAを使用してください。1024ビットではもはや不十分とされています。PowerDMARCの無料 DKIMジェネレーター は、コマンドラインツールを必要とせずに、すぐに公開できるDNSレコードを生成します。

複数の送信サービスでDKIMを管理している場合、 Hosted DKIM なら、鍵の生成、DNSへの公開、ローテーションを一元的に管理でき、鍵を変更するたびに手動でDNSを編集する必要がありません。

ステップ3：DMARCレコードを追加する

SPFとDKIMの設定が完了したら、DNSにDMARCレコードを追加してください。まずは p=none から開始し、メールの配信に影響を与えることなく集計レポートデータを収集してください。

最低限の初期レコード：

v=DMARC1; p=none; rua=mailto:[email protected];

p=none は、なりすましメッセージをブロックしません。DMARCを監視モードに設定するため、どの送信元が認証に合格し、どの送信元が不合格であるかを示す集計レポートを受け取ることができますが、メールが隔離されたり拒否されたりすることはありません。 

そのデータを活用して設定ミスや整合性の問題を特定し、次に p=隔離 を経て、最終的に p=rejectに進みます。

次のURLにあるドメイン p=none の状態が継続しているドメインは、なりすましから保護されません。監視フェーズには、期限の定めのない期間ではなく、明確な終了時点が必要です。

ステップ4：設定の確認

レコードを公開した後、設定が完了したとみなす前に、各レコードが正しく解決されていることを確認してください。

レコードが正しく解決されることは必要ですが、それだけでは不十分です。実際のテスト送信を行い、認証ヘッダーがエンドツーエンドで正常に通過していることを確認してください。 PowerDMARCのSMTPテストツール を使用すると、メールサーバーへの接続をテストし、 SPF、DKIM、およびDMARC が、DNS上だけでなく実際の送信メールでも通過しているかを確認できます。 

よくある間違い

本番環境で認証エラーを引き起こす最も一般的な2つのミスは次のとおりです： 

SPF 10 - 照会制限

SPFでは、受信サーバーがレコードを評価する際に、RFC 7208で定められた上限である最大10回のDNSルックアップが許可されます。 受信サーバーがレコードを評価する際、RFC 7208で定められた制限により、最大10回のDNSルックアップが行われます。「include」、「a」、「mx」などのメカニズムはそれぞれルックアップをトリガーし、これらはネストされます。 

ほとんどのドメインは、サードパーティの送信者を積み重ねることで10件の制限を簡単に超えてしまいます。これは、インクルードで認証するサービスごとにルックアップが消費されるためです。制限を超えると、SPFは PermErrorを返し、受信サーバーはこれを、もはやメールを承認しない無効なレコードとして扱います。 

フラット化 これを修正するには、インクルードの仕組みを、それらが解決される実際のIPv4およびIPv6の範囲に置き換え、ルックアップ回数をゼロに近づけるようにします。

DKIM キーのローテーション

DKIMキーのローテーションとは、予定に従ってDKIMキーペアを更新し、古い秘密鍵を無効にして、その代わりに新しい公開鍵を公開する手順のことです。ローテーションを行うことで、個々のキーが公開される期間を制限できるため、万が一キーが漏洩した場合でも、被害の範囲を最小限に抑えることができます。多くのチームでは四半期ごと、あるいは年2回ローテーションを行っており、一部のプロバイダーでは自動的にキーのローテーションを行っています。

ローテーションの失敗の多くは、スワップに関連する手順に起因しています。管理者が最も見落としがちな点は以下の通りです。

古い公開鍵を早すぎる段階で削除してしまう

すでに送信中のメッセージは古い鍵で署名されているため、受信者はそれらを検証するためにDNS上に登録された対応する公開鍵を必要とします。切り替えを行うと同時に古いレコードを削除すると、送信中のメールはDKIM検証に失敗します。古い鍵で署名されたメールがすべて配信完了するまで、移行期間中は古い鍵を公開し続けてください。

同じセレクタの再利用

セレクタを上書きするのではなく、ローテーションさせてください。新しいキーを 新しいセレクタの下に公開し、署名をそちらに移行してから、重複期間が終わった後に古いセレクタを廃止してください。単一のセレクタのレコードを上書きすると、古い鍵で署名されたメールが検証できなくなるギャップが生じます。

DNSの伝播が完了する前に切り替える

新しい公開鍵が 新しい公開鍵が全サーバーに反映される前に、受信側はそれを見つけられず、DKIMが失敗します。まず新しいレコードを公開し、レコードのTTLが経過するのを待ってから、署名を切り替えてください。

サードパーティの送信者を除外する

ESPやCRMなどの各送信サービスは、それぞれ独自のDKIMキーとセレクタを管理しています。メインドメインのキーを更新しても、これらには影響しません。各サービスのキーは個別に更新するか、プロバイダーが対応してくれるかどうかを確認してください。

2048ビットのレコードを誤って分割する

現在の標準である2048ビットの公開鍵は、もし現在1024ビットを使用しているならアップグレードする価値がありますが、単一のDNS TXTレコードの文字数制限である255文字を超えることが多く、引用符で囲んだ複数の文字列に分割する必要があります。分割の仕方を誤るとレコードが破損し、鍵が存在しているように見えても検証に失敗してしまいます。

監視なしでの回転

DMARCの集計レポートは、新しい鍵が正しく検証されているかを確認するための手段です。これがないと、鍵のローテーションに失敗しても、アラートとして通知されるのではなく、配信率の低下として現れてしまいます。鍵のローテーションを行うたびに、レポートを確認してください。

どちらの障害も、手作業で管理しきれないほどの速さで変更されるレコードに起因しています。 PowerDMARCは、SPFを10件のルックアップ制限内に収め、 10回検索という制限内に収め、DKIMキーを適切にローテーションし、配信率に悪影響が出る前に、問題が発生した瞬間に通知します。

無料トライアルを開始 今すぐ無料トライアルを開始して、現在のドメインの状況を確認しましょう。

よくあるご質問

DKIMはSPFに取って代わるのでしょうか？

いいえ。DKIMは暗号署名を用いてメッセージの完全性を検証しますが、送信サーバーが認証済みであるかどうかは確認しません。その確認はSPFが行うため、完全な保護を実現するには両方が必要です。 

メールを転送すると、なぜSPF検証に失敗するのですか？

SPFは送信サーバーのIPアドレスを許可リストと照合しますが、転送処理が行われると、元のIPアドレスが転送元のIPアドレスに置き換えられ、そのIPアドレスは許可リストに含まれていません。これはRFC 7208で想定されている動作であり、DKIMは経路ではなくコンテンツを検証するように設計されているため、この状況でも有効性を維持できます。 

SPFとDKIM、どちらがより重要ですか？

どちらもではありません。SPFはサーバーレベルで認証を行い、DKIMはメッセージレベルで検証を行います。信頼性の高いDMARCアラインメントを実現するには、両方が必要です。両方を導入しておけば、転送時に一方が失敗しても、メールは正常に送信されます。 

DKIMセレクタはいくつまで設定できますか？

数に制限はありません。必要なだけ発行してください。通常は、送信サービスごと、またはキーのローテーションサイクルごとに1つずつ発行します。それぞれが、selector._domainkey.yourdomain.com にある個別のDNS TXTレコードとして存在します。 

SPFは設定しているが、DKIMは設定していない場合、どうなりますか？

メッセージレベルの整合性が失われ、DKIMの整合性確保の代替手段も存在しないため、SPFに問題が生じた場合、正当な転送メールであってもDMARCの検証に失敗する可能性があります。また、Googleの大量送信者向けルールではDKIMの使用が義務付けられているため、大量のメールを送信する送信者はコンプライアンス違反となる可能性があります。