📌

送信ドメイン認証を活用してメールの信頼性を上げる

2023/09/21に公開

Rails

送信ドメイン認証

tech

はじめに

新規アプリケーション開発でメール送信機能を一から実装したときに、送信ドメイン認証を設定する必要がありました。
そこで設定したものや実装する上で必要な知識をまとめます。
メールサーバーは自前で用意せず、メールリレーサービスの利用を前提としています。

送信ドメイン認証とは

メールの信頼性を上げ、到達率の改善に貢献する仕組みのことです。

迷惑メールとして認識されないようにするのが目的
送信元が詐称されていないかを検証する
送信元メールサーバのIPアドレスや電子署名を利用して認証を行う
認証経路はDNSを利用する

メールの構造

メールそのものの構造には「差出人」に相当するものが2種類あります。

ヘッダーFrom
エンベロープFrom

この2つのFromの違いは以下の通りです。

ヘッダーFrom

メールソフト上での差出人（From）にあたるもの
送信者が自由に書き換えることができるので、転送や代理送信など柔軟なメール配信が可能になる、などのメリットがある
- その一方で、自由に設定ができるため他人になりすましてメールを送ることが可能

エンベロープFrom

メールの世界では実際に送信した差出人（送信元）にあたるもの
確実に存在するメールアドレスを設定しないと、メールの信頼性が下がる
メールの配送が問題なく完了した場合はとくに参照されることはない。何らかの原因でメールが宛先に届かなかった場合に、エンベロープFromのアドレス宛にエラーが戻る
- そのため、Return-pathとも言う

送信ドメイン認証がなぜ必要なのか

メールソフト上で表示・確認できるのは、ヘッダーFromです。
上記の通り、ヘッダーFromには実質的になんでも設定できてしまうので送信者のなりすましを防ぐ仕組みが必要です。それが「送信ドメイン認証」なのです。

SPF

送信元IPアドレスの正当性を検証する送信ドメイン認証技術の方式です。
SPFはエンベロープFromのドメイン認証を行います。
設定はDNSへのレコード追加（SPFレコードの追加）によって行います。

ヘッダーFromno-reply@example.comを例にした場合、以下のようなレコードをDNSに追加します。

	レコード名	レコードタイプ	値
例1	`example.com`	TXT	`"v=spf1 +ip4:192.168.10.1 –all"`
例2	`example.com`	TXT	`"v=spf1 include:spf.example.jp –all"`

記述方法は複数ありますが、DNSへレコードを追加することは変わらないと思います。
外部のメールリレーサービスを利用する場合は、具体的な設定内容を示してくれるサービスもあるので、それに従ってDNSへレコードを追加しましょう。

DNSレコードタイプにはSPFという専用のレコードタイプが用意されていますが、現在は推奨されていません。TXTレコードを使用することが推奨されています。

DKIM

電子署名を利用し、メールの内容がメール作成時点（オリジナル）から改竄されていないことを検証する仕組みです。DKIMはヘッダーFromのドメイン認証を行います。

DKIMのおおまかな認証のフローはこのようになります。

秘密鍵と公開鍵のペアを作る
公開鍵をDNSへ登録する
メール送信時に、メール配信サーバーで秘密鍵を付与する
メール受信側で、メールに添付されている秘密鍵を、DNSに登録された公開鍵で検証する

メールリレーサービスを使用していたので、上記の内メール2. 公開鍵をDNSへ登録するはこちら側で登録作業を行う必要がありました。
レコードの一例を示します。

レコード名	レコードタイプ	値
`sample-email._domainkey.example.com`	TXT	`"v=dkim; k=rsa; p={公開鍵}"`

DKIMもTXTレコードで使用します。
SPFと異なり、DKIMのレコード名は特殊なフォーマットで登録します。

[セレクタ名]._domainkey.[ドメイン名]

DKIMセレクタは、メッセージの署名に使われる特定の公開鍵を識別するために使われます。
DKIMドメインは、メールそのもののドメイン名を表します。

注意点としては、TXTレコードは最大文字数は255文字という制限があります。公開鍵は文字数が長くなるので、DKIMキーの値を2つの部分に分割して登録することで対応できます。

DMARC

ドメイン認証技術にはDMARCというものありますが機能開発時点では未設定のため詳細はスキップします。
DMARCを設定することで、よりメールの信頼性は向上します。
簡単な概要は以下の通りです。

ドメインの所有者が、認証失敗時に受信者がどのようにメールを取り扱うか方法を指定できる（DMARCポリシー）
ドメインの所有者が、メールの認証結果を受信者から受け取れる（DMARCレポート）
ほとんど普及してない

ドメイン認証の検証

Gmailでは届いたメールが送信ドメイン認証が正常に設定されているかを確認することができます。
メール本文のハンバーガーメニュー内に「メッセージのソースを表示」を開きます。

すると、上記のようなメッセージ情報が表示されます。
この例だと、SPF、DKIM、DMARCそれぞれの認証がPASS（認証成功）していることがわかります。

アプリケーション（Rails）での設定方法

アプリケーション側での設定はとても簡単です。
ヘッダーFromとエンベロープFromを設定するだけです。
以下のように、環境ごとのconfigから設定できます。

# config/environments/production.rb

config.action_mailer.default_options = {
    from: 'no-reply@example.com',
    return_path: 'system@example.com'
}

特定のメールごとに変えたいケースにも対応できます。

class ApplicationMailer < ActionMailer::Base
  default from: 'from@example.com'
  layout 'mailer'
end

class NotifierMailer < ApplicationMailer
  default from: 'no-reply@example.com',
          return_path: 'system@example.com'

  def welcome(recipient)
    @account = recipient
    mail(to: recipient.email_address_with_name,
         bcc: ["bcc@example.com", "Order Watcher <watcher@example.com>"])
  end
end

Mailer Models
mail(headers = {}, &block)