ARC
ARC(Authenticated Received Chain)は、メッセージの元のSPF、DKIM、DMARCの結果を記録し、メーリングリストや転送サービスなどの中継サーバーを経由する間もその結果を引き継ぐメール認証プロトコルです。中継サーバーがメッセージを変更する前にどのように認証されていたかを、最終的な受信サーバーが信頼できる形で確認できるため、正当な転送メールが拒否されるのを防ぎます。
定義
Authenticated Received Chainは、2019年7月に公開されたRFC 8617で定義されたメール認証の標準規格です。その目的は、メッセージが送信者から受信者へ直接届くのではなく、中継サーバーを経由する場合にSPFとDKIMがうまく機能しないという長年の弱点を解決することです。
受信者に直接メールを送る場合、SPFとDKIMのチェックは通常成功し、DMARCも合格します。問題が起きるのは、メッセージが途中で第三者を経由するときです。メーリングリスト、メールを自動転送するアカウント、セキュリティゲートウェイなどは、メッセージを変更することがよくあります。件名を書き換えたり、フッターを追加したり、別のIPアドレスから中継したりします。こうした変更によって元のDKIM署名が壊れ、SPFの結果も無効になるため、メッセージが完全に正当なものであってもDMARCが失敗することがあります。
ARCは、Googleをはじめとする大手メール事業者のエンジニアを含む業界団体によって、受信側がこの状況を認識できるようにする目的で設計されました。受信側は、最終ホップで見える壊れた認証結果だけで判断するのではなく、ARCチェーンを読み取り、中継サーバーが手を加える前にメッセージが正しく認証されていたことを確認できます。
仕組み
ARCでは、対応する各中継サーバーが、メッセージを次に転送する前にARCセットと呼ばれる暗号署名付きの記録を追加します。各ARCセットは3つのヘッダーフィールドで構成され、チェーンを順番に読めるようにインスタンス番号が付与されます。
1つ目のフィールドはARC-Authentication-Resultsです。中継サーバーがメッセージを受信した時点で確認したSPF、DKIM、DMARCの結果をスナップショットとして記録します。いわば、そのホップにおける認証結果を固定したコピーです。
2つ目のフィールドはARC-Message-Signatureです。DKIM署名とよく似た働きをします。チェーンのその時点におけるメッセージのヘッダーと本文に対する暗号署名で、記録された認証結果を実際の内容と結び付けます。
3つ目のフィールドはARC-Sealです。現在のセットだけでなく、それまでのARCヘッダーのチェーン全体を対象とする署名です。シールにはcvと表記されるチェーン検証タグが含まれ、それまでのチェーンの状態を示します。値がnoneなら最初のホップ、passならそれ以前のARCセットがすべて正しく検証されたこと、failならチェーン内の何かを検証できなかったことを意味します。
メッセージが複数のARC対応サーバーを経由するにつれて、インスタンス番号はホップごとに増えていきます。メッセージを検証する受信サーバーは、ARCセットを順番に読み取り、欠落がないこと、各シールがそれ以前のエントリを有効と報告していることを確認し、最新のメッセージ署名を検証します。チェーンが整合していれば、受信側は最初のホップで記録された認証結果を信頼できます。
メール
転送やメーリングリストはあらゆる場所で使われており、ARCがなければ正当なメールが知らないうちに拒否されてしまうため、ARCは重要です。業務メールを個人アカウントに転送する社員、すべてのメッセージにフッターを追加するディスカッションリスト、受信メールをスキャンするサードパーティのセキュリティアプライアンスは、いずれもメッセージの真正性とは無関係な形でDKIMやSPFを壊してしまいます。
ドメイン所有者がp=rejectのような厳格なDMARCポリシーを公開している場合、こうした認証の失敗によって、通常は転送されたメールが破棄されます。受信者は届くはずのメッセージを目にすることがなく、外からは原因不明の配信失敗のように見えます。ARCは、最終的な受信側がより適切に判断できるだけの文脈を提供します。信頼できる中継サーバーが変更する前にメッセージが正しく認証されていたことをARCチェーンが示していれば、受信側は正当な転送に厳格なポリシーを適用せず、配信することを選べます。
ARCができることとできないことを正確に理解しておくことが大切です。ARCはDMARCを上書きするものではなく、配信を保証するものでもありません。あくまでもシグナルです。受信側は、特定のARCチェーンをどの程度信頼するかを自ら判断し、その信頼は署名した中継サーバーの評価に左右されます。ARCは、よくある厄介な誤拒否の原因を取り除き、正当なメールが受信トレイに届く可能性を高めるだけです。
VeriMailsでの
VeriMailsはメール検証サービスであり、到達率のうち、ARCとは異なる補完的な部分に注力しています。ARCは中継サーバーを経由して転送中のメッセージを守るのに対し、VeriMailsは送信ボタンを押す前の段階で、リスト上のアドレスが実在しメールを受信できることを確認します。
VeriMailsは、確認するすべてのアドレスに対して、構文の検証、MXレコードの照会、DNSチェック、受信側メールサーバーとのライブSMTPハンドシェイク、キャッチオール検出、使い捨てアドレス検出、ロールベースアドレス検出を実行します。これらを組み合わせることで、アドレスがキャンペーンに入る前に到達可能かどうかがわかり、キャンペーンの判断に使える明確な到達性カテゴリーが得られます。
この2つのアプローチは互いを補強します。ARCと、SPF、DKIM、DMARCからなる認証の仕組みは、メールが正当であることを証明して送信元の評価を守ります。VeriMailsは、無効なアドレスやリスクのあるアドレスをリストから除外することで、逆の方向から同じ評価を守り、バウンスや迷惑メール報告を減らします。アドレスはVeriMails REST APIで1件ずつ検証することも、CSVファイルをアップロードして一括で検証することもできます。新規アカウントには有効期限のない100クレジット無料が付与され、クレジットカードは不要です。