SendGridで独自ドメインから送信する際は、Sender Authentication機能を利用してSPFとDKIMの設定をすることが一般的です。
これで基本的にはOKなのですが、この方法だとSPFは通過するもののSender IDやdocomo独自の検証は通過しないため、docomoのキャリアメールに対して届きにくいことがあります。
FromとEnvelope From
まず、メールのFromとEnvelope Fromについておさらいしましょう。
From
Fromアドレス（ヘッダFrom）は、メールヘッダに記載されるアドレスで、一般のメーラーで「送信者」として表示されるものです。
例えばこのAmazonのメールでは、 auto-confirm@amazon.co.jp がFromアドレスになります。
Envelope From
Envelope FromはSMTPの MAIL FROM で指定するもので、バウンスメールの宛先として利用されます。送信時にヘッダには記載しませんが、最後のMTAが Return-Path としてヘッダに追記するため、受信側はそれを見ることでEnvelope Fromを確認できます。
先ほどのAmazonのメールでは、 Return-Path: <ユニークなIDらしき英数字列@bounces.amazon.co.jp> になっていました。
telnetで送信する際の例
telnetでSMTPを送信する以下のようなシンプルな例で見てみましょう。赤字が自分で入力した文字列です。
baba@ubuntu:~$ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 ubuntu ESMTP Postfix (Ubuntu) EHLO localhost 250-ubuntu 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: mail0001@bounces.example.com 250 2.1.0 Ok RCPT TO: baba@bpsinc.example 250 2.1.5 Ok DATA 354 End data with. From: noreply@example.com Subject: Hello, world . 250 2.0.0 Ok: queued as 7C508 quit
この例では、以下のようになります。
mail0001@bounces.example.comがEnvelope Fromです。ここにユニークなアドレスを指定することで、バウンスを検知しやすくなります。noreply@example.comがFromです。これは受信者に表示され、またReply-Toヘッダを追加しない限り返信先にもなるので、メールの目的に応じて適切なものを設定します。baba@bpsinc.exampleがEnvelope Toです。これが実際に送信される宛先で、このアドレスとヘッダのToを別のものにすることで、BCCを実現できます。- ヘッダにToアドレスは指定していませんので、受信者から見ると「宛先無し」のメールに見えます。
SPFとSender ID
SPFとSender IDはどちらも、ドメインに記載したTXTレコードを使って送信元アドレスを認証する技術です。
例えば bpsinc.example ドメインに以下のようなDNSレコードが設定されていた場合、送信元アドレスが mail.bpsinc.example のメールは 198.51.100.1 のメールサーバから送るよ（それ以外は偽物だよ）と言うことになります。
txt mail v=spf1 +ip4:198.51.100.1
SPFとSender IDはどちらも上記のTXTレコードを使いますが、「送信元アドレス」としてどれを見るかが異なります。
SPFの場合
SPFではEnvelope Fromをチェックします。
Sender IDの場合
Sender IDではPurported Responsible Address (PRA) をチェックします。
詳細は RFC4407 に記載がありますが、通常はヘッダのFromアドレスが使われることが多いと思います。
SPFと違い、ユーザに見える送信者アドレスをチェックすることになるので、なりすまし対策としてはより踏み込んだものになります。
Gmailでの確認
Gmailでは「Show Original」からメッセージヘッダを表示する画面で、SPF（やDKIM、DMARC）の通過状況を確認することができます。
現在のところ、Sender IDには対応していないようです。
SendGridでのSPF対応
前置きが長くなりましたが、SendGridでの設定について見てみましょう。
ダッシュボードからSender Authenticationを開き進んでいくと、以下のようなCNAMEを設定するように指定されます（一部数字を0に伏せてあります）。
cname sendgrid u0000000.w0000.sendgrid.net.
cname s1._domainkey s1.domainkey.u0000000.w0000.sendgrid.net.
cname s2._domainkey s2.domainkey.u0000000.w0000.sendgrid.net.
DKIMはいったん置いておくとして、SPF用のレコードは cname sendgrid u0000000.w0000.sendgrid.net. です。
SPFはTXTレコードで v=spf1 +ip4:198.51.100.1 のような形で指定するものですが、これだとSendGrid側でサーバのIPアドレスを変えた際に全利用者が変更しなくてはならなくなるため、このような設定が推奨されているようです。
上記の設定を example.com に行った場合、SendGridから送信するときにはEnvelope Fromに @sendgrid.example.com が利用されるため、SPFが無事に通過します。
問題点
上記の設定方法からわかるとおり、SendGridからの送信では、必ずEnvelope Fromに何らかのサブドメインが付与され、SPFもそのサブドメインに設定します。
そのため、Fromアドレスを sender@example.com のようにサブドメインを付けないアドレスにして、そのアドレスがPRAになる場合、Sender IDを通過しないことになります。
多くのメールサーバやau, softbankのキャリアメールはSPFが通過すれば問題ないのですが、docomoではSender ID（もどき？）が使われているため、このままだとなりすましメール扱いされるリスクが高まります。
SPF（TXT）レコードの確認には、メールヘッダのFROMフィールドを使用します。なお、メールヘッダのFROMフィールドが存在しない場合はエンベロープFROMを使用します。
同記事より
対策
Fromアドレスを @sendgrid.example.com のようにするのは一つの手ですが、あまり格好良くありません。
Sender IDやdocomoに対応するには、以下のようなレコードを設定するのがお手軽だと思います。
txt @ v=spf1 include:sendgrid.example.com
これで、サブドメインのつかないメールアドレスでも sendgrid.example.com の中身を見ることになるため、自前でSendGridサーバのIPアドレス変更を検知・処理することなく、安心して使うことができます。