SendGridからメール送信する場合のSPFとDKIMの認証の仕組み – 前編

SendGridサポートチームの有田です。
過去の記事で一般的なSPFとDKIMの仕組みについて解説しましたが、SendGridからメール送信する場合はどのように送信ドメイン認証されるのでしょうか。前後編に分けて、その仕組みを簡単にご紹介します。

SPFとDKIMの復習

まずは、SendGridを使わない場合のSPFとDKIMの仕組みを復習します。
SPFもDKIMも、メールのなりすましを防ぐための送信ドメイン認証の手法です。メールを受け取った受信側メールサーバは、送信元ドメインのDNSサーバに認証情報を問い合わせます（図1の③）。この認証情報とメール自身が持つ情報を突き合わせて、差出人の詐称やメールの改ざんの有無をチェックします（図1の④⑤）。認証情報として、SPFでは送信元IPアドレスを、DKIMでは電子署名を利用します。

図1) 送信ドメイン認証

SendGridのDomain Authentication設定について

SendGridで独自ドメイン（例：kke.co.jp）からのメールを送る場合に、SPF/DKIMの独自ドメイン化を支援するため、Domain Authentication機能が提供されています。

Domain Authenticationの設定前後では以下のような違いがあります。

• Domain Authenticationを設定しない場合 ･･･ SPF/DKIMがSendGridのドメインで認証される。Domain Authenticationを設定していない全てのユーザが同じドメインで認証されるため、他のユーザの影響を受ける可能性がある。また、メールのヘッダFrom（独自ドメイン）とエンベロープFrom（SendGridのドメイン）が異なることから、なりすましと判断されることがある。
• Domain Authenticationを設定する場合 ･･･ SPF/DKIMが独自ドメインで認証される。他のユーザからの影響を受けず、ドメインレピュテーションを独自に制御できるため、到達率の向上が期待される。

機能についての詳細は、以下の記事もご覧ください。
参考：使いやすくなった独自ドメイン利用設定機能(Sender Authentication)のご紹介

それでは、SendGridからメール送信する場合の認証フローを見ていきましょう。SendGridを利用すると、図1の「送信側メールサーバ」がSendGridに置き換わります。

Domain Authenticationを設定せずにメール送信する場合

以下の図2は、送信元ドメイン（ヘッダFromドメイン）を kke.co.jp とする場合のSPFの認証フローです。

図2) SendGridからのメール送信（Domain Authentication未設定）

Domain Authenticationを設定しない場合、メールのヘッダFromは kke.co.jp ですが、エンベロープFromはSendGridのドメインになります。受信側メールサーバがメールを受け取ると、SPFのチェック対象であるエンベロープFromのドメイン（=SendGridのドメイン）を管理するDNSサーバに認証情報を問い合わせます（図2の③）。受信側メールサーバは、SendGridのDNSサーバが返した認証情報をチェックします（図2の④⑤） 。

このとき、SendGridのDNSサーバには適切なSPFレコードが登録されているので、認証自体はパスします。しかし、メールのヘッダFromとエンベロープFromが一致していないため、受信側メールサーバによってはなりすましメールと判断し、メールをフィルタしたり、迷惑メールフォルダに振り分けたりすることがあります。

Domain Authenticationを設定してメール送信する場合

前章のように「差出人のドメインと送信ドメイン認証されるドメインが異なる」状態を解消するには、Domain Authentication設定を利用します。このときのSPFの認証フローは以下の通りです。
※本章では、Use automated securityがONであることを前提とします。

図3) SendGridからのメール送信（Domain Authentication設定済み）

Domain Authenticationを設定した場合、メールのヘッダFromは kke.co.jp 、エンベロープFromは kke.co.jp のサブドメイン（例：em.kke.co.jp）になります。このサブドメインは、Domain Authentication設定を作成する際にSendGridが自動的に付与します（※ユーザが任意のサブドメインを指定することも可能）。

受信側メールサーバがメールを受け取ると、エンベロープFromのドメイン（em.kke.co.jp）を管理するDNSサーバに認証情報を問い合わせます（図3の③）。このDNSサーバにはDomain Authentication用のCNAMEレコード（エイリアス／別名）を登録しており、em.kke.co.jp の認証情報の問い合わせがあると、SendGridのDNSサーバを参照するようになっています（図3の④）。そのため、受信側メールサーバから見ると、em.kke.co.jp のDNSサーバが認証情報を返したように見えますが、実際にはSendGridのDNSサーバに登録されたレコードを参照していることになります（図2の⑤）。受信側メールサーバは認証情報をチェックします（図2の⑥）。

このとき、SendGridのDNSサーバには適切なSPFレコードが登録されているので認証をパスします。加えて、ヘッダFromとエンベロープFromのドメインが一致するため、なりすましと判断される可能性が低くなり、到達率の向上が期待されます。

ここまでSPFについて説明してきましたが、基本的な認証フローはDKIMも同じです。DKIMの認証に使う秘密鍵と公開鍵はSendGridが管理し、DKIMレコードを参照するためのCNAMEレコードを独自ドメインを管理するDNSサーバに登録します。概要は下図の通りです。

図4) DKIMの認証フロー

まとめ

今回の記事では、SendGridでメール送信する場合の認証フローについて解説しました。
SPFとDKIMの普及率が上がってきたこと、DMARCのような新しい送信ドメイン認証の手法が登場したことからも、なりすましを疑われないメールを送信することが、今後はより重要になってくると考えられます。
受信者に問題なくメールを届けることができるよう、独自ドメインからのメールを送る場合はDomain Authenticationを適切に設定しましょう。詳しい設定方法は、チュートリアルをご覧ください。

後編では、内容を少し発展させて、「Domain Authentication設定のサブドメインはなぜ必要なのか？」「Advanced Settings（高度な設定）はどんなケースで必要になるのか？」といった内容を解説します。