OpenARCをPostfixに導入する方法｜ARC署名の設定・検証手順を解説

最終更新日：2026.03.12

近年、メールを取り巻く環境は大きく変化しています。GmailやOutlookをはじめとした主要なメールサービスでは迷惑メール対策が年々強化されており、送信ドメイン認証（SPF/DKIM/DMARC）を正しく設定することは、今や事実上の前提条件となっています。

一方で、次のような課題も顕在化しています。

SPF/DKIM/DMARCをすべて設定していても、転送を経由すると迷惑メールとして扱われる
DMARCポリシーを厳格にすると、メーリングリストや転送が成立しなくなる

こうした問題が起こる背景には、従来のメール認証モデルが「送信者から受信者へ直接届く」構成を前提としており、「転送」を想定していなかったことがあります。

この課題に対する現実的な解決策として登場したのが、ARC（Authenticated Received Chain）です。

本記事では、転送でSPF/DKIM/DMARCが失敗する理由から、ARCの基本的な考え方、ARCを実装するためのOSSであるOpenARCをPostfixに導入する方法、Gmailでの検証手順（※）まで解説します。

※検証例としてGmailを利用していますが、ARCはGmail専用の技術ではなく、複数の主要メールサービスで評価されている標準的な技術です

前提知識：転送でSPF/DKIM/DMARCが失敗する理由

ARCは、転送により送信ドメイン認証が失敗する問題を解決する仕組みです。では、そもそもなぜ転送を経由すると認証NGとなってしまうのでしょうか。

本章では、SPF/DKIM/DMARCの基本的な仕組みを簡単に整理したうえで、転送によってこれらの認証が失敗する理由について解説します。

SPF（Sender Policy Framework）

SPFは、「そのドメインのメールを送信してよい送信元IPアドレス」をDNSに公開する仕組みです。

受信側のメールサーバーは、SMTP接続時の送信元IPアドレスと、MAIL FROM（エンベロープFrom）のドメインをもとに、送信元IPアドレスがSPFレコードに含まれているかを検証し、含まれていれば認証結果はpassとなります。

このようにSPFは送信元IPアドレスを基準に判定するため、メールが転送されると送信元IPが転送サーバーのものに変わり、認証結果がfailになりやすいという特徴があります。

DKIM（DomainKeys Identified Mail）

DKIMは、メールに電子署名を付与し、「このメールは確かにこのドメインから送信され、途中で改ざんされていない」ことを証明する仕組みです。

送信側は秘密鍵で署名を行い、受信側はDNSに公開されている公開鍵を使って署名を検証します。

DKIMの場合、署名対象となる本文やメールヘッダが変更されなければ、メールが転送されても認証結果はpassとなります。ただし、転送時に文字コード変換やメーリングリストによる本文の追記などの加工が行われると、署名の検証が失敗し認証がfailになる場合があります。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）

DMARCは、SPF・DKIMの認証結果と、差出人（ヘッダFrom）のドメインを突き合わせることで「送信元ドメインのなりすましが行われていないか」を検証する仕組みです。

DMARCは、ヘッダFromのドメインと、SPFの認証に使用したエンベロープFromのドメイン、またはDKIMの認証（署名）に使用したドメインが一致しているか（アライメント）によって認証を行います。

DMARCはなりすまし対策として非常に有効な技術ですが、前述の通り転送やメーリングリストを経由するとSPFやDKIMが失敗しやすくなるため、結果としてDMARCもfailになりやすいという特徴があります。

ARC（Authenticated Received Chain）とは？

SPF/DKIM/DMARCは、もともと「送信者から受信者へ直接メールが届く」という構成を前提に設計されています。

しかし実際のメール運用では、外部ゲートウェイの通過、別アドレスへの自動転送、メーリングリストの経由など、複数のサーバーをまたいで送信されることが一般的です。こうした構成では、転送時に送信元IPアドレスが変わることでSPFがfailとなったり、本文の追加や加工によってDKIMがfailとなったりするケースが発生します。

これは、従来の認証方式が「転送」を前提としていなかったことによる構造的な問題です。

この課題に対する現実的な解決方法として登場したのが、ARC（Authenticated Received Chain）です。本章では、ARCの基本的な考え方について解説します。

ARC（Authenticated Received Chain）の考え方

ARCはSPFやDKIMの代替技術ではなく、失敗を「なかったこと」にする技術でもありません。ARCの考え方は非常にシンプルで、その目的は「転送される前の時点では正しく認証されていた」という事実を後段のサーバーに伝えることにあります。

例えば、あるメール中継サーバーを通過する際に、メール本文への追記が行われるとします。この場合、中継サーバーの時点ではDKIMはpassしていても、その後に本文が追加されることで、後段のメールサーバーではDKIM署名の検証に失敗しfailとなります。その結果、最終的にメールを受信するサーバーでは、不審なメールと判断されやすくなってしまいます。

中継サーバーによってメール本文が追加され、DKIM署名の検証に失敗するケースを説明した図

そこで、中継サーバーにARCを実装すると、その時点でのSPF/DKIM/DMARCの認証結果が記録され、次のサーバへ引き継がれるようになります。後段のサーバーはARCの情報を参照することで、「DKIMはfailになっているが、不審なメールではないようだ」と判断できるようになります。

中継サーバーにARCを実装することで、DKIMの認証結果が引き継がれる仕組みを説明した図

近年のメール評価では、単純な「pass/fail」だけでなく「どのサーバーが、どの時点で、どう判断したか」という履歴が重視されるようになっています。ARCはその履歴を安全に伝えるための仕組みだと考えると分かりやすいでしょう。

ARCの仕組みや設定方法については、以下の記事で詳しく解説しています。
メールのARCとは？ ARCの仕組み、設定が必要なケースを解説｜ベアメールブログ

OpenARCをPostfixに導入する手順（インストール〜設定）

それでは、実際にOpenARCをPostfixに導入する手順を解説します。

今回の検証では、実際の業務環境でよく見られる構成を再現しています。relay_server01ではすでにDKIMが設定されており、2つの中継サーバーを経由して、最終的に外部のメールサービスへ配送される構成です。relay_server02にOpenARCを導入し、relay_server03では一般的な配送のみを実施します。

なお、今回はARCの検証がメインとなるため、relay_server01およびrelay_server03の初期構築、AWS EC2のネットワーク設定などの説明は省略し、relay_server02の構築・設定を中心に解説します。

また、AWSでは25番ポートのアウトバウンド通信に制限があります。そのため本検証では、relay_server02とrelay_server03の間を25番ポートではなく、10025番ポートでSMTP接続することで制限を回避しています。

1. OpenARCをインストールする

まず、relay_server02を構築します。本検証では、以下のOSにOpenARCをインストールします。

# cat /etc/redhat-release
AlmaLinux release 8.10 (Cerulean Leopard)

※補足
検証当初はAmazonLinux2023やAlmaLinux９での実装を試みましたが、AmazonLinux2023ではOpenARCが正常に作動せず、AlmaLinux９では必要なライブラリがレポジトリに存在しなかったため、最終的にAlmaLinux８を使用しています。

OpenARC単体ではメールの送受信を行えないため、MTAであるPostfixと組み合わせて使用する必要があります。また、ARC署名用の鍵を生成するためにOpenDKIMも併せてインストールします。

OpenARCはEPEL（Extra Packages for Enterprise Linux）レポジトリから提供されているため、まずEPELを有効化します。

# dnf install -y epel-release
# dnf install -y openarc postfix opendkim opendkim-tools

2. ARC鍵を作成してDNSに登録する

インストールが完了したら、ARC署名に使用する鍵を作成します。まず、鍵を保存するディレクトリを作成します。

mkdir -p /etc/openarc/keys

ARC署名にはDKIM形式の鍵を使用します。ここでは、以下の設定で鍵を生成します。

セレクタ：arc2025
ドメイン：example.jp

# opendkim-genkey -D /etc/openarc/keys -d example.jp -s arc2025
# ll /etc/openarc/keys
total 8
-rw——-. 1 openarc openarc 887 Dec 17 19:06 arc2025.private
-rw——-. 1 openarc openarc 314 Dec 17 19:06 arc2025.txt
# chown openarc:openarc /etc/openarc/keys/arc2025.private
# chmod 600 /etc/openarc/keys/arc2025.private

arc2025.txtを開くと以下のようになっています。

# cat /etc/openarc/keys/arc2025.txt
arc2025._domainkey IN TXT ( “v=DKIM1; k=rsa; “
“p=MIGfM…” ) ; —– DKIM key arc2025 for example.jp

DKIMと同じようにDNSへ公開鍵を登録する必要があるため、上記を参考にDNSへDKIMレコードを登録します。

arc2025._domainkey.example.jp IN TXT “v=DKIM1;k=rsa;p= MIGfM…”

3. OpenARCの設定を行う

ARC鍵の作成・登録が完了したら、OpenARC本体の設定を行います。

ここでは、以下の作業を行います。

OpenARCの設定ファイルの編集
Internal-hostsの設定
設定内容の動作とサービスの起動

OpenARCの設定ファイルを編集する

まず、OpenARCの設定ファイルを編集します。

# vi /etc/openarc.conf

PidFile /run/openarc/openarc.pid
Socket inet:8893@localhost
UserID openarc:openarc
Syslog yes
SyslogFacility yes
SoftwareHeader yes
AuthservID arc-gw.example.jp
Domain example.jp
Selector arc2025
KeyFile /etc/openarc/keys/arc2025.private
InternalHosts /etc/openarc/internal-hosts
Canonicalization relaxed/relaxed
SignatureAlgorithm rsa-sha256
Mode sv

最後に記載している「Mode sv」は、OpenARCの動作モードを指定する設定です。「s」は署名(Sign)、「v」は検証(Verify)を意味し、svを指定すると署名と検証の両方が有効になります。

internal-hostsの設定を行う

続いて、internal-hostsファイルを作成します。internal-hostsは「信頼できる送信元」を定義するリストで、このリストに含まれるホストからのメールに対してARC署名が付与されます。

一方、internal-hostsに含まれない送信元からのメールについては、ARC署名は付与されません。既存のARCヘッダが存在する場合のみ、その情報が改ざんされていないかの検証が行われます。ARCヘッダ自体が存在しないメールについては、ARCの検証は行われません。

internal-hostsは、社内中継と外部転送の境界を明確にするために使用されることが多く、実運用において非常に重要な設定項目です。

# vi /etc/openarc/internal-hosts

127.0.0.1
::1
xxx.xxx.xxx.xxx #接続元IP(relay_server01)

接続元IPには、以下の形式を指定できます。

IPアドレス
CIDR
ホスト名

設定内容を確認する

設定が完了したら、構文チェックを行います。

# openarc –n -c /etc/openarc.conf

エラーメッセージが表示された場合は、設定に誤りがある可能性があります。何も出力されなければ、設定ファイルは正しく記述されています。

OpenARCを起動する

設定確認後、OpenARCを起動します。

# systemctl enable –now openarc
# systemctl status openarc

「Active:active(running)」と表示されていれば、正常に起動しています。

4. Postfixの設定を行う

OpenARCの設定が完了したら、Postfixの設定を行います。

Postfixでは、以下の2つを設定します。

OpenARCとの連携設定
relay_server03へ転送するための設定

OpenARCとの連携設定を行う

まず、PostfixとOpenARCを連携させるための設定を行います。以下の設定を追加してください。

# vi /etc/postfix/main.cf

mynetworks = 127.0.0.0/8,<送信元IP(relay_server01)>
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8893
non_smtpd_milters = $smtpd_milters

relay-server03へ転送するための設定を行う

続いて、同じくmain.cfに対してrelay-server03へ転送する設定を追記します。

relayhost=[xxx.xxx.xxx.xxx]:10025

relayhostにはrelay_server03のIPアドレスを設定し、10025番ポートで転送する設定を行います。通常の25番ポートで転送する場合には、以下のように指定します。

relayhost=[xxx.xxx.xxx.xxx]:25

続いて、10025番ポートでメールを受信するためのトランスポートを設定します。

# vi/etc/postfix/master.cf

10025 inet n -n – – smtpd
-o smtpd_milters=inet:127.0.0.1:8893
-o smtpd_banner=ARC_inbound
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_recipient_restrictions=permit_mynetworks,reject

これでPostfix側の設定は完了です。

postfixの設定を確認し、起動する

設定が完了したら、設定ファイルに対し構文チェックを行います。

# postfix check

エラーが表示されなければ問題ありません。続いて、Postfixを起動します。

# systemctl start postfix

10025番ポートの動作確認を行う

念のため、10025番ポートで接続できるか確認します。以下のように表示されれば、接続は成功です。

# telnet localhost 10025
Trying ::1…
Connected to localhost.
Escape character is ‘^]’.
220 ARC_inbound

この状態になれば、PostfixとOpenARCの連携設定は完了です。

5. relay-server01側の事前準備を行う

relay_server01では、あらかじめDKIMの設定を行っておく必要があります。詳しい設定方法については、以下の記事を参考にしてください。

DKIMレコードの書き方は？設定・確認方法や失敗例も解説｜ベアメールブログ
 OpenDKIM×Postfixを使ってDKIMを設定する｜ベアメールブログ

relay_server01の役割は、受信したメールをOpenARCが導入されているrelay_server02へ、10025番ポートで転送することです。そのため、設定ファイル(main.cf)に以下の設定を追記します。

# vi /etc/postfix/main.cf

relayhost = [<relay_server02のIP>]:10025

これでrelay_server01の設定は完了です。なお、relay_server03については、受信したメールをそのまま後段のサーバーへ配送するのみの構成としているため、特別な設定は行っていません。

GmailでARCヘッダを確認する手順（動作検証）

ARCはRFC 8617で定義されている技術ですが、ステータスは「Experimental(実験)」となっています。そのため、2026年３月時点でARC認証が実装されているメールサービスは多くはありません。

ですが、GmailやOutlookなどの主要メールサービスでは、実運用においてメール評価にARCが取り入れられています。

本章では、Gmail宛にメールを送信し、ARCヘッダが正しく付与されていることを確認します。

1. telnetでテスト送信する

まず、telnetコマンドを使ってrelay_server01へメールを送信します。

# telnet 25
EHLO localhost
MAIL FROM:
RCPT TO:
DATA
From:
To :
Subject: ARC TEST

ARC TEST Mail
.
QUIT

これでメールが送れたはずです。

送信後、メールが受信ボックスへ正常に到達していることを確認します。

無事届いていたので、次にメールのヘッダを確認します。

2. ARCヘッダを確認する

届いたメールのヘッダ情報には、以下のようなARCヘッダが付与されていることが確認できます。

Authentication-Results: arc-gw.; arc=none smtp.remote-ip=<送信元IP>
ARC-Seal: i=1; a=rsa-sha256; d=; s=arc2025; t=1766723612; cv=none; b=n948eW…
ARC-Message-Signature: i=1; a=rsa-sha256; d=; s=arc2025; t=1766723612; c=relaxed/relaxed; bh=ZasH…
ARC-Authentication-Results: i=1; arc-gw.

これは、relay_server02がメールを受信した際に付与した最初のARCヘッダです。この時点で「arc=none」になっているのは、その前のrelay_server01ではARCヘッダを付与していないためです。

i=の意味

ARC認証は多段式で記載され、i=はARCチェーンの段数を示します。relay_server02で「ARC-Seal:i=1;」が付与されていることから、このサーバーでARCチェーンが開始されたことが分かります。

後段のサーバーでARCの検証が行われると、「i=2」、「i=3」といった形で数字が増えていきます。今回の検証では、最終地点であるGmailに到達した時点で「ARC-Seal:i=2;」となっていました。これは、relay_server02で1回目のARC処理、Gmailで2回目のARC検証が行われたことを示しています。

cv=の意味

ARC-Sealヘッダに含まれるcv=は、ChainValidationの略で、ARC履歴が壊れていないかを示します。最初の段階ではARCヘッダが存在していないため、「cv=none」となっています。

その後、Gmailに到達した時点では「cv=pass」となっており、ARCの履歴が壊れずに、正しく検証されたことが確認できます。

まとめ

メールを取り巻く環境は、ここ数年で大きく変化しました。SPF/DKIM/DMARCの整合性や運用状況まで含めて評価されるようになり、送信者側に求められる要件はより厳しくなっています。

実際の運用では、正しく送信しているにもかかわらず、転送や中継によって意図せず認証が失敗してしまうケースも増えています。

ARCは、そのような状況において「途中の時点では問題なく認証されていた」という情報を伝えるための技術です。導入すればすべてが解決するわけではありませんが、転送が日常的に行われる送信環境では有効な選択肢となります。

最近のメール評価においては、単純な「pass/fail」だけでなく、「どの経路を通り、どの時点でどのように判断されたか」といった背景を含めて評価されるようになってきています。ARCは、その変化に対応するための一つの手段として、理解しておきたい技術だといえるでしょう。