はじめに
技術部インフラグループの鈴木です。
以前、「【いまさらやるPostfix】GmailにPostfix+Rspamd(SPF/DKIM)を使ってメールを送る」という記事で、自前のサーバからGmailへメールを送信する方法について解説しました。
今回はその続編として、PostfixとRspamdを使い、受信したメールをGmailへ転送する設定に焦点を当てます。
Postfixの構築
Postfixの基本的なインストールや設定については、前回の記事で詳しく解説していますので、そちらをご参照ください。
メールを転送する設定
以前の設定に加えて、特定のドメイン宛のメールを受け取り、指定したメールアドレス（今回はGmail）に転送するための設定を行います。
まず/etc/postfix/main.cfに以下の設定を追記します。これによりvirtual_alias_domainsで指定したドメイン宛のメールがvirtual_alias_mapsで指定したファイルに基づいて転送されるようになります。
virtual_alias_domains = yabaibuki.dev virtual_alias_maps = hash:/etc/postfix/virtual
次に、転送ルールを定義する /etc/postfix/virtual ファイルを以下のように作成します。この例では、forward-test@yabaibuki.dev 宛に届いたすべてのメールを ****@gmail.com に転送します。
# /etc/postfix/virtual forward-test@yabaibuki.dev ****@gmail.com
ファイルを作成したら、Postfixが参照できる形式のデータベースを作成し、設定をリロードします。
$ sudo postmap /etc/postfix/virtual $ sudo systemctl restart postfix
Rspamdの構築
前提知識
Header FROMとEnvelope FROMの違いについて
メールにおける2種類の送信元について簡単に説明します。
Header From:私たちがメールソフトで普段目にする、お馴染みのFrom:ヘッダです。Envelope FROM:メールサーバ同士が実際に通信する際に使用する配送情報です。
SPF認証が検証するのは、後者のEnvelope FROMです。
ARC (Authenticated Received Chain) とは？
メールを転送すると、Envelope FROM(送信元IPアドレス)が変わってしまうため、SPF認証は失敗します。
またDKIMはメールのヘッダや本文の内容を基に電子署名を作成しますが、メーリングリストは、例えば件名に[ML-Name]のような接頭辞を付け加えたり、本文の末尾に何かしらの情報を追記(退会URLなど)したりすることがあります。
このように署名された内容が変更されると、メールのハッシュ値が署名時と異なることで、受信側で署名の検証が失敗してDKIM認証も無効となってしまいます。
ARC (Authenticated Received Chain) は、この問題を解決するための仕組みです。各転送サーバが、受信したメールの認証結果（SPFやDKIM）を検証し、その結果をヘッダに署名して次のサーバへ渡します。これにより、認証の連鎖が保持され、最終的な受信者は元のメールが正当なものであったことを確認できます。
インストール・初期設定
Rspamdのインストールと初期設定、およびSPF/DKIMの設定については、前回の送信編で詳しく解説しています。基本的な手順は同じですので、以下の記事を参考にしてください。
ARCの設定
Rspamdは標準でARCの署名・検証に対応しています。RspamdにARC署名を有効にするには、以下の設定を行います。今回は、既存のDKIM署名用の鍵をARC署名にも流用する形で設定します。
まず、ARC署名用の鍵を格納するディレクトリを作成し、適切なパーミッションを設定します。
$ sudo mkdir -p /var/lib/rspamd/arc $ sudo chown _rspamd:_rspamd /var/lib/rspamd/arc $ sudo chmod 750 /var/lib/rspamd/arc
今回は既存のDKIMの鍵ファイルへのシンボリックリンクをARC用の鍵として作成します。これにより、鍵の管理を一元化できます。
# 例: DKIMの鍵が /var/lib/rspamd/dkim/yabaibuki.dev.20250529.key の場合 $ sudo ln -s /var/lib/rspamd/dkim/yabaibuki.dev.20250529.key /var/lib/rspamd/arc/yabaibuki.dev.20250529.key
最後にRspamdにARC署名を有効にするための設定ファイル (/etc/rspamd/local.d/arc.conf) を作成します。
# /etc/rspamd/local.d/arc.conf
sign_local = true;
domain {
yabaibuki.dev {
# ARC署名鍵のパス
path = "/var/lib/rspamd/arc/yabaibuki.dev.20250529.key";
# DKIMの鍵をARCの鍵としても使用するためセレクタは同じとしている
selector = "20250529";
}
}
設定を反映させるためにRspamdを再起動します。
$ sudo systemctl restart rspamd
これで、Rspamdを通過するメールに対して、DKIM署名と合わせてARC署名が付与されるようになります。
メール転送テスト
設定が完了したら、実際にメールが正しく転送され、ARC署名が付与されているかを確認します。
XXXXXX@livesense.co.jpから、Postfixサーバで設定した転送用アドレス（forward-test@yabaibuki.dev）へメールを送信します。そのメールがGmailに転送され、ヘッダがどうなっているかを確認します。
graph TD
A[Google Workspace<br>XXXXXX@livesense.co.jp] -- "1. forward-test@yabaibuki.devへメール送信" --> B{転送用サーバ<br>yabaibuki.dev};
B -- "2. 最初のARC署名 (i=1) を付与" --> C{Gmailサーバ<br>mx.google.com};
C -- "3. ARC(i=1)を検証し、<br>次のARC署名(i=2)を付与" --> D[Gmailの受信トレイ<br>****@gmail.com];
ARCのメールヘッダ
Gmailで受信したメールのメールヘッダを確認します。以下のようなヘッダが確認できれば成功です。
ARC-Seal: ARCヘッダの正当性を検証するための署名です。ARC-Message-Signature: メッセージ本文の署名です。ARC-Authentication-Results: 認証の連鎖を示します。i=XXXはARCチェインの回数を表し、arc=passとなっていれば、ARCの検証に成功したことを意味します。
実際のメールヘッダ
以下は、「XXXXXX@livesense.co.jp」から forward-test@yabaibuki.dev を経由してGmailに届いた場合のメールヘッダを加工したものです。
ARC-Seal: i=1; a=rsa-sha256; t=1722325200; cv=none;
d=yabaibuki.dev; s=20250529;
b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yabaibuki.dev;
s=20250529; ...
ARC-Authentication-Results: i=1; yabaibuki.dev;
spf=pass smtp.mailfrom=XXXXXX@livesense.co.jp;
dkim=pass header.i=@livesense.co.jp
... (他のヘッダ) ...
ARC-Authentication-Results: i=2; mx.google.com;
arc=pass (i=1 spf=pass dkim=pass fromdomain=livesense.co.jp);
spf=fail (google.com: domain of XXXXXX@livesense.co.jp does not designate XXX.XXX.XXX.XXX as permitted sender)
このヘッダは2段階で評価されます。
転送サーバ(yabaibuki.dev)が作成したi=1ヘッダ
ARC-Authentication-Results: i=1で始まるヘッダは、転送サーバ(yabaibuki.dev)が作成したARC署名です。
転送サーバ(yabaibuki.dev)はXXXXXX@livesense.co.jpから届いた元のメールを検証し、spf=pass かつ dkim=pass であったことを確認します。
その認証成功という結果を、ARCの仕組みを使ってヘッダに記録し、電子署名をつけます。これがARCチェーンの最初の輪（i=1）となります。
最終受信者(Gmail)が検証したi=2ヘッダ
ARC-Authentication-Results: i=2で始まるヘッダは、最終的な受信者であるGmailのサーバが行った評価です。
まずGmailは転送元のあなたのサーバ（IP: XXX.XXX.XXX.XXX）に対してSPF認証を行いますが、転送されたことによりspf=failとなります。
しかし、ここでGmailはi=1のARCヘッダを見つけ、その署名を検証します。この場合、署名が正しかったため、arc=pass と評価します。
これによりGmailは「SPFは失敗したが転送元(yabaibuki.dev) が『元のメールは正当だった』と証明している」と判断します。
このARCの連鎖のおかげで、転送によって発生してしまう認証の失敗を乗り越え、メールは迷惑メールにならずに受信トレイへ届く可能性が大幅に向上します。
おわりに
今回は、PostfixとRspamdを使ってメールを転送する際に、ARC署名を付与する方法について解説しました。Rspamdは、SPF、DKIM、DMARC、そしてARCといった主要なメール認証技術を単体でサポートしているため、複数のミドルウェアを組み合わせる必要がありません。
メール転送やメーリングリストの運用において、メールの到達性は非常に重要です。本記事で紹介したARCの設定は、将来的な受信要件の厳格化に対する有効な投資となると感じています。
