ARC(Authenticated Received Chain)とは何ですか?
ARC電子メール(Authenticated Received Chain)とは、電子メール認証システムであり、電子メールを取り扱う各段階において、電子メールの認証評価を表示する。より簡単に言えば、Authenticated Received Chainは、電子メールメッセージの一連の検証または「保管の連鎖」と呼ぶことができ、メッセージを処理する各エンティティは、そのメッセージを以前に処理したすべてのエンティティを効果的に確認することができます。2019年7月にRFC 8617で「Experimental」として公開され文書化された比較的新しいプロトコルとして、Email ARCは、SPFとDKIMが中間サーバーによって無効にされた場合でも、受信サーバーが電子メールを検証することを可能にします。
主なポイント
- ARC (Authenticated Received Chain)は、複数のハンドリング・サーバーにまたがる電子メール認証結果の検証可能な「保管チェーン」を提供します。
- メーリングリストやフォワーダーのような仲介者によって引き起こされるDMARCの失敗を軽減し、正当なメールの正当性を維持します。
- ARCは、受信者が最初の認証結果を信頼できるようにすることでDMARCを補完し、DMARCを置き換えることなく配信性を向上させる。
- 実装には、検証情報を渡すためにARC-Authentication-Results、 ARC-Seal、およびARC-Message-Signatureヘッダーを追加することが含まれる。
- 仲介者による正しいARC署名は、通常であればSPF/DKIMを破壊するような変更にもかかわらず、最終的な受信者が電子メールの真正性を検証することを可能にする。
DMARC ARC
DMARC ARCは、メール転送の結果としてDMARC認証システムに存在する可能性のある脆弱性を回避する効果的な方法です。DMARCは、認証チェックを通過できるようにメール情報を保存します。不正なEメールが遮断されることは必要ですが、正当なEメールが配信に失敗することは最も避けたいことです。DMARC ARCは、メールヘッダが変更されることなく、次の中間処理に引き継がれることを保証するために、すべてのステップでメールの検証シーケンスを維持します。
PowerDMARCでARCを簡素化!
ARCはDMARCの代用品として使用できますか?
答えはノーです。ARCのメールは、中間サーバーを何台経由しても、認証識別子を順次受け渡すように設計されています。ARCは、DMARCの検証結果を保持し、第三者やメールボックスプロバイダーがメッセージのヘッダーやコンテンツを変更するのを防ぎます。ARCはDMARCの代替ではなく、DMARCポリシーに追加して使用することで、メールの配信性をさらに向上させることができます。
Authenticated Received Chainはどのように役立つのか?
DMARCは、SPFや DKIMといった電子メール認証標準に照らして電子メールを認証し、認証に失敗した電子メールや認証に合格した電子メールをどのように処理するかを受信側に指定するものです。しかし、厳格なDMARC ポリシーに基づきDMARCを実施した場合、メーリングリストやフォワーダー経由で送信されたメールなど、正当なメールであっても認証に失敗し、受信者に届かない可能性があります!Authenticated Received Chainは、この問題を効果的に軽減するのに役立ちます。次のセクションでその方法を学びましょう:
アークがお手伝いできる場面
- メーリング・リスト
メーリングリストのメンバーであれば、メーリングリストのアドレスを指定することで、メーリングリストのメンバー全員にメッセージを一斉送信することができます。その後、受信アドレスがあなたのメッセージをメーリングリストの全メンバーに転送します。現状では、DMARCはこの種のメッセージの検証に失敗し、正当な送信元から送信されたにもかかわらず認証に失敗する!これは、メッセージが転送されるとSPFが壊れてしまうからです。メーリングリストでは、メール本文に余分な情報が盛り込まれることが多いため、メール内容の変更によってDKIM署名が無効になることもあります。
- メッセージの転送
転送されたメッセージの場合のように、送信サーバーから直接メールを受け取るのではなく、中間サーバーからメールを受け取るなど、間接的なメールの流れがある場合、SPFが壊れ、メールは自動的にDMARC認証に失敗します。また、フォワーダーの中にはメールの内容を変更するものもあるため、DKIMの署名も無効になってしまいます。
このような状況では、Authenticated Received Chainが助けになります。どうやって?それを見てみましょう。
DMARC ARCはどのように機能するのか?
上記の状況では、フォワーダーは、DMARCセットアップに対して検証された電子メールを、認可されたソースから最初に受信していた。Authenticated Received Chainは、Authentication-Resultsヘッダーをメッセージ配送の次の「ホップ」に渡すことを可能にする仕様として開発された。
転送されたメッセージの場合、受信者のメールサーバーは、DMARC認証に失敗したメッセージを受信すると、最初のホップのEmail ARC Authentication-Resultsを抽出して、そのメールに対して提供されたAuthenticated Received Chainに対して、2度目のメール認証を試み、仲介サーバーから受信サーバーに転送する前に正当であると認証されたかどうかをチェックします。
受信者は、抽出された情報をもとに、ARCのメール結果をDMARCのポリシーに優先させるかどうかを決定し、それによってメールを本物かつ有効なものとして、受信者の受信箱に正常に配信することを許可するのです。
ARCの実装により、受信者は以下の情報を用いて効果的にメールを認証することができます。
- 中間サーバーが目撃した認証結果と、最初のホップでのSPFとDKIMの検証結果の全履歴を表示します。
- 送信されたデータを認証するために必要な情報です。
- 送信された署名を仲介サーバにリンクさせるための情報で、仲介者がコンテンツを変更しても、新しい有効なDKIM署名を転送していれば、受信サーバでメールが検証されるようになっています。
Authenticated Received Chainの実装
ARCは3つの新しいメールヘッダを定義しています。
- ARC-Authentication-Results(AAR)。メールヘッダの最初にあるAARは、SPF、DKIM、DMARCなどの認証結果をカプセル化したものです。
- ARC-Seal (AS) - ASはDKIM署名の簡易版で、認証ヘッダーの結果とARC署名の情報を含んでいます。
- ARC-Message-Signature(AMS) - AMSもDKIMの署名に似ていますが、ARC-Sealヘッダー以外のTo:フィールド、From:フィールド、件名、メッセージの本文全体を含むメッセージヘッダーのイメージを取得します。
変更内容に署名するために中間サーバーが行う手順。
ステップ1:サーバーはAuthentication-Resultsフィールドを新しいAARフィールドにコピーし、それをメッセージのプレフィックスとします。
ステップ2:サーバは、メッセージに対するAMSを(AARとともに)策定し、メッセージの前に追加します。
ステップ3:サーバは、前回のARC-SealヘッダのASを策定し、メッセージに追加します。
最後に、認証された受信チェーンを検証し、転送されたメッセージが正当かどうかを調べるために、受信者はチェーンまたはARCシールヘッダと最新のARC-Message-Signatureを検証する。DMARCのARCヘッダが何らかの形で変更されている場合、そのメールは結果的にDKIM認証に失敗する。しかし、メッセージの送信に関与したすべてのメールサーバーが正しく電子メールARCに署名し送信した場合、電子メールはDKIM認証結果を保持し、DMARC認証を通過し、結果として受信者の受信箱にメッセージが正常に配信されます!
ARCの導入は、組織におけるDMARCの導入をバックアップし、すべての正当なメールが一度も滞りなく認証されるようにサポートします。今すぐDMARCの無料トライアルにお申し込みください。
- DMARCレコードの作成と公開方法- 2025年3月3日
- 2025年に「SPFレコードが見つかりません」を修正する方法- 2025年1月21日
- DMARCレポートの見方- 2025年1月19日