MailData

ARC(Authenticated Received Chain)

ARC

メール転送に弱いSPF/DKIM/DMARC認証を補完

ARCアーク（Authenticated Received Chain）は、メールにおいて認証情報を確保するための規格であり、メールが複数のメールサーバを経由する際に、認証結果を伝播させることができます。
これにより、メールを転送するとSPFやDKIMが合格できない問題を回避できるようになります。
ARCは、DMARCやSPF、DKIMといった既存のメール認証技術と連携して動作します。

ARCの仕様は、2019年に公開されたRFC8617に記載されています。

ARCの必要性

メールのドメイン認証をSPF（Sender Policy Framework）やDKIM（DomainKeys Identified Mail）、DMARC(Domain-based Message Authentication, Reporting, and Conformance)で行う際、メールの転送によって認証が失敗する問題が存在します。

SPFにおける転送の問題点
SPFは、送信ドメインが使用しているMTA（メール送信サーバ）のIPアドレスリストを用いて、メールが正当なMTAから送信されたかを確認します。
しかし、メールが転送されると、受信者のMTAから再送信されるため、このIPアドレスがSPFのリストに含まれていないことが多いです。
結果として、転送されたメールはSPFのチェックを通過できないことがあります。
DKIMにおける転送の問題点
DKIMでは、メールのヘッダーと本文から生成されるハッシュ値に基づき、秘密鍵で署名することで、メールが指定ドメインから送信されたことを証明します。
しかし、メールが転送される際には、ヘッダーの情報が変更されたり、件名に「FW:」が追加されたり、本文に追記がある場合があります。
特にメーリングリストを介して転送されると、メーリングリストの情報が本文に追加されることがあります。
これらの変更により、DKIMの署名が無効になることがあります。
DMARCにおける転送の問題点
DMARCは、Return-PathやDKIMの鍵のドメインと、ヘッダーFromのドメインが一致しているかどうかを確認し、アドレスが詐称されていないかどうかを判断します。
転送するとSPFやDMARCの認証が失敗する事があり、もし何も変更せずに転送していても、Return-Pathが転送した人のアドレスやメーリングリストのアドレスになるので、ドメインと一致が崩れます。
これらの変更により、DMARCが転送先では合格できないことがあります。

転送メールの認証の仕組み

転送時に受信側のMTA（メール転送エージェント）が転送したMTAのDNSに直接問い合わせるわけではありません。
メールの転送と認証のプロセスは以下のように進行します。

1. メールの送信
メールが送信されると、送信元のMTAはSPFレコード（DNSに保存されている）とDKIM署名（メールヘッダに含まれる）を用いてメールを認証します。
この時点でのDNSの問い合わせは、送信元のMTAが送信ドメインのSPFレコードを確認するために行われます。
2. メールの転送
メールが転送されると、転送するMTAは通常、メールのReturn-Pathを変更し、場合によってはメールの内容（特にヘッダー）を変更することがあります。
3. メールの受信
転送されたメールが受信側のMTAに到達すると、受信側のMTAはそのメールのSPFとDKIMの認証を行います。
この時、受信側のMTAは、メールのReturn-Path（SPFのため）とDKIM署名（もし存在するなら）に基づいて、関連するDNSレコードを問い合わせます。
4. DMARCのチェック
DMARCポリシーの確認では、メールの「From」ドメインに対するDMARCレコードをDNSから取得し、SPFとDKIMの結果に基づいてメールがDMARCポリシーに合致するかどうかを評価します。

受信側のMTAは転送されたメールの認証を行う際、そのメールのReturn-PathやDKIM署名に関連するDNSレコード（主に送信ドメインのもの）を問い合わせます。
しかし、それらの値を転送したMTAのDNSに問い合わせるわけではありません。

ARCの仕組み

ARCの仕組み

ARC（Authenticated Received Chain）をプロセスに組み込むと、メールの転送と認証のプロセスは以下のように変化します：

1. メールの送信
メールが送信されると、送信元のMTAはSPFレコード（DNSに保存されている）とDKIM署名（メールヘッダに含まれる）を用いてメールを認証します。
この時点でのDNSの問い合わせは、送信元のMTAが送信ドメインのSPFレコードを確認するために行われます。
2. メールの転送とARCの適用
メールが転送される際、転送するMTAはメールのReturn-Pathを変更し、場合によってはメールの内容（特にヘッダー）を変更することがあります。
この時、ARCは転送MTAによって適用され、元のメールの認証結果（SPF、DKIMの結果）と共に、新たなARCヘッダー（ARC-Seal、ARC-Message-Signature、ARC-Authentication-Results）がメールに追加されます。
これにより、元の認証状態が保存され、後続のMTAがこれを参照できるようになります。
3. メールの受信とARCの評価
転送されたメールが受信側のMTAに到達すると、受信側のMTAはメールのSPFとDKIMの認証、そしてARCヘッダーの検証を行います。
ARCヘッダーを用いて、受信側のMTAは、メールが転送中に認証情報がどのように変化したかを把握し、メールの信頼性をより適切に判断できます。
4. DMARCのチェック
DMARCポリシーの確認では、メールの「From」ドメインに対するDMARCレコードをDNSから取得し、SPFとDKIMの結果に基づいてメールがDMARCポリシーに合致するかどうかを評価します。
ARCが適用されている場合、DMARCの評価は、ARCによって保存された元の認証情報を考慮に入れることができます。
これにより、転送されたメールがDMARCチェックに合格する可能性が高まります。

ARCは、メールが転送される間に認証情報が失われることなく維持されるように設計されており、特に転送されたメールがDMARCの評価において適切に扱われるようにします。

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は、メールのReturn-Path（送信元）アドレスです。
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の設定を手動で行う必要があります。