Eメール送信のベストプラクティス

自分のウェブサービスやサイトからユーザーに向けてEメールを送りたいけど、なぜかユーザーのメールアドレスに届かないとか、迷惑メールフォルダに分類されてしまうといった悩みはエンジニアなら一度は持ったことがあるのではないでしょうか。

実際、大手のメールプロバイダーは増え続けるスパムメールやフィッシングメールに対しての対策を強化しており、メール配信へのハードルは決して低くありません。

例えばGoogleはEメール送信のガイドラインを発表しており、その要件に満たないメールは迷惑メールに分類もしくは拒否されると公言しています。

ただ、裏を返せば上記の要件を満たせばユーザーの受信ボックスに配信される確率はかなり高くなるということですので、１つずつ対策を確認してみましょう。

1. SPFとDKIMを設定

SPF（センダーポリシーフレームワーク）はご自身のDNSプロバイダーで以下のようなTXTレコードを追加することで設定できます。

"v=spf1 a mx ~all"

上記は基本的な例ですが、「SPFのバージョン１に則り、このドメインで指定しているA/AAAAレコード及びMXレコードに記載されているIPアドレスからのメール送信を許可し、それ以外はソフトフェイル（明確に拒否はしないが、送信ホストはおそらく許可されてない）」という意味になります。

実際にメールが送信される際には、SPFレコードは以下のように使われます。

送信サーバーがEメールをSMTPで送信。エンベロップのMAIL FROMにme@mydomain.comと記載。
受信サーバーがMAIL FROMに記載されているメールアドレスのドメイン（mydomain.com）のSPFレコードをDNSでチェックし、記載されているIPアドレス一覧を取得。メッセージヘッダーのFROMのEメールアドレスではなくエンベロップのMAIL FROMのEメールアドレスをチェックしますので、間違えないように注意が必要です。
送信サーバーのIPアドレスが、２で取得したIPアドレス一覧に含まれていれば受信サーバーはSPF認証をパスさせ、含まれていなければフェイルさせます。

DKIM認証

DKIMはDomainKeys Identified Mailの略でディーケーアイエムと読みます。DKIMもDNSレコードを使ったEメール認証のプロトコルという意味ではSPFとよく似ていますが、以下の点で異なっています。

DKIMでは秘密鍵と公開鍵を使うが、SPFでは使わない。
SPFはエンベロップの内容を使うのでSMTPに依存した認証の仕組みだが、DKIMはメールヘッダーと本文のみを使いエンベロップは使わないのでSMTPから独立した仕組みである。

DKIM認証の流れは以下の通りです。

ドメイン所有者が秘密鍵と公開鍵を送信サーバーにて作成。
公開鍵をDNSレコードとして公開。
秘密鍵で送信メールに署名を付与。
受信メールサーバーが送信ドメインの公開鍵をDNSレコードから取得し、メールの署名と合致するかチェック。もし合致したらDKIM認証はパス、合致しなかったらフェイルとする。

上記の確認プロセスにより受信サーバーは、１）送信ドメインオーナーがそのEメールを許可したか、２）Eメールが送信中に改竄されていないか（改竄されていたらメールの内容が署名と合致しなくなるため）、の２点を確認することができます。

なお、DKIMのDNSレコードは「任意のセレクター」＋「_domainkey」「ドメイン名」をドットで繋いだサブドメインとすることが決まっています（例：s1._domainkey.yourdomain.com）。このDNSレコードは最終的にTXTレコードに解決すれば良いので、CNAMEで発行することも可能です。

SPFとDKIMの認証結果の検証

SPFとDKIMが正しく認証されているかは、個別メールのソースとPostmaster Toolsで確認できます。

個別メールのソースでチェック

大抵のメールプロバイダーはメールのソースを表示する機能を提供しています。例えばGmailだと、個別メールの右メニューから「メッセージのソースを表示」というメニュー項目をクリックすると、そのメールのソースを確認することができます。

ソースのヘッダーを見ても良いのですが、Gmailだとソースに加えて以下のようにSPF、DKIM、DMARCそれぞれの認証結果を概要欄で教えてくれるので便利です。

Gmail以外のプロバイダーで上記のような概要欄を提供していなかったり、もっと詳しくソースまで見てご自身でチェックしたい場合は、Authentication-Resultsヘッダーがあるか確認してみてください。これはSPF、DKIM、DMARCそれぞれの認証結果を記載するためにRFC8601で定められている正式なヘッダー項目です。上記の概要欄での結果も、このヘッダーをユーザーにわかりやすく表示しているだけだと推察されます。

以下はGoogleから送られてきたメールに記載されていたAuthentication-Resultsヘッダーですが、dkim=pass, spf=pass, dmarc=passとなっているので、３つ全ての認証プロトコルで認証がパスしているのがわかります。

Authentication-Results: mx.google.com;
       dkim=pass header.i=@google.com header.s=20230601 header.b="vEt/Ho2N";
       spf=pass (google.com: domain of 3x6z7zrykanwdmpkq-pcacgnrq-lmpcnjwemmejc.amk@chime-notifications-apps.bounces.google.com designates 209.85.220.69 as permitted sender) smtp.mailfrom=3X6z7ZRYKANwDMPKQ-PCACGNRQ-LMPCNJWEMMEJC.AMK@chime-notifications-apps.bounces.google.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com

Received-SPFという別のメールヘッダーもありますが、こちらはSPFの認証結果を記載するだけのヘッダーですので、より包括的なAuthentication-Resultsヘッダーを使った方が良いでしょう。

なお、Authentication-Resultsがどのようにパスしたかをさらに確認したい場合、SPFの場合はメッセージヘッダーのReturn-Pathに記載されているメールアドレスをチェックします。SPF認証にはSMTP通信でエンベロップに含まれるMAIL FROMのメールアドレスが使われると説明しましたが、エンベロップはSMTP通信が終わると破棄され、MAIL FROMはメッセージヘッダーにReturn-Pathとして追記されるためです。Return-Pathに記載されているメールアドレスのドメインでSPFレコードが登録されており、自身がメール送信に使っているサーバーのIPアドレスがそのSPFレコードに含まれていれば認証は成功しているはずです。

Postmaster Toolsでの確認

Googleが提供しているPostmaster Toolsでは、自分のドメインを登録すると、そのドメインからGmailに送信されたEメールに関する様々な指標を確認することができます。

このツールで「認証」メニューを選ぶと、Gmailが受信したメール全体の何％がSPF、DKIM、Dmarcそれぞれの認証にパスしたかを確認することができます。

2. DNSで正引きレコードと逆引きレコードを設定

メールの受信サーバーは、スパム対策として送信サーバーの正当性をDNSの逆引きを行なうことで検証します。

送信サーバーのIPアドレスについて、DNSのポインターレコード（PTRレコード）が存在し、ホスト名に解決すること。
1で解決したホスト名のAレコードもしくはAAAAレコードが存在し、送信サーバーのIPアドレスに解決すること。

1と2の確認を行った際、IPアドレスとホスト名がお互いに参照し合っていてループ構造になっていればパスします。

この仕組みはRFC8601に「The “iprev” Authentication Method」として記載されているので、興味があればぜひ読んでみてください。

送信サーバーのIPアドレスとホスト名は、メールソースのヘッダーに以下のように記載されます。

Received: from mail-sor-f69.google.com (mail-sor-f69.google.com. [209.85.220.69])

括弧（）の中のホスト名が、その右のIPアドレスの逆引きで参照されているホスト名です。

PTRレコードが自身のDNSプロバイダーで設定出来ているかは、以下のdigコマンドでチェックします。

dig -x 127.0.0.1 (ホスト名を特定したいIPアドレス）

3. TLSで接続する

ウェブサイトへのアクセスにTransport Layer Security（TLS）を使うのがデフォルトになっているように、メール送信もTLSを使うのがデフォルトとなっています。TLSを使って暗号化をしないと、配信中のメールの中身を第三者に覗かれるリスクが高まるからです。

GoogleのPostmaster Toolsの「暗号化」メニューで、自身のドメインからGmailに送られたメールのTLS使用率を確認できます。

受信と送信の２種類ありますが、これはGmail側から見て受信か送信かということですので、自分のドメインからGmailに送信されたメールのTLS使用率は受信の方を見ます。この数値が100%になっていれば問題ありません。

4. Postmaster Toolsで迷惑メール率を監視

GoogleのPostmaster Toolsには、上記の「SPFとDKIMを設定」で解説した「認証」メニューに加え、「迷惑メール率」メニューがあり、Gmailユーザーが報告した迷惑メールが全体の何％あるかを確認できます。

Googleのガイドラインでは、迷惑メール率を0.3%未満にすることが要求されています。

5. RFC5322に準拠したメッセージ・フォーマットを使用

RFC5322はEメールのフォーマットの仕様を定めていますが、その仕様から外れたメールを送ると受信サーバーに拒否される可能性が高まります。

例えばRFC5322はメールヘッダーの内、日付（Date）と差出人（From）フィールドを必須と定めていますので、どちらかがないEメールはほぼ拒否されると考えて間違いないでしょう。たとえ仕様で定めていなくても、日付や差出人が不明のEメールなんて怪しすぎますよね。

もしメッセージ・フォーマットのエラーがある場合、Google Postmaster Toolsの「配信エラー」メニューに記載されます。

6. Gmailのなりすましはしない

要はGmailから送っていないEメールなのに、Fromヘッダーにme@gmail.comと記載するな、ということです。自分のメインのメールアドレスがGmailだからと言って、Gmail以外のサーバーから送るメールのFromにGmailアドレスを使うのは止めましょう。

なお、GmailはDMARCで検疫ポリシー(p=quarantine)を適用すると公言していますので、Gmailのなりすましメールはどこに送ろうが確実に迷惑メールフォルダー行きになるかと思われます。

7. メール転送する場合はARCヘッダーを追加

ARC（Authenticated Received Chain）はメールが複数のサーバーを経由して配信される際に、各サーバーでの認証結果を保存して伝達するためのプロトコルです。

メーリングリストサービスを運営しているなど、メール転送を自身で行っていない限り、この要件に自分で対応する必要はないでしょう。ただ、ARCがどのような課題を解決するための仕組みで、実際にどのようなヘッダーが挿入されるのかは理解しておいた方が良いので、説明していきます。

まず、なぜメール転送の際にARCが必要なのかというと、メールを転送するとSPF認証やDKIM認証がパスしなくなり、結果としてDMARC認証もパスしなくなる可能性があるからです。

例えば、A（送信サーバー）、B（転送サーバー）、C（受信サーバー）の３つがあり、メールはこの３つのサーバーを上記の順番で転送されていくとします。

SPFは送信元のIPアドレスを認証する仕組みなので、Bサーバーが他社のサービスだった場合は、BのIPアドレスはSPFレコードで許可されていない可能性があります。そうするとAからBに送る際はSPF認証はパスしますが、BからCに転送される歳にはSPF認証はフェイルとなってしまいます。

また、Bサーバーがメーリングリストサービスの場合、メーリングリスト名や配信停止リンクなどをメール本文に挿入する場合があります。そうすると、AからBへのメール送信ではDKIM認証はパスしますが、BからCに転送の際にはDKIM署名と本文の内容が一致しなくなり、DKIM認証がフェイルとなります。

BからCの転送の際にSPF認証もDKIM認証もフェイルしているということは、BからCの転送の際にDMARCも必然的にフェイルしてしまうということです。

この問題を解決するためにARCは使われます。ARCには以下の３つのヘッダーがあり、３つで１つのセットとして扱われます。

ARC-Authentication-Results
ARC-Message-Signature
ARC-Seal

これらのヘッダーが実際のメール転送の際にどのように使われるかを、同じ例を使って説明します。

Bの転送サーバーがAの送信サーバーからメールを受け取った際に、SPF、DKIM、DMARC認証を通常の通り行い、認証結果をAuthentication-Resultsヘッダーに記録します。
BサーバーがCサーバーにメールを転送する際に、Authentication-Resultsヘッダーの内容をARC-Authentication-Resultsヘッダーにコピーします。その際に、１から始まるシークエンス数をiタグにi=1のように記載します。転送サーバーが複数ある際は、iは1, 2, 3と増えていきます。
BサーバーがCサーバーにメールを転送する際に、ARC-Message-Signatureヘッダーを追加し、メールヘッダーと本文を使ってDKIMのような署名を付与します。また、ARC-Authentication-Resultsに使ったのと同じシークエンス数をiタグに記載します。
BサーバーがCサーバーにメールを転送する際に、ARC-Sealヘッダーを追加し、ARCヘッダーを使ってDKIMのような署名を付与します。また、ARC-Authentication-Resultsに使ったのと同じシークエンス数をiタグに記載します。
BサーバーがメールをCサーバーに送ります。
Cサーバーで通常のDMARC認証がフェイルした場合、ARCヘッダーで転送前サーバー（Bサーバー）での認証結果を確認し、メールを受信するかどうかを決めることが出来ます。

以下はARCヘッダーの例です。

ぜひご自身が受信したメールのソースを見て、ARCヘッダーがどのようになっているか確認してみてください。

8. DMARC認証を追加

この項目は、ご自身のDNSプロバイダーでDMARCレコードを追加するだけでパスできます。Dmarcレコードは以下の例のように_dmarcサブドメインでTXTレコードとして指定しなければなりません。

_dmarc.yourdomain.com

但し、このレコードの値は厳しい水準が求められているわけではなく、一番ゆるい以下の値で大丈夫です。

"v=DMARC1; p=none;"

vはバージョン（version）の略、pはポリシー（policy）の略です。上記の例の意味は、DMARCのバージョンは１で、ポリシーはなし（SPFやDKIM認証でパスしないメールを受け取っても、迷惑メールとして分類したり拒否したりすることを受信サーバーに求めない）です。但しポリシーはなしと言っても、Dmarcのフィードバックレポートを受け取れるようになります。

9. DMARCアラインメントにパスする

DMARC認証をパスするには、SPF、DKIM認証にパスするだけでなく、それぞれの認証プロトコルのアラインメントにパスすることが必要です。アラインメントの詳しい説明は後ほど行いますが、DMARCをパスする要件は以下の２つです。

SPF認証及びSPFアラインメントにパスする。
DKIM認証及びDKIMアラインメントにパスする。

上記1、２どちらかにパスすればDMARCはパスします。

アラインメントは日本語で「一致」という意味になり、メールヘッダーのFromアドレス（RFC5322で規定されているFromであって、エンベロップのアドレスではない）のドメインが、SPF認証、DKIM認証で使われているメールアドレスのドメインと一致するかどうかのテストです。

SPFアラインメント

SPF認証ではエンベロップのMAIL FROMが使われるので、SPFアラインメントでもエンベロップのMAIL FROMが比較対象になります。具体的には、メールヘッダーのFromアドレスのドメインが、エンベロップのMAIL FROMのアドレスのドメインと一致するかどうかを確認します。サブドメインも含めて完全一致する場合はstrictアラインメント、サブドメインは一致しないが、サブドメインを除外したドメイン（APEXドメイン）は一致する場合はrelaxedアラインメントとしてパスします。

例えば、以下のようなケースを考えてみましょう。

メールヘッダーFrom：me@mydomain.com

エンベロップMAIL FROM: me@mysubdomain.mydomain.com

この場合はサブドメインは完全一致していませんが、APEXドメインは一致していますので、relaxedアラインメントならパスします。

なお、DMARCポリシーで何も指定しない場合のデフォルトはrelaxedアラインメントが適用されるので、strictアラインメントを受信サーバーに要求したい場合はaspf=sというタグを使います（aspfはalignment spf、sはstrictの略）。

DKIMアラインメント

DKIM認証ではDKIM署名のドメインが使われるので、DKIMアラインメントでも同じくDKIM署名のドメインが比較対象になります。

具体的には、メールヘッダーのDKIM-Signatureに含まれるd=の部分に記載されているドメインと、メールヘッダーのFromアドレスのドメインが一致するかどうかを確認します。SPFアラインメントと同様、サブドメインも含めて完全一致する場合はstrictアラインメント、サブドメインは一致しないが、サブドメインを除外したドメイン（APEXドメイン）は一致する場合はrelaxedアラインメントとしてパスします。

例えば、以下のようなケースを考えてみましょう。

メールヘッダーFrom：me@mydomain.com

DKIM-Signatureのd=：mysubdomain.mydomain.com

この場合はサブドメインは完全一致していませんが、APEXドメインは一致していますので、relaxedアラインメントならパスします。

なお、DMARCポリシーで何も指定しない場合のデフォルトはrelaxedアラインメントが適用されるので、strictアラインメントを受信サーバーに要求したい場合はadkim=sというタグを使います。adkimはalignment dkim、sはstrictの略です。

DMARCレポートでアラインメントを確認

DMARC自体にパスしているかどうかはGoogleのPostmaster Toolsで確認できますが、SPFアラインメント、DKIMアラインメントそれぞれがパスしているかどうかまではわかりません。それぞれの詳細を知りたい場合は、DMARCレコードでruaタグを使ってDMARC集計レポートの送付先に自身のメールアドレスを含め、XMLで送られてくるDMARC集計レポートを開きます。

v=DMARC1; p=none; rua=mailto:me@mydomain.com;

DMARCレポートの例

<feedback>
  <report_metadata>
    <org_name>Yahoo</org_name>
    <email>dmarchelp@yahooinc.com</email>
    <report_id>1636851487.757013</report_id>
    <date_range>
      <begin>1636761600</begin>
      <end>1636847999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>167.89.50.229</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <selector>s1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

DMARCアラインメントで必要になるのは、policy_publishedとpolicy_evaluatedのセクションです。

  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>

policy_publishedは、自身のドメインのDMARCポリシーで指定しているアラインメントモードを示しています。adkimとaspfが両方ともrになっているので、SPF、DKIMそれぞれがrelaxedモードを指定しています。

policy_evaluatedは実際に配信されたメールのアラインメントが合っているかを示しています。以下のレポートでは、dkim、spf共にpassしているので、両者ともにアラインメントが合っていることを示しています。

      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>

10. マーケティングメールの場合はワンクリックで配信停止できるようにする

配信停止リンクがメールに含まれていなかったり、含まれていたとしてもやたら配信停止するのが大変なマーケティングメールを受信したらいやですよね。

ご自身が送るメールにも受信者へ同様の配慮が必要となります。具体的には、List-Unsubscribeというヘッダーをメールに付与してユーザーが簡単にメーリングリストから登録解除出来るようにしてあげます。

このヘッダーをメールに付けると、メールソフトで表示されるFromアドレスの横にメーリングリストの登録解除というリンクが表示されるようになり、ユーザーがワンクリックでメール配信を停止出来るようになります。

例えばGmailではこのように表示されます。

上記リンクのメールソース上のヘッダーは下記のようになっており、登録解除用のURLが値として指定されています。URLではなくmailtoの場合、もしくは両方記載されている場合もあります。

「メーリングリストの登録解除」リンクをクリックすると上記のURLにリクエストが送られ、メーリングリストから登録を解除してもらえるという仕組みになっています。

なお、List-Unsubscribeヘッダーに加え、メール本文のわかりやすい位置に配信停止リンクを配置することも当然必要ですので、忘れないようにしましょう。

まとめ

ユーザーにメールを配信する際に求められる基準は厳しくなっていますが、裏を返せば迷惑メールがユーザーの受信箱から除外されることで、自身のサービスのメールが埋もれることが少なくなる良い機会と捉えることができます。

上記の項目に沿って対策をし、適切な内容のメールを送っている限り過度に恐れることはありませんので、ぜひ実施してみてください。

エンジニア術