ARC
メール転送に弱いSPF/DKIM/DMARC認証を補完
ARC（Authenticated Received Chain）は、メールの認証情報を確実に伝達するための規格です。
メールが複数のメールサーバ（MTA：メール転送エージェント）を経由する際に、各段階での認証結果（SPF、DKIM、DMARCなど）をヘッダーに記録し、伝播させることが可能となります。
これにより、メール転送やメーリングリストの利用時に、SPFやDKIMの検証が失敗してDMARCが適用できないといった問題を回避できます。
ARCは、各MTAがメールに対して「保管履歴チェーン」を形成するため、ARC-Seal、ARC-Message-Signature、ARC-Authentication-Resultsの3種類の認証評価ヘッダーを付加します。
これにより、メールを転送する際、どのMTAがどのような認証評価を行ったかが追跡可能となり、最終受信者は信頼性の高い認証情報を基にメールの取扱いを判断できます。
また、ARCにより、認証プロセスに影響を及ぼす中継サーバによる改変のリスクも軽減されます。
ARCの仕様は、2019年に公開されたRFC8617に詳細が記載されています。
ARCの必要性
メールのドメイン認証は、SPF、DKIM、DMARCによって行われますが、メールの転送によって認証が失敗する問題があります。
ARCは、この問題を解決するために、転送経路上で認証結果を保持・伝達する仕組みです。
- SPFにおける転送の問題点
-
SPFは、送信ドメインが許可するMTA（メール送信サーバ）のIPアドレスリストを基に、メールが正当なサーバから送信されたかを確認します。
しかし、メールが転送されると、再送信されるMTAのIPアドレスが元のリストに含まれない場合が多く、転送メールではSPFチェックが失敗する可能性があります。 - DKIMにおける転送の問題点
-
DKIMは、メールのヘッダーと本文から生成したハッシュ値を、秘密鍵で署名することで認証を行います。
しかし、転送時にヘッダーが変更されたり、件名に「FW:」が追加されたり、本文に追記が行われると、署名と実際の内容が一致せず、DKIM署名が無効になる可能性があります。
特にメーリングリスト経由では、リストの情報が追加されるため、問題が顕著です。 - DMARCにおける転送の問題点
-
DMARCは、Envelope From（実際の送信者アドレス）やDKIM署名のドメインと、ヘッダーFromのドメインが一致しているかを確認することで、なりすましを防ぎます。
しかし、転送時にはEnvelope Fromが転送者やメーリングリストのアドレスに変わるため、ドメインの一致が崩れ、DMARC認証に失敗する場合があります。
転送メールのSPF/DKIM/DMARCの認証
ここで云う「転送」とは、受信箱に一旦入ったメールを転送することを指します。
MTAからMTAとメールが経由するのは、「SMTPリレー」と呼ばれ、ここで云う転送とは異なります。
転送時、受信側のMTA（メール転送エージェント）は転送元のMTAのDNSに問い合わせるのではなく、メールに含まれる情報を元に認証を実施します。
以下は、メールの転送と認証がどのように進行するかの概要です。
- 1. メールの送信
-
送信元MTAは、メール送信時にDKIM署名を付加して認証情報を埋め込みます。
また、送信元MTAは自らのIPアドレスが送信ドメインのSPFレコードに合致していることを前提としてメールを送信しますが、SPFのDNS問い合わせによる検証は受信側MTAで行われます。 - 2. メールの受信
-
受信側MTAは、SPF、DKIMやDMARCモジュールがインストールされていればDKIMやDMARCについて検証を行います。
SPF単体仕様の検証はどのMTAでも一般的ですが、DKIMやDMARCについては、日本で普及しているPostfixが対応していないため、DKIMやDMARCのモジュールを別途インストールして設定していない場合があります。 - 3. メールの転送
-
ユーザが受信箱に入ったメールを転送メールが転送される際、転送するMTAは、多くのMTAでSPF単体仕様での検証を合格させるためにSRS(Sender Rewriting Scheme)と呼ばれる機構を実装してあり、Envelope Fromを転送するドメインのアドレスに変更する場合があります。
SPFについては、SRSで合格できたとしても、DMARCでのSPFベースでのAlignmentチェックは、ヘッダーFromとEnvelopeFromが異なるため不一致となります。
DKIMについては、本文のハッシュ値とヘッダーのハッシュ値は、そのままヘッダに埋め込まれたまま送信されます。
また転送に使われるMTAがDKIM署名に対応していて署名する設定の場合は、転送するドメインでのDKIM署名を付与します。 - 4. 転送メールの最終受信
-
転送されたメールが転送受信側のMTAに到着すると、転送受信側MTAは、メールに記載されたEnvelope FromやDKIM署名をもとに、関連するDNSレコード（主に送信ドメインのもの）を問い合わせ、SPFとDKIMの認証を再実施します。
転送受信側MTAは、DKIMやDMARCの認証に対応していれば、その認証プロセスに従い、処理を行います。
転送受信側MTAは転送されたメールの認証を行う際、メールに記載されたヘッダーFromに従い、元々の送信ドメインのSPF/DKIM/DMARCのDNSレコードを問い合わせますが、転送元のMTAのDNSに問い合わせることはありません。
ARCの仕組み
ARC（Authenticated Received Chain）をプロセスに組み込むと、メールの転送と認証の流れが以下のように変化します。
以下の各ステップは、ARC対応のMTAで処理されることを前提としています。
- 1. メールの送信
-
メール送信時、送信元MTAはまずDKIM署名を付加し、メールの認証情報をヘッダーに埋め込みます。
ARCに対応している送信元MTAでは、このDKIM署名を基に「ARCセットのインデックス0 (i=0)」として最初のARC署名が付与されます。
※ Google WorkspaceやMicrosoft365など、独自ドメインのDKIM設定が行われていない場合は、i=0でのARC署名が付与されない点に注意してください。 - 2. 初回のメール受信
-
受信側MTA（最初の受信者）は、SPF、DKIM、DMARCの検証モジュールを用いてメールの認証を行います。
ARC対応の場合、これらの検証結果を元に、次のARC署名、すなわち「ARCセットのインデックス1 (i=1)」が付与され、認証情報が連鎖的に記録されます。 - 3. メールの転送
-
ユーザが受信したメールを転送する際、転送MTAはSRS (Sender Rewriting Scheme) を利用してEnvelope Fromを転送先ドメインのアドレスに変更する場合があります。
この変更により、SPF検証はSRSにより合格することが期待されますが、ヘッダーFromとEnvelope Fromが異なるため、DMARCのアライメントチェックは不一致となる可能性があります。
一方、DKIM署名は、メール本文やヘッダーに基づいて付与され、そのまま転送される場合もあれば、転送MTAがDKIM再署名を行う場合もあります。
ARC対応の転送MTAでは、転送時の認証検証結果を元に「ARCセットのインデックス2 (i=2)」のARC署名が追加され、認証情報が保持されます。 - 4. 転送メールの最終受信
-
転送されたメールが最終受信側のMTAに到着すると、受信側MTAは、メールに記載されたEnvelope FromやDKIM署名に基づき、送信元ドメインのDNSレコードを問い合わせ、SPFとDKIMの再検証を実施します。
また、ARCヘッダーの検証により、メールが転送中にどのような認証情報の変化があったかを確認し、全体の信頼性を評価します。
DMARCの評価も、ARCにより保存された元の認証情報を考慮するため、転送メールでも適切に認証される可能性が高まります。
ARCは、メール転送中に認証情報が失われることなく連鎖的に保持される仕組みを提供し、転送メールでも元の認証情報に基づいた信頼性の高い評価を可能にします。
ARCヘッダの仕様
ARCは主に以下の3つの新しいヘッダーをメールに追加します。
これらのヘッダーは、メールが転送される際に、元々の認証情報（SPF、DKIM、DMARCの結果）を維持する役割を果たします。
これらのヘッダーを組み合わせることで、ARCはメールが複数のMTAを通過する間、その認証情報を維持し、最終的な受信者のMTAがメールの真正性をより正確に評価できるようにします。
ARCは特に、メール転送やメーリングリストを経由する際の認証問題を解決するために有用です。
- AAR(ARC-Authentication-Results)
- 認証結果の情報を記録。
- AS(ARC-Seal)
- ARCによる認証情報の完全性と信頼性を保証するための署名
- AMS(ARC-Message-Signature)
- メールヘッダとボディが改竄されていないことを保証するための署名
AAR(ARC-Authentication-Results)
AARヘッダーは、メールが前のホップ（転送元）のMTAによって受信された時点での認証結果を記録します。
このヘッダーには、SPF、DKIM、DMARCの各認証メカニズムの結果が含まれます。
AARは、メールが次のホップ（転送先）のMTAに到達した際に、元の認証状態を提供するために使用されます。
i=1; mx.google.com; dkim=pass header.i=@domain.com header.s=xyz header.b=Q9TN1jXp; spf=pass(google.com: domain of user@domain.com designates 101.53.164.222 as permitted sender) smtp.mailfrom=user@domain.com; dmarc=pass(p=REJECT dis=NONE) header.from=domain.com
上記のAARヘッダの内容について解説します。
この認証結果は、メールがdomain.comから正当に送信され、各種のメール認証テスト（DKIM、SPF、DMARC）に合格したことを示しています。
i=1; mx.google.com;-
これは、メールがGoogleのメールサーバ（mx.google.com）を通過したことを示しています。
"i=1"は、ARCセットのインスタンス番号で、ARCチェーンの最初のセットであることを意味します。 dkim=pass header.i=@domain.com header.s=xyz header.b=Q9TN1jXp;-
dkim=passは、DKIMのチェックが合格したことを意味します。
これは、メールが送信されたドメイン（domain.com）が、メールヘッダーに含まれるデジタル署名を使ってメールの真正性を保証していることを示しています。- header.i=@domain.com ... DKIM署名がdomain.comドメインによって行われたことを示しています
- header.s=xyz ... 使用されたDKIMセレクター（署名の設定を特定するための識別子）です
- header.b=Q9TN1jXp ... DKIM署名の一部です。
spf=pass(google.com: domain of user@domain.com designates 101.53.164.222 as permitted sender) smtp.mailfrom=user@domain.com;-
- spf=passは、SPFのチェックが合格したことを意味します。
これは、メールが正当な送信元から送信されたことを示しています。 google.com: domain of user@domain.com designates 101.53.164.222 as permitted senderは、user@domain.comのドメインがIPアドレス101.53.164.222を許可された送信元として指定していることを示しています。smtp.mailfrom=user@domain.comは、メールのEnvelope From（送信元）アドレスです。
- spf=passは、SPFのチェックが合格したことを意味します。
dmarc=pass(p=REJECT dis=NONE) header.from=domain.com-
dmarc=passは、DMARCのポリシーが合格したことを意味します。
メールの「From」ドメインが、SPFとDKIMの認証結果に基づいてDMARCポリシーを満たしていることを示しています。p=REJECTは、DMARCポリシーが「REJECT」に設定されていることを意味します。
つまり、DMARCのチェックに合格しないメールは拒否されるべきです。dis=NONEは、DMARCの失敗に対する処置が「NONE」（何もしない）に設定されていることを示しています。
これは、メールがDMARCに合格したため、拒否や隔離の必要がないことを意味します。header.from=domain.comは、メールの「From」ヘッダーのドメインです。
AS(ARC-Seal)
ASヘッダーは、ARCによる認証情報の完全性と信頼性を保証するための署名です。
この署名は、ARCの他のヘッダー（AARとAMS）が改竄されていないことを確認するために使用されます。
ASは、メールが転送される際に、各ホップで新たに生成され、以前のホップの認証情報を保護します。
i=1; a=rsa-sha256; t=1608028598; cv=none; d=google.com; s=arc-20160816; b=u1Tiu150Jf7sRT49ZVeFUaBLUbSILgotn8kMYGlzMA5L7sRZmFDv03aiFM0LrNdJ/A+bFlt9A+6gAcGFGYyZGWBSeb+h3WqPMfjVC7GdLdrTQPFUkG19DrazsgHo2/hEbg2WbnqVzBxJB500yYVqwlph1pntaG/YWZSN2Wawr9HHgeQJvb9Ed/BHSM7gfj7zxOBUhvbqXLmp6DaBtTpyMZYh5taAoR8DBdYS7fLuUER7S2fA50S6h7GpCtuWWErlGpop1LXSDH/WHOw1rWzq01tC8P5zbavayZ+YsANKL4By+kqQrlOAPO4N3g+YaDyjxnTiL2eG+eEbLrGqKAD2/g==
上記のASヘッダの内容について解説します。
このヘッダーにより、mx.google.comの認証を電子署名によって担保します。
i=1;- "i=1"はARCセットのインスタンス番号で、これがARCチェーンの最初のセットに紐づいていることを意味します。
a=rsa-sha256;-
これは使用される署名アルゴリズムを指定しています。
ここでは、RSAとSHA-256ハッシュアルゴリズムが使用されています。 t=1608028598;-
この部分は、署名が生成された時刻をUNIXタイムスタンプ（エポック秒）で示しています。
1608028598は、特定の日時を表しています。 cv=none;-
"cv"はChain Validationの略で、このフィールドはARCチェーンの検証状態を示します。
"none"は、前のARCセットがない、または検証がまだ行われていないことを意味します。 d=google.com;-
この部分は、署名を行ったドメインを指定しています。
ここでは"google.com"が署名ドメインです。 s=arc-20160816;-
これは使用されるDKIMセレクタを示しており、特定の署名キーを識別します。
"arc-20160816"は、google.comドメインの特定のARCキーセットを指します。 b=u1Tiu150Jf7sRT49ZVeFUaBLUbSILgotn8kMYGlzMA5L7sRZmFDv03aiFM0LrNdJ/A+bFlt9A+6gAcGFGYyZGWBSeb+h3WqPMfjVC7GdLdrTQPFUkG19DrazsgHo2/hEbg2Wb nqVzBxJB500yYVqwlph1pntaG/YWZSN2Wawr9HHgeQJvb9Ed/BHSM7gfj7zxOBUhvbqXLmp6DaBtTpyMZYh5taAoR8DBdYS7fLuUER7S2fA50S6h7GpCtuWWErlGpop1LXSDH/WHOw1rWzq01tC8P5zbavayZ+YsANKL4By+kqQrlOAPO4N3g+YaDyjxnTiL2eG+eEbLrGqKAD2/g==;-
この部分は実際のデジタル署名です。
メールのヘッダとARC認証結果（ARC-Authentication-Results）を含むメッセージの一部をハッシュ化し、その後秘密鍵で暗号化して生成されます。
AMS(ARC-Message-Signature)
AMSヘッダーは、メール本体とヘッダー（特に転送によって変更されがちなヘッダー）のDKIMスタイルの署名です。
この署名は、メールの内容が転送プロセス中に改竄されていないことを保証するために使用されます。
AMSは、メールが各ホップを通過する際に生成され、メールの内容が元の送信時点から変更されていないことを確認します。
i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:subject:message-id:cc:to:from:date:dkim-signature; bh=utFVsQV90imCkfdAbs4rSFF+Hh1llV6Wdr1n2w6XqxA=; b=L7JNVN7na3akSOKhBXao0YbGpYAootoeq80HHhuHbDsFoZAH47Kjb92JZh8xjcZp32vrtOSBFh+1PLWAwsJX8MOfz8/l1du6HOI1NdF32efp7nOIQOQYWzI3UEaVHEwli2D71SNvNgz/Zx5KaL5NBsqLrlytLaw343MhvFT2vRd9gBV23BIM7ihRe3WsEo2islcLwzxvuTFKgillU6m1vJUDQxFLnjngcYs/URfmV3Zu83VdlV2igAlq2CpWdA4u9jo2gJDGOfselSOZITc9W4sFRcJ/2rbwUaVW4f5TMNhIZ2YpHXOn87lh/yB5/1w6nLXOyVjmp5qp6WE/2ELYIg==
上記のAMSヘッダの内容について解説します。
このヘッダーにより、メール本文(ヘッダとボディ)の内容が改竄されていないことを電子署名によって担保します。
i=1;- これはARCセットのインスタンス番号を示しており、"i=1"はこれがARCチェーンの最初のセットであることを意味します。
a=rsa-sha256;- この部分は使用される署名アルゴリズムを指定しており、ここではRSAとSHA-256ハッシュアルゴリズムが使用されています。
c=relaxed/relaxed;-
この部分は署名の適用ポリシーを示しています。
"relaxed/relaxed"は、ヘッダフィールドと本文の両方に対して比較的寛容な処理が行われることを意味します。
つまり、一部の空白や行の折り返しなどが署名の検証過程で無視される可能性があります。 d=google.com;- "d"は署名を行ったドメインを示しており、ここでは"google.com"が署名ドメインです。
s=arc-20160816;-
"s"は使用されるDKIMセレクタを示しており、特定の署名キーを識別します。
"arc-20160816"は、google.comドメインの特定のARCキーセットを指します。 h=mime-version:subject:message-id:cc:to:from:date:dkim-signature;-
この部分は署名されたヘッダーフィールドのリストです。
署名プロセスに含まれるヘッダーの種類を示しています。 bh=utFVsQV90imCkfdAbs4rSFF+Hh1llV6Wdr1n2w6XqxA=;-
"bh"はボディハッシュ値で、メール本文のハッシュ値を示しています。
これは、メール本文が署名時点から変更されていないことを保証します。 b=L7JNVN7na3akSOKhBXao0YbGpYAootoeq80HHhuHbDsFoZAH47Kjb92JZh8xjcZp32vrtOSBFh+1PLWAwsJX8MOfz8/l1du6HOI1NdF32efp7nOIQOQYWzI3UEaVHEwli2D71SNvNgz/Zx5KaL5NBsqLrlytLaw343MhvFT2vRd9gBV23BIM7ihRe3WsEo2islcLwzxvuTFKgillU6m1vJUDQxFLnjngcYs/URfmV3Zu83VdlV2igAlq2CpWdA4u9jo2gJDGOfselSOZITc9W4sFRcJ/2rbwUaVW4f5TMNhIZ2YpHXOn87lh/yB5/1w6nLXOyVjmp5qp6WE/2ELYIg==;-
"b"は実際のデジタル署名です。
この署名は、ヘッダの指定された部分と本文のハッシュ値に基づいて生成され、メールの認証情報の完全性を保証します。
ARCの対応状況
ARCに対応しているMTAやMailing List Managerなどの一覧は、 "ARC Specification for Email"のResourcesに掲載されています。
まとめ
SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）、およびDMARC（Domain-based Message Authentication, Reporting and Conformance）は、メールの認証に広く用いられる手法ですが、メールが転送された際に認証が失敗することがあります。
ARCは、この問題に対処するために設計された技術で、SPF、DKIM、DMARCの認証メカニズムを補完します。
ARCはメールが転送される過程での認証情報を保存し、メールの認証状態を維持するための追加ヘッダーを提供します。
この追加された認証情報によって、メールが転送された後も、SPF、DKIM、DMARCの認証結果を正確に評価することができます。
Gmail/Google WorkspaceやMicrosoft365などの主要なメールサービスでは、デフォルトでARCが設定されており、ARCヘッダーが自動的にメールに付与されます。
一方で、自社でMTA（メール転送エージェント）やメーリングリストシステムを運用している場合は、ARCの設定を手動で行う必要があります。