Sender Policy Framework（SPF）：電子メールインフラストラクチャの保護層

公開: 2020-03-04

誰かが（ふざけてまたは悪意を持って）あなたの電話を持って、誰かにあなたのふりをしてテキストメッセージを送ったことがありますか？あまり気分が良くないですよね？あなたが受取人と真実を明らかにした後でさえ、彼らは将来あなたのすべてのテキストに警戒するでしょう。そして、あなたはおそらくあなたがあなたの電話を誰に借りさせるかについてもっと注意深くなるでしょう。信頼が壊れています。

電子メールの世界でも同様のシナリオが考えられます。フィッシング詐欺師は、ビジネスになりすますためにユーザー名とパスワードを必要としません。怖いですよね？

幸いなことに、私たちはあなたのブランドの評判を守るための簡単でそれほど秘密ではないトリックを知っています。これはSenderPolicyFramework（SPF）と呼ばれ、電子メールレピュテーションの命の恩人です。

電子メールが1つのサーバーから別のサーバーに送信される場合、SMTP（Simple Mail Transfer Protocol）を使用して、送信者から受信者にメッセージを取得します。 SMTPサービスとして、TwilioSendGridはこのプロセスを容易にします。

電子メールのインフラストラクチャのセキュリティ上の弱点の1つは、送信者またはホストが自分自身と、必要なドメインとして電子メールを識別できることです（たとえば、ドナルドトランプのTwitterアカウントを大量に作成したようなものです）。これにより、受信者は、メッセージが実際に送信者からのものであると信頼することが困難になります。また、送信者は、自分のドメインからメールを送信し、ブランドの評判を損なう可能性があることを知って不安になります。

受信者は電子メールの信憑性への信頼を失い、送信者は妄想的な詐欺師がブランドを装っています。誰にとっても良くありません。ソリューションの一部は、DNSのtxtレコードに保存されているSPFレコードです。この記事では、SPFのすべてのことを探求します。それが何であるかから、自分でエラーを発見することまで、すべてをカバーします。

SPFレコードとは何ですか？

SPFはSenderPolicyFrameworkの略です。これは、特定のドメインからの電子メールの送信が許可されているメールサーバーを識別するのに役立つ電子メール認証方法です。この検証プロトコルを使用して、ISPは、スプーファやフィッシング詐欺師がドメインから電子メールを偽造してユーザーに悪意のある電子メールを送信しようとしている時期を特定できます。

SPFを使用すると、受信者は、受信する電子メールメッセージが期待している相手からのものであると確信できます。また、送信者は、フィッシング詐欺師が自分のブランドからオーディエンスを電子メールで偽装したりフィッシングしたりしていないことを知って安心できます。

より技術的には、SPFレコードは、ドメインの管理者がtxtレコードに追加する短いテキスト行です。 txtレコードは、A、PTR、およびMXレコードと一緒にDNS（ドメインネームシステム）に保存されます。 SPFレコードは次のようになります。

「v=spf1ip4：12.34.56.78 include：example.com-all」

SPFのしくみ

上記のテキスト行は、特定のドメインからのメールの送信を許可されているホストを受信SMTPサーバーに通知するために使用されます。

SPFレコードは通常、SMTP会話の非常に早い段階で、メッセージの本文が送信されるかなり前にチェックされます。メッセージを送信しようとすると、送信側サーバーと受信側サーバーの間でTCP接続が開かれます。

接続が確立されると、HELOコマンドが発行されます。これは、基本的に、どのドメインがメールを送信しようとしているのかを受信サーバーに通知します。この後に、メッセージの送信元の電子メールアドレスを受信サーバーに通知するMAILFROMコマンドが続きます。 MAIL FROM（envelopefromおよびreturnpathとも呼ばれます）コマンドで見つかったドメインは、SPFレコードチェックに使用されるドメインです。

したがって、メッセージが受信され、MAILFROMアドレスが[email protected]であるとします。受信サーバーは、example.comのパブリックDNSレコードをチェックし、v=spf1で始まるTXTレコードを探します。 v = spf1で始まるTXTレコードがない場合、認証は成功します。 v = spf1のTXTレコードが複数ある場合は、エラーが発生する可能性があります。

1つが見つかったと仮定すると、前の例のようになります。

「v=spf1ip4：12.34.56.78 include：example.com-all」

受信サーバーは、メッセージを送信しようとしているSMTPクライアントのIPアドレスがSPFレコードに含まれているかどうかを確認します。 IPアドレスがリストされている場合、メッセージはSPF認証に合格します。

核心：SPFレコードの各部分を分解する

SPFレコードは、次のようなさまざまなメカニズムで構成されています。

含む

常にドメイン名が続きます。受信サーバーがインクルードメカニズムに遭遇すると、そのドメインのSPFレコードがチェックされます。送信者のIPがそのレコードに表示される場合、メールは認証され、SPFチェックは終了します。見つからない場合、SPFチェックは次のメカニズムに進みます。

A

また、ドメイン名が続きます。ただし、この場合、SPFはそのドメインに関連付けられているIPアドレスをチェックするだけです。送信者のIPと一致する場合は合格し、SPFチェックは停止します。そうでない場合は、次のメカニズムに進みます。

MX

「A」に似ています。常にドメイン名が続きます。リストされたドメインが送信側クライアントのIPアドレスに解決されると、認証に合格し、SPFチェックが実行されます。そうでない場合は、次のメカニズムに進みます。

IP4およびIP6

常に特定のIPアドレスまたはCIDR範囲が続きます。送信側クライアントのIPがIP4またはIP6メカニズムの後にリストされている場合、認証に合格し、SPFチェックが実行されます。そうでない場合は、次のメカニズムに進みます。

PTR

SPFレコードに含めることはできません。いくつかの技術的な理由により、エラーが発生しやすく、受信サーバーが解決するために多くのメモリと帯域幅が必要になります。一部のサーバーは、PTRメカニズムの存在に基づいてSPF認証に失敗します。

リダイレクト

技術的にはメカニズムではなく修飾子ですが、これにより、ドメインの管理者はドメインを別のドメインのSPFレコードにポイントできます。 REDIRECT機能を使用する場合、「すべて」のメカニズムを含め、他のメカニズムをSPFレコードに含めることはできません。リダイレクトレコードのサンプル：「v = spf1redirect：example.com」

「INCLUDE」、「A」、「MX」、「PTR」、「EXISTS」、および「REDIRECT」メカニズムはすべてDNSルックアップを必要とするため、これらを10個までにすることができます。これは十分に単純に思えますが、ネストされたDNSルックアップも含まれます。つまり、さらに2つの「INCLUDE」メカニズムを持つ別のSPFレコードにつながる「INCLUDE」は、3つのDNSルックアップとしてカウントされます。それらは速く加算されます！

Twilio SendGridのお客様はどうですか？

ほとんどの送信者は、送信ドメインをsendgrid.netにポイントするCNAMEを設定しています。これは、受信サーバーがsendgrid.netを指すCNAMEを確認し、代わりにそのSPFレコードをチェックすることを意味します。したがって、クエリするSPFレコードのほとんどが同一であっても驚かないでください。

Twilio SendGrid固有の質問については、SenderPolicyFrameworkのドキュメントページをご覧ください。いくつかの一般的な質問とシナリオに対する追加の回答があります。

SPFレコードを確認するにはどうすればよいですか？

すべての人がSPF認証を使用するわけではありませんが、SPFの失敗に基づいて拒否する受信者は配信を拒否します。一部の受信者は、SPFに失敗したメールをブロックせずに隔離する場合もあります。

各SPFレコードは少し異なりますが、正しく設定されていることを確認する必要があります。レコードの検証に役立つ3つのツールを次に示します。

Scott KittermanのSPFテストツール：ドメインにSPFレコードが既に存在するかどうかを確認し、その有効性を確認するか、パフォーマンスをテストします。
OpenSPF.org ：一連のフォームと電子メールベースのテスターを確認します。
SPFレコードチェック： SPFレコードチェックは、SPFレコードルックアップおよびバリデーターとして機能します。 照会されたドメイン名のSPFレコードを検索し、レコードに対して診断テストを実行して、電子メールの配信可能性に影響を与える可能性のあるエラーを強調表示します。
SPFウィザード：SPFウィザードは、ブラウザーベースのSPFレコード生成ツールです。フォームに記入すると、サイトがSPFレコードを生成します。

SenderPolicyFrameworkを優先する

簡単に言えば、悪意のある電子メールメッセージはビジネスに悪影響を及ぼし、電子メールチャネルを劣化させます。フィッシング詐欺師は、Sender Policy Frameworkで保護されたドメインを見ると、より簡単なターゲットに移動する可能性が高くなります。 SPFはスパムを防ぐことはできませんが、抑止力として機能し、攻撃に対する脆弱性を軽減することができます。そして、誰がそれを望まないのですか？そのため、すべての電子メールクライアントにSPFレコードを作成することをお勧めします。

SPFは、Sender ID、DKIM、DMARCと組み合わせることで、ISPが電子メールを適切に識別し、スパマーを適切に識別できるようにすることで、ユーザーをより適切にサポートする追加レベルの電子メールセキュリティを提供します。