電子メール認証のベストプラクティス：SPF、DKIM、および DMARC を展開する最適な方法

はじめに

このガイドでは、現在使用されている3つの主要なEメール認証テクノロジー(SPF、DKIM、DMARC)について説明し、その実装のさまざまな側面について説明します。実際のEメールアーキテクチャの状況をいくつか取り上げ、それらをCisco Eメールセキュリティ製品セットに実装するためのガイドラインを示します。これは実践的なベストプラクティスガイドであるため、より複雑な資料の一部は省略します。必要に応じて、提示された内容を理解しやすくするために、特定の概念を単純化または要約できます。

製品知識の要件

このガイドは高度なレベルのドキュメントです。提示された資料を最後まで読み進めるには、Cisco Eメールセキュリティアプライアンスについて、Cisco Eメールセキュリティフィールドエンジニア認定レベルの製品知識が必要です。さらに、読者はDNSとSMTP、およびその操作に関する強力なコマンドを持っている必要があります。SPF、DKIM、DMARCの基礎を知っていることがプラスです。

電子メール認証 – 概要

送信者ポリシーフレームワーク(SPF)

Sender Policy Frameworkは、2006年にRFC4408として初めて発行されました。現在のバージョンはRFC7208で指定され、RFC7372で更新されています。基本的に、ドメイン所有者がDNSを使用して受信者に正当な電子メールソースを簡単にアドバタイズする方法を提供します。SPFは主にリターンパス(MAIL FROM)アドレスを認証しますが、仕様では、SMTP HELO/EHLO引数（SMTPカンバセーション中に送信される送信側のゲートウェイのFQDN）も認証することを推奨（およびメカニズムを提供）しています。

SPFは、非常に単純な構文のTXTタイプのDNSリソースレコードを使用します。

spirit.com テキスト= "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ～all"

上記のSpirit Airlinesレコードでは、@spirit.comアドレスからの電子メールを特定の/24サブネット、FQDNで識別される2台のマシン、およびMicrosoftのOffice365環境から受信できます。末尾の「～all」修飾子により、受信側は他の送信元をソフト障害（SPFの2つの障害モードのいずれか）と見なすように指示されます。送信者は、受信側が失敗メッセージに対してどのような処理を行うべきかを指定せず、失敗の度合いを指定することに注意してください。

一方、デルタは異なるSPF方式を採用しています。

delta.com text = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"

必要なDNSクエリーの数を最小限に抑えるために、Deltaは、すべてのSMTPゲートウェイをリストする単一の「A」レコードを作成しました。また、「_spf.vendor.delta.com」でベンダー用に個別のSPFレコードを提供します。また、SPF（「すべて」修飾子）で認証されなかったメッセージをすべてハードフェイル(HFAIL)する手順も含まれています。ベンダーのSPFレコードをさらに調べることができます。

_spf.vendor.delta.com text = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all"

したがって、送信者@delta.comからの電子メールは、Air Franceの電子メールゲートウェイなどから正規に送信される場合があります。

一方、Unitedは、よりシンプルなSPF方式を使用しています。

united.com text = "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ～all"

同社は、自社のメールゲートウェイの他に、電子メールマーケティングプロバイダー(「usa.net」および「enviaremails.com.br」)、従来のContinental Air Linesゲートウェイ、および同社のMXレコードに記載されているすべてのものを含んでいます（「MX」メカニズム）。MX(ドメインの着信メールゲートウェイ)は発信とは異なる場合があることに注意してください。小規模な企業では通常は同じですが、大規模な組織では、受信メールを処理するインフラストラクチャと、送信メールを処理するインフラストラクチャが別々になっています。

また、上記の例はすべて、追加のDNS参照（「含む」メカニズム）を幅広く使用しています。ただし、パフォーマンス上の理由により、SPF仕様では最終レコードを取得するために必要なDNSルックアップの総数が10に制限されています。DNS再帰のレベルが10を超えるSPFルックアップは失敗します。

Domain Keys Identified Mail（DKIM；ドメインキー識別メール）

RFC 5585、6376、および5863で規定されているDKIMは、YahooのDomainKeysとシスコのIdentified Internet Mail(DIM)という2つの古い提案を統合したものです。送信者が簡単に送信メッセージに暗号署名し、その署名を（他の検証メタデータとともに）電子メールヘッダーに含める方法を提供します（「DKIM署名」）。送信者はDNSで公開キーを公開するため、受信者はキーを簡単に取得して署名を確認できます。DKIMでは、物理メッセージの送信元は認証されませんが、送信元が送信者組織の秘密キーを所有している場合、送信元が代わりに電子メールを送信することは暗黙的に許可されるという事実に依存しています。

DKIMを実装するには、送信元の組織が1つ以上の公開キーペアを生成し、公開キーをTXTレコードとしてDNSに公開します。各キーペアは「セレクタ」によって参照されるため、DKIM検証器はキーを区別できます。発信メッセージは署名され、DKIM-Signatureヘッダーが挿入されます。

DKIMシグニチャ： v=1; a=rsa-sha1; c=relassed/relassed; s=united; d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:To:Reply-To:Subject:List-Unsubscribe:Message-ID; i=MileagePlus@news.united.com; bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=;

b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYqT01rEwL0V8MEY1MztrxZzzZ ijkLPGqt/sK1WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=

シグニチャの形式は非常に簡単です。「a」タグは署名に使用するアルゴリズムを指定し、「c」は[1]を使用する正規化スキームを指定し、「s」はセレクタまたはキー参照で、「d」は署名ドメインです。このDKIM署名ヘッダーの残りの部分はメッセージ固有です。「h」は署名付きヘッダーをリストし、「i」は署名付きユーザのIDをリストし、最後にヘッダーは2つの別々のハッシュで終わります。「bh」は署名付きヘッダーのハッシュで、「b」はメッセージ本文のハッシュ値です。

DKIM署名付きメッセージを受信すると、受信者は次のDNSクエリを作成して公開キーを検索します。

<selector>._domainkey.<署名ドメイン>

DKIMシグニチャヘッダーで指定したとおりに動作します。上記の例では、クエリは「united._domainkey.news.united.com」です。

united._domainkey.news.united.com text = "g=*\; k=rsa\; n=" "お問い合わせ" "postmaster@responsys.com" "ご質問" "関連" "この" "署名" "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35hO4v6dTy5Qmxcuv5Awqx9d0j0jBaxtuvYALjkgggO xmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB2IBwIDAQAB\"

返されるDNSレコードには、キーと、その他のオプションパラメータが含まれます。[2]

DKIMの主な問題は、送信者がDKIMを使用する広告を初期仕様で許可していなかったことです。したがって、メッセージに署名がない場合、受信者がメッセージに署名が必要であることを簡単に知る方法はありません。その場合、メッセージはおそらく本物ではありません。1つの組織が複数のセレクタを使用できる（また使用する場合も多い）ため、ドメインがDKIM対応かどうかを「推測」するのは簡単なことではありません。これをカバーするために別の標準である作成者ドメイン署名プラクティスが開発されましたが、使用率が低いことや他の問題が原因で、後継ルータなしで2013年に廃止されました。

ドメインベースのメッセージ認証、レポート、および準拠(DMARC)

DMARCは、対象となる3つの電子メール認証テクノロジーの中で最も新しく、SPFとDKIMの両方の欠点に対処するために特別に開発されました。他の2つとは異なり、メッセージのヘッダーFromを認証し、他の2つによって以前実行されたチェックにリンクします。DMARCはRFC7489で指定されています。

SPFおよびDKIMでのDMARCの付加価値は、次の要素で構成されます。

• すべての使用可能なID（HELO、MAIL FROMおよび/またはDKIM署名ドメイン）がFromヘッダーと一致していること（正確に一致するか下位であること）を確認します。
• 送信側のドメイン所有者が、受信側のポリシーを指定して、障害が発生したメッセージを処理する方法を指定できるようにする
• 送信者のドメイン所有者が失敗メッセージを通知されるフィードバック機能を提供することで、フィッシングキャンペーンやSPF/DKIM/DMARCポリシー割り当てのエラーを簡単に特定できます。

DMARCは、シンプルなDNSベースのポリシー配信メカニズムも使用します。

_dmarc.aa.com text = "v=DMARC1\; p=none\; fo=1\; ri=3600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"

 DMARCポリシー仕様で必須のタグは「p」だけで、失敗したメッセージに対して使用するポリシーを指定します。これは、none、quarantine、rejectの3つのうちのいずれかになります。

最も頻繁に使用されるオプションパラメータは、レポートに関連しています。「rua」は、特定のドメインから発信されたと主張するすべての失敗メッセージに関する日次の集計レポートを送信するためのURL(mailto：またはPOSTメソッドを使用するhttp:// URL)を指定します。「ruf」は、障害が発生したすべてのメッセージに関する詳細な障害報告を即時に送信するURLを指定します。

仕様に従って、受信側はアドバタイズされたポリシーに準拠する必要があります。通知しない場合は、送信元のドメイン所有者に集約レポートで通知する必要があります。

DMARCの中心となる概念は、いわゆるIDアラインメントです。IDの位置合わせは、メッセージがDMARC検証を渡す方法を定義します。SPFとDKIMのIDは別々に調整され、メッセージはDMARC全体を渡すにはこれらのいずれかを渡す必要があります。ただし、DMARCポリシーオプションでは、1つのアラインメントに成功しても他方のアラインメントに失敗しても、送信側は失敗レポートの生成を要求できます。上記の例では、「fo」タグが「1」に設定されていることがわかります。

メッセージがDKIMまたはSPF識別子のアラインメントに従う方法には、strictとrelaxedの2つがあります。厳密な準拠とは、Header FromのFQDNが、DKIM署名の署名ドメインID（「d」タグ）またはSPFのMAIL FROM SMTPコマンドのFQDNと完全に一致する必要があることを意味します。一方、Relaxedでは、Header From FQDNを前述の2つのドメインのサブドメインにすることができます。  これは、電子メールトラフィックをサードパーティに委任する際に重要な意味を持ちます。これについては、このドキュメントで後ほど説明します。

SPFの導入に関する考慮事項

レシーバ用SPF

Cisco Eメールセキュリティアプライアンス(ESA)またはクラウドEメールセキュリティ仮想アプライアンスでは、SPF検証を簡単に設定できます。このドキュメントの以降の部分では、ESAに関する記述にはすべてCESが含まれます。

SPF検証はメールフローポリシーで設定されます。SPF検証をグローバルに実行する最も簡単な方法は、適切なリスナーのDefault Policy ParametersセクションでSPF検証をオンにすることです。着信メールと発信メールの収集に同じリスナーを使用している場合は、「RELAYED」メールフローポリシーのSPF検証が「Off」に設定されていることを確認します。

SPFではポリシーアクションを指定できないため、SPF検証（および後述するDKIM）ではメッセージの検証のみを行い、実行されたSPFチェックごとにヘッダーのセットを挿入します。

Received-SPF：パス(mx1.hc4-93.c3s2.smtpi.com：ドメイン/

  united.5765@envfrm.rsys2.comは12.130.136.195を

  permitted sender) identity=mailfrom;

  client-ip=12.130.136.195、receiver=mx1.hc4-93.c3s2.smtpi.com、

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="united.5765@envfrm.rsys2.com";

  x-conformance=sidf_compatible; x-record-type="v=spf1"（x準拠=sidf_compatible; xレコードタイプ="v=spf1"）

Received-SPF：なし(mx1.hc4-93.c3s2.smtpi.com：送信者なし)

  ドメインから入手できる真正性情報

  postmaster@omp.news.united.com) identity=helo;

  client-ip=12.130.136.195、receiver=mx1.hc4-93.c3s2.smtpi.com、

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="postmaster@omp.news.united.com";

  x-conformance=sidf_compatible（x準拠=sidf_互換）

このメッセージでは、2つの「ID」がSPFによって検証されています。仕様で規定されている「mailfrom」と、同じ仕様で推奨されている「helo」です。メッセージは正式にはSPFを通過します。これは、SPFコンプライアンスに関連するのはSPFだけであるためです。一部のレシーバは、HELO IDにSPFレコードを含めない送信者も同様に通過を許可する可能性があります。したがって、送信メールゲートウェイのホスト名をSPFレコードに含めることをお勧めします。

メールフローポリシーがメッセージを確認したら、実行するアクションを設定するのはローカル管理者です。これを行うには、メッセージフィルタルールSPF-status() [3]を使用するか、またはこれを使用して着信コンテンツフィルタを作成し、適切な着信メールポリシーに適用します。

図1:SPF検証コンテンツフィルタ条件

推奨されるフィルタ処理は、失敗したメッセージのドロップ（SPFレコードでは – all）、およびSoftfailしたメッセージの検疫（SPFレコードでは～all）です。ただし、これはセキュリティ要件によって異なる場合があります。一部のレシーバは、失敗したメッセージにタグを付けるだけか、または目に見えるアクションを実行しないが、管理者に報告します。

最近、SPFの人気が大幅に高まっていますが、多くのドメインが不完全または誤ったSPFレコードを公開しています。安全な側に立つには、すべてのSPF失敗メッセージを隔離し、しばらくの間隔離を監視して、「誤検出」がないことを確認します。

他のドメインまたはサードパーティに電子メールサービスを提供している場合

サードパーティの電子メール配信またはホスティングサービスを提供する場合、サードパーティは、メッセージを独自のSPFレコードに配信するために使用するホスト名とIPアドレスを追加する必要があります。これを行う最も簡単な方法は、プロバイダーが「包括」SPFレコードを作成し、お客様にSPFレコードに「含める」メカニズムを使用してもらうことです。

suncountry.com text = "v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.109.66.68 ip4:198.179.134.238 ip4:107.20.24 .57 ip4:207.87.182.66 ip4:199.66.248.0/22 include:cust-spf.exacttarget.com ～all"

ご覧のように、Sun Countryは一部の電子メールを独自の管理下に置いていますが、マーケティング電子メールはサードパーティにアウトソーシングされています。参照レコードを展開すると、マーケティングメーリングサービスプロバイダーが使用する現在のIPアドレスのリストが表示されます。

cust-spf.exacttarget.com text = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:13.111.0.0/18 -all"

この柔軟性により、電子メールサービスプロバイダーは、各顧客に連絡してDNSレコードを変更することなく、規模を拡張できます。

サードパーティの電子メールサービスを使用する場合

前の段落と同様に、サードパーティの電子メールサービスを使用していて、完全にSPF検証済みのメールフローを確立したい場合は、独自のSPFレコードを自分のSPFレコードに含める必要があります。

jetblue.com説明テキスト「v=spf1 include:_spf.qualtrics.com ?all」

JetBlueはQualtricsの分析サービスを使用しており、実行する必要があるのはQualtricsからの正しいSPFレコードを含むことだけです。同様に、他のほとんどのESPは、顧客のレコードに含めるSPFレコードを提供します。

ESPまたは電子メールの販売会社がSPFレコードを提供しない場合は、送信メールゲートウェイを自分に直接記載する必要があります。ただし、これらのレコードを正確に保持する責任はプロバイダーにあります。プロバイダーがゲートウェイを追加したり、IPアドレスやホスト名を変更したりすると、メールフローが損なわれる可能性があります。

SPFに意識のない第三者による更なる危険は、リソースの共有によるものです。 ESPが同じIPアドレスを使用して複数の顧客にメールを配信する場合、ある顧客が同じインターフェースを通して配信する別の顧客を装ってSPF有効なメッセージを生成することは、技術的に可能です。このため、SPFの制限を行う前に、MSPのセキュリティポリシーと電子メール認証の認識について調査する必要があります。SPFがインターネット上の信頼の基本的なメカニズムの1つであることを考えると、質問に対する答えがない場合は、MSPの選択を再考することを強くお勧めします。セキュリティについてだけではありません – SPF、DKIM、DMARC、およびMSPで採用されているその他の送信者のベストプラクティス[4]は、配信可能性の保証です。MSPがメッセージに従わない、または誤って従うと、大規模な受信システムでの信頼性が低下し、メッセージの遅延やブロックが発生する可能性があります。

（サブ）電子メールトラフィックのないドメイン

現在、ほとんどの組織はマーケティング目的で複数のドメインを所有していますが、企業のEメールトラフィックにアクティブに使用するのは1つだけです。SPFが実稼働ドメインに正しく展開されていても、悪意のある攻撃者は、電子メールに積極的に使用されていない他のドメインを使用して組織のIDをスプーフィングする可能性があります。SPFは、特別な「すべて拒否」SPFレコードを使用してこれを防ぐことができます。電子メールトラフィックを生成しないドメイン（およびサブドメイン！）の場合は、DNSで「v=spf1 -all」を発行します。優れた例は、openspf.org - SPFカウンシルのWebサイトです。

SPF委任は1つのドメインに対してのみ有効であるため、電子メールを生成しない可能性のある、使用している可能性のあるサブドメインの「すべて拒否」SPFレコードも発行することが重要です。実稼働ドメインに「通常の」SPFレコードがある場合でも、トラフィックのないサブドメインに「すべて拒否」レコードを追加するために特別な作業を行ってください。繰り返しますが、受信は送信と同じではないことを忘れないでください。ドメインは電子メールを受信することがありますが、送信元になることはありません。これは、短期間のマーケティング・ドメイン（イベント、期間限定のプロモーション、製品発表など）に対して非常に当てはまります。これらのドメインに送信されたメールは本番ドメインに配信され、これらのメールに対する応答はすべて本番ドメインから配信されます。これらの短期間のドメインには有効なMXレコードがありますが、電子メールの送信元ではないことも識別するSPFレコードが必要です。

DKIMの導入に関する考慮事項

レシーバ用DKIM

ESAでのDKIM検証の設定は、SPF検証と似ています。メールフローポリシーのデフォルトのポリシーパラメータで、単にDKIM検証を「オン」にします。繰り返しますが、DKIMではポリシーを指定できないため、シグニチャを検証し、「Authentication-Results」ヘッダーを挿入するだけです。

認証結果：mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature verified) header.i=MileagePlus@news.united.com

DKIM検証結果に基づくアクションは、コンテンツフィルタによって実行される必要があります。

図2:DKIM検証コンテンツフィルタの条件

単純なSPFとは異なり、DKIMは実際のメッセージテキストを操作するため、一部のパラメータは制限されることがあります。オプションで、DKIM検証プロファイルを作成し、異なる検証プロファイルを異なるメールフローポリシーに割り当てることができます。受け付ける署名のキーサイズを制限したり、キー取得の失敗アクションを設定したり、DKIM検証のレベルを設定したりできます。

メッセージは複数のゲートウェイを通過するため、複数回署名でき、複数の署名を伝送できます。DKIM検証に合格するメッセージについては、すべての署名で検証する必要があります。デフォルトでは、ESAは最大5つのシグニチャを検証します。

SMTPと電子メールの歴史的なオープン性と、インターネット全体の（積極的な）変化への対応が困難であるため、メーリングリストのマネージャがメッセージをリレーして変更する場合や、メッセージが新しいメッセージの添付ファイルとしてではなく直接転送される場合など、DKIMシグニチャが正当に失敗する可能性のある状況がいくつかあります。そのため、一般的にDKIMに失敗したメッセージのベストプラクティスは、ドロップではなく検疫またはタグ付けにあります。

DKIMで署名する準備をしています

RELAYED Mail Flow PolicyでDKIM署名をオンにする前に、キーを生成/インポートし、DKIM署名プロファイルを作成し、公開キーをDNSで公開する必要があります。

単一のドメインに対して署名する場合、プロセスは簡単です。キーペアを生成し、メールポリシーのDomain Keysセクションで単一の署名プロファイルを作成し、プロファイルの準備ができたら、「DNS Text Record」の下の「Generate」オプションをクリックします。DNSで生成されたキーを公開します。最後に、メールフローポリシーでDKIM署名をオンにします。

複数の異なるドメインに署名する場合は、より複雑になります。この場合、次の2つのオプションがあります。

1. 単一の署名プロファイルを使用して、すべてのドメインに署名します。（単一の）公開キーを「プライマリ」ドメインのDNSゾーンに保存し、DKIMシグニチャがそのキーを参照します。この手法は、過去にESPで使用されていることがよくありました。個々の顧客のDNSスペースと対話することなく、大規模に署名することができました[5]。
2. 署名するドメインごとに個別の署名プロファイルを作成します。これにより、初期設定がより複雑になりますが、移行の柔軟性が大幅に向上します。ドメインごとにキーペアを作成し、「Profile Users」セクションで1つのドメイン（およびそのサブドメイン）のみを指定するプロファイルを作成し、その特定のドメインのDNSゾーンで関連する公開キーを発行します。

オプション#1を使用する方が簡単に開始できますが、最終的にはDMARCが機能しなくなることに注意してください。DMARCでは署名ドメインIDをヘッダーのFromに合わせる必要があるため、DKIMとの識別子の位置合わせは失敗します。SPFを正しく設定し、DMARC検証に合格するためにSPF識別子の調整を利用すると、この問題を回避できる可能性があります。

ただし、オプション#2を最初から実装することで、DMARCについて心配する必要がなくなり、単一のドメインの署名サービスを取り消したり再設定したりするのはかなり簡単です。 また、サードパーティのドメインに対して一部の電子メールサービスを提供する場合、使用するキーをそこから取得する（そしてESAにインポートする）必要が生じることがあります。このキーはドメイン固有であるため、別のプロファイルを作成する必要があります。

サードパーティの電子メールサービスを使用する場合

一般的に、DKIM署名を使用して、一部の電子メール処理（マーケティング電子メールなど）をサードパーティにオフロードする場合、実稼働で使用するキーと同じキーをサードパーティに使用させたくありません。これは、DKIMにセレクタが存在する主な理由の1つです。代わりに、新しいキーペアを生成し、DNSゾーンの公開部分を発行して、秘密鍵を相手に配信する必要があります。これにより、問題が発生した場合に特定のキーを迅速に取り消し、実稼働のDKIMインフラストラクチャを変更せずに維持できます。

DKIMでは不要ですが（同じドメインのメッセージに複数の異なるキーで署名できます）、サードパーティで処理される電子メールには、個別のサブドメインを提供することをお勧めします。これにより、メッセージの追跡が容易になり、後でDMARCをより明確に実装できるようになります。例として、Lufthansaからの複数のメッセージからの次の5つのDKIMシグニチャヘッダーについて考えます。

DKIMシグニチャ：v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa; d=newsletter.milesandmore.com;

DKIM署名： v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;

DKIM署名： v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;

DKIM署名： v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com

DKIM署名： v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa5; d=fly-lh.lufthansa.com;  

Lufthansaは5つの異なるキー（セレクタ）を使用して、2つのプライマリ実稼働ドメイン(lufthansa.comとmilesandmore.com)の5つの個別のサブドメインに分割しています。つまり、これらはそれぞれ独立して制御でき、それぞれ異なるメッセージングサービスプロバイダーにアウトソーシングできます。

DMARCの導入に関する考慮事項

レシーバ用DMARC

ESAでのDMARC検証はプロファイルベースですが、DKIMとは異なり、仕様に準拠するにはデフォルトプロファイルを編集する必要があります。ESAのデフォルトの動作では、お客様から明示的な指示がない限り、メッセージが廃棄されることはありません。そのため、デフォルトのDMARC検証プロファイルでは、すべてのアクションが「No Action」に設定されます。また、正しいレポート生成を有効にするには、「メールポリシー」のDMARCセクションの「グローバル設定」を編集する必要があります。

プロファイルが設定されると、他の2つの場合と同様に、DMARC検証がメールフローポリシーのデフォルトポリシー設定セクションで設定されます。集約フィードバックレポートを送信するボックスを必ずオンにしてください。これは、おそらく送信者にとってDMARCの最も重要な機能です。このドキュメントの作成時点では、ESAはメッセージごとの障害レポート（DMARCポリシーの「ruf」タグ）の生成をサポートしていません。

DMARCポリシーアクションは送信者によって通知されるため、SPFやDKIMとは異なり、プロファイル設定以外で設定できる特定のアクションはありません。コンテンツフィルタを作成する必要はありません。

DMARCによる検証では、Authentication-Resultsヘッダーに次のフィールドが追加されます。

認証結果：mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature verified) header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com

上記の例では、DMARCがDKIM識別子のアラインメントに基づいて検証され、送信者が「none」のポリシーを要求したことが示されています。これは、現在DMARC導入の「モニタ」フェーズにあることを示します。

他のドメインまたはサードパーティに電子メールサービスを提供している場合

DMARC準拠に関するESPの最大の懸念事項は、適切なIDのアラインメントを実現することです。DMARCを計画する際は、SPFが正しく設定されていること、関連する他のすべてのドメインの発信ゲートウェイがSPFレコードに含まれていること、および主にMAIL FROMとHeader FromのIDに異なるドメインを使用することによってアライメントに失敗するメッセージを送信しないことを確認します。このエラーは、電子メール通知または警告を送信するアプリケーションによって最も頻繁に発生します。これは、アプリケーションの作成者は、電子メールIDの不整合の結果をほとんど認識していないためです。

前述のように、各ドメインに対して個別のDKIM署名プロファイルを使用していること、および署名プロファイルが「ヘッダー：自」で使用されているように、署名対象のドメインを正しく参照していることを確認します。独自のサブドメインを使用している場合は、単一のキーで署名できますが、DMARCポリシー(「adkim="r」)でDKIMの準拠性をrelaxに設定していることを確認してください。

一般に、直接制御できない多数のサードパーティに電子メールサービスを提供している場合は、配信する可能性が最も高い電子メールの送信方法に関するガイドライン文書を作成することをお勧めします。ユーザ間の電子メールは一般的に正常に動作するため、これは上記の例のアプリケーション作成者のためのポリシー文書として機能します。

サードパーティの電子メールサービスを使用する場合

サードパーティを使用して電子メールトラフィックの一部を配信する場合、最適な方法は、別のサブドメイン（または完全に異なるドメイン）をサードパーティプロバイダーに委任することです。この方法で、必要に応じてSPFレコードを管理し、個別のDKIM署名インフラストラクチャを使用して、実稼働トラフィックを妨害しません。したがって、アウトソースEメールのDMARCポリシーは、社内とは異なる場合があります。前述のとおり、サードパーティが配信する電子メールを検討する際は、常にIDが一致し、DKIMおよびSPFの規定に準拠する内容がDMARCポリシーで適切に設定されていることを確認してください。

（サブ）電子メールトラフィックのないドメイン

以前のEメール認証テクノロジーに対するDMARCのもう1つの改善点は、サブドメインの処理方法です。デフォルトでは、特定のドメインのDMARCポリシーがすべてのサブドメインに適用されます。DMARCポリシーレコードを取得する際にHeader From FQDNレベルでレコードが見つからない場合、受信者は送信者の組織ドメイン[6]を決定し、そこでポリシーレコードを検索する必要があります。

ただし、組織ドメインのDMARCポリシーでは、明示的なDMARCポリシーがパブリッシュされていないサブドメインに適用される別のサブドメインポリシー（DMARCレコードの「sp」タグ）を指定することもできます。

前述のSPFの章で説明したシナリオでは、次のようになります。

1. 電子メールの正当なソースであるサブドメインに対して明示的なDMARCレコードを発行します。
2. 組織ドメインポリシーレコードで「拒否」のサブドメインポリシーを発行し、非送信ドメインをスプーフィングする電子メールを自動的に拒否します。

このようなEメール認証の構造により、インフラストラクチャとブランドを最大限に保護できます。

DMARC固有の問題

DMARCには、DMARCが依存する他の認証テクノロジーの特性と欠点に起因する、いくつかの潜在的な問題があります。問題は、DMARCが電子メールを拒否するポリシーを積極的にプッシュし、メッセージ内のすべての異なる送信者IDを関連付けることによってこれらの問題を表面化したことです。

ほとんどの問題は、メーリングリストとメーリングリスト管理ソフトウェアで発生します。メーリングリストにメールが送信されると、そのメールはすべての受信者に再配布されます。ただし、結果として生成される電子メールは、元の送信者の送信者アドレスが含まれており、メーリングリスト管理者のホスティングインフラストラクチャによって配信されるため、ヘッダー送信元(ほとんどのメーリングリスト管理者はリストのアドレスをエンベロープ送信元(MAIL FROM)として使用し、元の送信者のアドレスをヘッダー送信元として使用)のSPFチェックに失敗します。

DMARCはSPFで失敗するため、DKIMに依存する可能性がありますが、ほとんどのメーリングリスト管理者はメッセージにフッターを追加したり、件名にリスト名をタグ付けしたりしているため、DKIM署名検証を中断します。

DKIMの著者は、この問題に対していくつかの解決策を提案し、そのすべてがメーリングリスト管理者に要約され、すべてのFromアドレスのリストのアドレスを使用しなければならず、別の方法で元の送信者アドレスを示しています。

元のメッセージをSMTP経由で新しい受信者にコピーするだけで転送されるメッセージでも、同様の問題が発生します。ただし、現在使用されているほとんどのメールユーザエージェントは、新しいメッセージを正しく形成し、転送されたメッセージをインラインまたは新しいメッセージの添付ファイルとして含めます。この方法で転送されたメッセージは、転送ユーザがパスするとDMARCを通過します（もちろん、元のメッセージの信頼性は確立できません）。

電子メール認証を実装するためのサンプルアクションプラン

テクノロジー自体はシンプルですが、完全なEメール認証インフラストラクチャを実装するための道は長く、曲がりくねっていることがあります。小規模な組織や制御されたメールフローを持つ組織では、この方法は非常に簡単ですが、大規模な環境では非常に困難です。大規模な企業では、導入プロジェクトを管理するためにコンサルティング・ヘルプを採用することは珍しくありません。

ステップ1:DKIM

未署名のメッセージは拒否されないため、DKIMは比較的影響を与えません。実際に実装する前に、前述のすべてのポイントを考慮に入れます。署名を委任する可能性のある第三者に連絡し、第三者がDKIM署名をサポートしていることを確認し、セレクタ管理戦略を検討してください。組織によっては、異なる組織単位に対して個別のキー（セレクタ）を保持することがあります。セキュリティを強化するためにキーの定期的な交換を検討する場合もありますが、送信中のすべてのメッセージが配信されるまで、古いキーを削除しないようにしてください。

キーサイズには特に注意が必要です。一般に「多くの方が優れている」が、メッセージごとに2つのデジタル署名を作成すること（正規化など）はCPUに非常に負荷がかかる作業であり、送信メールゲートウェイのパフォーマンスに影響を与える可能性があることを考慮に入れる必要がある。計算のオーバーヘッドがあるため、実際に使用できる最大キーサイズは2048ビットですが、ほとんどの導入では、1024ビットキーによってパフォーマンスとセキュリティの間で適切な妥協点が見つかります。

DMARCの後続の実装を成功させるには、次の作業を行う必要があります。

1. サブドメインを含め、送信するすべてのドメインを特定する
2. dkimキーを生成し、各ドメインの署名プロファイルを作成する
3. 関連する秘密鍵を任意のサードパーティに配信する
4. 関連するDNSゾーンのすべての公開キーを公開する
5. サードパーティが署名を開始する準備ができていることを確認する
6. すべてのESAでRELAYED Mail Flow PolicyのDKIM署名を有効にします
7. サードパーティに署名の開始を通知する

ステップ2:SPF

Eメール認証インフラストラクチャの実装において、SPFの適切な実装は、おそらく最も時間と手間のかかる部分です。Eメールは非常に使いやすく管理も簡単で、セキュリティとアクセスの観点からは完全にオープンだったため、これまで組織では、誰がどのようにEメールを使用できるかについて厳格なポリシーを適用する必要がありませんでした。このため、今日のほとんどの組織では、社内および社外の電子メールのさまざまなソースをすべて把握できていません。SPFを実装する際の最大の問題は、あなたの代わりに誰が正当に電子メールを送信しているかを知ることです。

調べる項目は次のとおりです。

1. 明らかな標的：Exchangeまたはその他のグループウェアサーバ、送信メールゲートウェイ
2. 外部通知を生成する可能性があるDLPソリューションまたはその他の電子メール処理システム
3. 顧客と対話する情報を送信するCRMシステム
4. 電子メールを送信する可能性のあるさまざまなサードパーティアプリケーション
5. 電子メールを送信する可能性のあるラボ、テスト、またはその他のサーバ
6. 外部の電子メールを直接送信するように設定されたパーソナルコンピュータおよびデバイス

組織によって環境が異なるため、上記のリストは完全ではありませんが、何を探すかについて一般的なガイドラインとして考慮する必要があります。電子メールソースを（ほとんど）特定した後は、既存のすべてのソースを承認するのではなく、リストをクリーンアップします。理想的には、いくつかの正当な例外を除き、すべての送信メールが送信メールゲートウェイを通じて配信される必要があります。サードパーティのマーケティングメールソリューションを所有している場合、または使用している場合は、実稼働のEメールゲートウェイとは別のインフラストラクチャを使用する必要があります。メール配信ネットワークが非常に複雑な場合は、SPFで現在の状態の文書化を続行できますが、将来のクリーンアップには時間がかかります。

同じインフラストラクチャ上で複数のドメインにサービスを提供する場合は、単一のユニバーサルSPFレコードを作成し、「含む」メカニズムを使用して個々のドメインで参照できます。SPFレコードが広すぎないことを確認します。たとえば、/24ネットワーク内の5台のマシンだけがSMTPを送信する場合、ネットワーク全体ではなく、これらの5つの個別のIPアドレスをSPFに追加します。可能な限り具体的な記録を作成し、悪意のあるEメールが自身を侵害する可能性を最小限に抑えます。

一致しない送信者に対してはsoftfailオプションから開始します(「～all」)。電子メールの送信元をすべてすべて特定したことを100 %確かめた後は、これをhardfail (-all)に変更してください。そうしないと、実稼働の電子メールを失うリスクがあります。その後、DMARCを実装し、しばらくモニタモードで実行すると、見逃したシステムを特定し、SPFレコードを更新して完了できます。その場合のみ、SPFをハードフェイルに設定するのが安全です。

ステップ3:DMARC

DKIMとSPFを可能な限り完全に設定したら、次にDMARCポリシーを作成します。以前の章で説明したさまざまな状況をすべて考慮し、複雑なEメールインフラストラクチャがある場合は、複数のDMARCレコードを導入する準備を整えます。

レポートを受信する電子メールエイリアスを作成するか、レポートを取り込むWebアプリケーションを作成します。この目的で使用する電子メールアドレスは厳密に定義されていませんが、rua@domain.com、dmarc.rua@domain.com、mailauth-rua@domain.comなど、説明的なアドレスを使用すると役に立ちます。オペレータがこれらのアドレスを監視してSPF、DKIM、およびDMARCの設定を適切に変更するためのプロセスが配備されていることを確認します。あるいは、スプーフィングキャンペーンが発生した場合はセキュリティチームにアラートを送信します。最初は、SPFとDKIMの設定中に失ったものをカバーするためにレコードを調整するため、作業負荷が大きくなります。しばらくすると、レポートにはスプーフィングの試みだけが表示されるようになります。

最初に、DMARCポリシーを「none」に設定し、失敗したチェック(「fo=1」)のレポートを送信するフォレンジックオプションを設定します。これにより、トラフィックに影響を与えずに、SPFとDKIMのエラーをすばやく検出できます。送信したレポートの内容に問題がなければ、セキュリティポリシーと設定に応じて、ポリシーを「検疫」または「拒否」に変更します。受信したDMARCレポートの誤検出をオペレータが継続的に分析していることを再度確認してください。

DMARCを完全かつ正確に実装することは、小規模な作業でも短時間の作業でもありません。不完全なレコードのセットと「なし」のポリシーを公開することで、いくつかの結果（およびDMARCの正式な「実装」）が得られる場合がありますが、送信者組織とインターネット全体の両方にとって、全員がその能力を最大限に実装することは最善の利益です。

スケジュールについては、一般的なプロジェクトの個々の手順の概要を次に示します。繰り返しになりますが、組織ごとに異なるため、次の点は正確ではありません。

1. DKIMの企画及び準備	2 ～ 4週間
2. DKIMテストの実行	2 週間
3. SPF – 正当な送信者識別	2 ～ 4週間
4. DMARC方針作成	2 週間
5. SPFおよびDMARCレコードのテストの実行	4 ～ 8週間
6. ハードフェイルでのSPFテストの実行	2 週間
7. 検疫/拒否によるDMARCテストの実行	4 週間
8. DMARCレポートの監視とそれに応じたSPF/DKIMの適応	連続

小規模な組織では、ほとんどの手順、特にステップ3と4の所要時間が短くなる可能性があります。Eメールインフラストラクチャがどんなにシンプルであっても、テストの実行中は常に十分な時間を割いて、フィードバックレポートを詳細に監視し、見逃していたものがないか確認します。

大規模な組織では、同じ手順を繰り返す時間がさらに長くなり、より厳しいテスト要件が必要になる場合があります。複雑なEメールインフラストラクチャを持つ企業が、Eメール認証の実装に関する技術的な側面だけでなく、プロジェクト全体を管理し、チームや部門間で調整するために、外部の支援を必要とすることは珍しくありません。

その他の参考資料

• SPFの参照サイト：http://www.openspf.org
• DKIM協議会：http://www.dkim.org
• 信頼される側のドメインプロジェクトによって運営されているDMARCのメインWebサイト：http://www.dmarc.org
• dmarcian - DMARCの作成者の1人であるTim Draegenによって実行されるヘルプとリソースサイトです。必ず「ツール」セクションにアクセスしてください。http://www.dmarcian.com
• Online Trust AllianceのRecord Validatorツール：https://otalliance.org/resources/spf-dmarc-record-validator
• DMARC Record Assistant:DMARCレコードの作成に役立つもう1つのツールです。http://www.kitterman.com/dmarc/assistant.html
• SPF記録テストツール：http://www.kitterman.com/spf/validate.html
• 『Don't Be A Phish: Deep Dive Into Email Authentication Techniques』、Cisco Live 2014プレゼンテーションBRKSEC-3770:https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1]正規化は、このドキュメントの範囲外です。DKIMの正規化の詳細については、「参考資料」セクションの資料を参照してください。

[2] DKIM DNSレコードパラメータも、このドキュメントの対象外です。

[3]メッセージフィルタの作成は、このドキュメントの範囲外です。サポートについては、『AsyncOS for Email』ユーザガイドを参照してください。

[4] M3AAWGは、業界の大半で採用され、評価されている優れたベストプラクティスのセットを定義しました。『Sender Best Common Practices』ドキュメントは、https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdfから入手できます。

[5]この動作は、元々DKIMがMAIL FROMまたはHeader Fromに示されているメッセージソースを検証しないという事実を利用します。署名ドメインID（DKIM署名の「d」パラメータおよび署名プロファイルの「Domain Name」パラメータ）が、メッセージの署名に使用されるペアの公開キーを実際にホストしていることだけを確認します。送信者の信憑性は、「From」ヘッダーが署名されることによって示されます。「プロファイルユーザ」セクションで、署名したすべてのドメイン（およびサブドメイン）をリストしてください。

[6]通常、TLDまたは関連するccTLDプレフィクス（.ac.uk、.com.sgなど）の1レベル下のドメイン