Sender Policy Framework (SPF) は、電子メールの送信元を検証するためのシンプルな認証プロトコルです。SPFは、ドメイン所有者がDNSレコードに送信可能なメールサーバーのリストを公開し、受信側のメールサーバーがその情報を使用して、メールが正規の送信元から送られているかどうかを確認します。
SRS (Sender Rewriting Scheme)、電子メール転送中に送信者のアドレスを書き換える方法です。SRSは主に2つの目的で使用されます。
- SPF (Sender Policy Framework) を通過するため
- 送信元ドメインの認証が失敗した場合のバウンスメッセージ（エラーメッセージ）を正確に処理するため
SPF (Sender Policy Framework)の問題
SPFは、ドメイン内から送信されるメールの発信元IPアドレスを検証・制限するためのテクノロジーです。しかし、メールがフォワードされると、最終的な受信サーバーがオリジナルの送信サーバーからのメールであることを認証できなくなります。その結果、SPFの検証に失敗し、フォワードされたメールがスパムやフィッシングとみなされる可能性があります。
SRS (Sender Rewriting Scheme)の役割
SRSはこの問題を解決するために、フォワードする際に送信者アドレスを、転送サーバーのドメインを指すアドレスに一時的に書き換えます。これにより、受信サーバーは書き換えられたドメインのSPFレコードを照会し、転送サーバーが正当な送信者であることを確認できます。また、バウンスメッセージは書き換えられたアドレスに送られ、転送サーバーはSRSで保持されている情報を元にオリジナルのアドレスに対して適切なエラーメッセージを返すことができます。
SRSは、IPベースの電子メール認証手段（例：SPF）とフォワーディングの両方を使用する状況で効果的です。これにより、メールが正しく配信され、認証やバウンス処理が適切に機能します。
SPF (Sender Policy Framework) の設定
SPF (Sender Policy Framework) の導入は、DNSにSPFレコードを記述するだけです。
SPF (Sender Policy Framework)の書式
SPFの目的は、電子メールアドレスのなりすましやスパム（特にphishing）を防ぐことです。これは、送信者ドメインのDNSレコードに、対応するIPアドレスまたは送信サーバーの識別子を含む「SPFレコード」を作成することで実現されます。
例えば、ドメインexample.com のSPFレコードは以下のようになることがあります。
example.com. IN TXT "v=spf1 ip4:192.168.0.1 include:_spf.example.net -all"example.com. IN TXT "v=spf1 ip4:192.168.0.0/24 ip6:2001:db8::/32 -all"このレコードでは、次のようなルールが定義されています。
v=spf1: SPFプロトコルのバージョンを示す。ip4:192.168.0.1/24:example.comからのメールを送信できるIPv4サブネットを示す。ip6:2001:db8::/32:example.comからのメールを送信できるIPv6 アドレスの範囲（この場合は 2001:db8:: から 2001:db8:0:ffff:ffff:ffff:ffff:ffff まで）include:_spf.example.net:example.comのSPFルールに、_spf.example.netドメインのSPFルールを追加する。-all: SPFレコードで許可されていないすべての送信元に対して、メールを拒否することを示す。
ip4 と ip6 を誤って ipv4 ipv6 と記述しないように注意してください。
SPFレコードの -all と ~all の違い
SPFレコードの -all と ~all は、受信側のメールサーバーがどのようにSPF検証が失敗したメールを扱うかに関する指示です。それぞれの違いは次のとおりです。
-all: ハードフェイル (Hard Fail)- SPF検証に失敗したメールは、明確に拒否されます。これは、非常に厳格なポリシーであり、ドメインから送信されることが許可されていないすべてのメールがリジェクトされることを意味します。これにより、正規の送信元以外からのメールがブロックされる可能性が高くなりますが、誤った設定や変更によって正当なメールも拒否されるリスクがあります。
~all: ソフトフェイル (Soft Fail)- SPF検証に失敗したメールは、注意喚起の対象としてマークされますが、通常は受信サーバーに届きます。これは、検証に問題があった場合でもメールが配信されることを許容し、特にSPFポリシーのテストや移行が行われている際に役立ちます。ただし、ソフトフェイルでは不正なメールのブロックが緩やかになるため、スパム対策としては
-allに比べて効果が低い場合があります。
- SPF検証に失敗したメールは、注意喚起の対象としてマークされますが、通常は受信サーバーに届きます。これは、検証に問題があった場合でもメールが配信されることを許容し、特にSPFポリシーのテストや移行が行われている際に役立ちます。ただし、ソフトフェイルでは不正なメールのブロックが緩やかになるため、スパム対策としては
どちらのオプションを使用するかは、ドメイン管理者がセキュリティポリシーと通信要件に基づいて決定すべきです。厳格なスパム対策が重要であれば -all を、柔軟性や誤検知リスクの軽減が優先される場合は ~all を選択することが一般的です。
受信サーバーは、このSPFレコードを使用して、電子メールが許可されたサーバーから送信されたかどうかを検証します。検証が成功した場合（「パス」）、メールは通常どおり処理されます。失敗した場合（「フェイル」「ソフトフェイル」「ニュートラル」など）、受信サーバーは設定に応じてメールをリジェクト、受信、または別の扱いを行います。
SPFは単独では完全なセキュリティソリューションとはなりませんが、他の電子メール認証プロトコル（例：DKIM、DMARC）と組み合わせることで、効果的な電子メールセキュリティ戦術の一部となります。
DNSレコードの追加または編集
DNS管理ツールを使用してドメインのDNS設定にアクセスし、新しいTXTレコードを追加または既存のTXTレコードを編集します。次の情報を入力します。
- レコードタイプ: TXT
- ホスト名: @（これはドメイン名自体を表します）
- テキスト値:
v=spf1 <mechanisms> ~all
TXTレコードの確認
まず、現在のドメインのTXTレコードが存在するかどうかを確認します。これは、DNS管理ツールや dig コマンドを使用して行うことができます。digコマンドは、DNS（Domain Name System）サーバーからドメイン名とIPアドレスの情報を取得するために使用されるネットワーク管理ツールです。このツールは、問い合わせやトラブルシューティングのために役立ちます。
基本的な使い方
dig <domain> <query-type><domain>: 問い合わせたいドメイン名を指定します。<query-type>: DNSリソースレコードタイプを指定します（例：A, AAAA, MX, NS, CNAME）。省略した場合は、デフォルトでAレコードが選択されます。
SPFはTXTレコードですので
dig <domain> TXT<domain> の部分を自分のドメイン名に置き換えてください。
よく使われるオプション
+short: 結果を簡潔に表示します。@<dns-server>: 指定したDNSサーバーに問い合わせを行います。
dig @8.8.8.8 txt google.com +short
"onetrust-domain-verification=de01ed21f2fa4d8781cbc3ffb89cf4ef"
"MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
"globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
"google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
"apple-domain-verification=30afIBcvSuDV2PLX"
"atlassian-domain-verification=5YjTmWmjI92ewqkx2oXmBaD60Td9zWon9r6eakvHX6B77zzkFQto8PQ9QsKnbf4I"
"v=spf1 include:_spf.google.com ~all"
"docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
"webexdomainverification.8YX6G=6e6922db-e3e6-4a36-904e-a805c28087fa"
"facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
"google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
"docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"これで、SPF設定が完了しました。メール送信時にSPFによる認証が行われるようになります。
SRS (Sender Rewriting Scheme)の導入
SRS (Sender Rewriting Scheme)をPostfixで設定する手順を以下に示します。この例では、postsrsdというツールを使用してSRSを実装します。
前提条件
すでに、Postfixが導入済みという前提です。
検証時の環境は、AlmaLinux9.2です。
必要なパッケージのインストール
必要なパッケージをインストールします。
sudo yum -y install epel-release
sudo yum -y install postsrsdpostsrsdの設定
次に、/etc/default/postsrsd 設定ファイルを編集し、必要な設定を行います。
※環境によっては/etc/sysconfig/postsrsdかも
sudo vi /etc/default/postsrsd以下のように変更して保存してください（ドメイン名とシークレットキーサイズを更新して適切な値に置き換える必要があります）
SRS_DOMAIN=yourdomain
#VirtualDomain運用の場合、/etc/default/excluded_domainsに全てのドメインを追加
SRS_EXCLUDE_DOMAINS="$(cat /etc/default/excluded_domains)"
CHROOT=/var/spool/postsrsd
RUN_AS=postsrsd
SRS_SECRET_LENGTH=24VirtualDomain運用の場合、/etc/default/excluded_domainsに全てのドメインを追加します。
追加してないドメインは Return-Path: 同様に From:ヘッダーが書き換えられてしまいます。
SRS_EXCLUDE_DOMAINSに追加してもReturn-Path:は期待通り書き換えしてくれます。
SPF, DMARCは、From:のドメインで検証するため、全てのドメインにSPF, DMARCレコードを正しく登録しておく必要があります。
From: SRS0=9QU0=CC=example.net=test@example.netSRS_SECRET_LENGTH オプション
PostSRSd（Sender Rewriting Schemeデーモン）で生成されるトークンの秘密鍵部分の長さを設定するために使用されます。このオプションは、SRSアドレスのセキュリティレベルを調整します。
SRS_SECRET_LENGTHの値が大きいほど、生成されるSRSアドレスの秘密鍵部分が長くなり、予測や総当たり攻撃に対してより強固になります。ただし、値が大きすぎると、SRSアドレスが非常に長くなり、一部のメールシステムで問題が発生することがあります。
デフォルトでは、SRS_SECRET_LENGTHオプションは設定されておらず、秘密鍵の長さは自動的に16文字に設定されます。手動で設定する場合は、次のように設定ファイル（/etc/sysconfig/postsrsdまたは/etc/default/postsrsd）に追記してください。
SRS_FORWARD_PORT オプション
postsrsdが送信者アドレスの書き換えを行うために待ち受けるTCPポート番号です。デフォルトのポート番号は10001です。このポートで受信したメールが、SRSにより送信元アドレスが書き換えられ、宛先に転送されます。
SRS_REVERSE_PORT オプション
postsrsdが送信者アドレスの書き換えを解除するために待ち受けるTCPポート番号です。デフォルトのポート番号は10002です。このポートで受信したメールが、SRSで書き換えられた送信元アドレスを元に戻し、宛先に転送されます。
CHROOT オプション
PostSRSd の chroot ディレクトリーを設定する際には、一般的に /var/spool/postsrsd をおすすめします。セキュリティと管理の観点から、このディレクトリーは専用のユーザーとグループが所有していることが望ましいです。
以下に、PostSRSd の chroot 環境を構築する手順を示します。
専用ユーザーとグループを作成
sudo groupadd -r postsrsd
sudo useradd -r -g postsrsd -d /var/spool/postsrsd -s /sbin/nologin postsrsdディレクトリと権限を設定
sudo mkdir -p /var/spool/postsrsd
sudo chown -R postsrsd:postsrsd /var/spool/postsrsd
sudo chmod 0750 /var/spool/postsrsd変更を適用し、PostSRSd サービスを再起動
sudo systemctl daemon-reload
sudo systemctl restart postsrsd
PostSRSd が /var/spool/postsrsd ディレクトリーで chroot 環境を使用するように設定されます。
Postfixの設定
次に、Postfixの設定ファイル /etc/postfix/main.cf を編集し、postsrsdとの連携を追加します。
sudo vi /etc/postfix/main.cfファイルの末尾に以下の行を追加します。
#
### SRS (Sender Rewriting Scheme)
#
#sender_canonical_maps = hash:/etc/postfix/canonical
sender_canonical_maps = hash:/etc/postfix/canonical,tcp:localhost:10001
recipient_canonical_maps = tcp:localhost:10002
既存のsender_canonical_mapsや、recipient_canonical_mapsがある場合は、 ,(カンマ)で区切って複数記述してください。2行に分けて記述するとエラーになります。
サービスの再起動
設定変更後、 postsrsd および postfix サービスを再起動して変更内容を適用します。
sudo systemctl restart postsrsd
sudo systemctl restart postfixPostfixと連携するSRSが構成されました。メール転送時にSRSが有効になります。
