大まかに言えば、Domain-based Message Authentication, Reporting and Conformance（DMARC）標準の導入は、組織のDNSレコードにテキストファイルを追加するだけで、送信メールに対して簡単に実行できます。しかし実際には、現代の組織の複雑さがプロセスを大幅に難しくすることがあり、正当なメール送信者が突然SPAMと判定されないよう、反復的なアプローチが必要になります。
基本的な手順は次のとおりです。
- DNSプロバイダーでDMARCレコードを公開する
- DMARCレポートを監視し、DMARCに失敗する正当な送信者を把握する
- 正当な送信元が認証に合格するよう、必要に応じてSPF、DKIM、DMARCを変更する
- DMARCの制限を強化する
- 正当な送信元でありながら失敗するものと、組織になりすまそうとする悪意ある送信元を把握するため、DMARCレポートを監視する
もちろん、これらの基本手順を実行するには追加の詳細が必要になることが多いため、この記事では以下の項目を詳しく解説します。
DMARCについて復習が必要な方は、まずDMARCとは？定義、メリット、デメリットなどをお読みください。
DMARCレコードの設定方法
DMARCレコードの作成は簡単です。ただし、DMARCはほかのメール認証標準に依存する標準でもあります。DMARCレコードを設定するには、まず依存する標準を確立し、その後にDMARCレコードを公開する必要があります。
依存するメール認証標準
DMARCは、Sender Policy Framework（SPF）とDomainKeys Identified Mail（DKIM）認証標準が正常に確立されていることに依存します。SPFとDKIMを先に設定せず、DNSレコードにDMARCポリシーを定義することも可能ですが、それでは何も機能しません。DMARCポリシーは、SPFおよびDKIMレコードをメールサーバーがどのように処理すべきかを定義します。
SPF、DKIM、DMARCの設定をテストし、定義したポリシーが意図どおりに機能し、正当なメールをブロックしないことを確認することが重要です。詳細は後述の「DMARCのテストと導入」で説明しますが、このテストを行うため、最初は緩和（relaxed）と隔離（quarantine）のオプションから始めることが推奨されます。
DMARCを公開する
DMARCを設定するには、組織がDMARCレコードと呼ばれるテキストファイルを、組織のDNSレジストラーで公開します。DMARCレコードは無料で公開でき、企業は必要な頻度でテキストファイルを変更できます。DMARCレコードは1行の単純なエントリーであり、多くの組織では次の手順で公開できます。
- ドメインレジストラーにログインする
- DNS設定を管理または構成するオプションをクリックする
- 「Add a New Record」オプションをクリックし、「TXT」レコードを選択する
- DMARCレコードのテキストをレコード欄にコピー＆ペーストする
多くのホスティング構成では、ドメイン名がファイル名に自動的に追加されます。追加されない場合は、レコードに手動で次の名前を付ける必要があります。
- 構文：_dmarc.<ドメインまたはサブドメイン>
- サブドメインの例：_dmarc.mailservers.ExampleDomain.com
- ドメインの例：_dmarc.NonProfitHealthcareExample.org
DNSプロバイダーによって要件や手順が異なる場合があるため、組織は利用するプロバイダーでの選択肢を慎重に確認する必要があります。DMARCポリシーはサブドメインごとに個別に設定できますが、DMARCポリシーを持たないサブドメインは親ドメインのDMARCポリシーを継承します。
もちろん、DMARCレコードは簡単に公開でき、単なるテキストファイルにすぎませんが、ミスを犯しやすい点を過小評価する人もいるでしょう。問題を避けるには、DMARCレコードタグの詳細を理解する必要があります。
DMARCレコードタグの詳細
DMARCレコードを理解するため、まずレコードの例を示し、各タグの詳細なオプションを見ていきます。
v=DMARC1;p=none;rua=mailto:dmarc@dxampledomain.com;ruf=mailto:dmarc@exampledomain.com;rf=afrf;pct=100これらのフィールドのうち、必須であり、先頭にこの順序で記載しなければならないのは最初の2つ、「v」と「p」だけです。ほかの変数は任意ですが、その多くは推奨されており、「v」に続いて「p」が来る限り、順序は問いません。
タグは余分なスペースを入れず、セミコロン（ ; ）で区切ります。ruaタグを使用してDMARCレポートをメール送信する場合は、各メールアドレスの前にmailto:プレフィックスを付ける必要があります。大文字と小文字が区別されるのは「v」タグだけですが、「v」タグ以外のすべてのタグには小文字のみを使用するのがベストプラクティスです。
v=DMARC1。
「v」タグはバージョン識別子を表し、常に「DMARC1」と記述されます。受信サーバーは、メッセージを送信したドメインのDNSレコードを確認する際に、この値を探します。ドメインに「v=DMARC1」で始まるテキストレコードが含まれていなければ、受信サーバーはDMARCチェックを実行しません。「v」タグは大文字と小文字が区別される唯一のオプションであり、DMARC1はすべて大文字で記述する必要があります。
p=none。
「p」タグはポリシーを表し、SPFまたはDKIMのテストに合格していないにもかかわらず自分のドメインから送信されたと主張するメールを、参加する受信メールサーバーがどう処理するかを指定します。この例では、ポリシーは「none」です。
ポリシーには次の3つのオプションがあります。
- p=none：最も寛容な設定です。「none」は、受信メールサーバーに対し、認証に合格しなかったメールに対して何も実行しないよう指示します
- p=quarantine：やや厳格なコマンドで、受信メールサーバーに対し、通常は迷惑メールフォルダーに送るなどして、認証に合格しなかったメールを隔離するよう指示します
- p=reject：最も厳格な設定です。「reject」は、受信メールサーバーに対し、そのドメイン宛ての認証に合格しなかったすべてのメールを拒否するよう指示します。ドメインによって署名されたことが確認されたメールだけが受信者の受信トレイに届くことができ、それ以外のメールはすべて破棄され、誤検知の影響を抑えます。
なお、DMARCの指示は受信メールサーバーによって無視または変更される場合があります。例えばMicrosoft Office 365では、rejectとquarantineを同じように扱い、DMARCに失敗したメールを迷惑メールフォルダーに配信します。
rua=mailto:dmarc@exampledomain.com
DMARCポリシーの極めて重要な要素は、ドメイン管理者がメールの認証失敗や、攻撃者による特定ドメインのなりすましを把握できるよう、レポート機能も提供することです。
「rua=mailto:」とタグに続くメールアドレスによって、DMARC失敗の集計レポートの送信先メールアドレスを指定します。これらのレポートには、詳細を含まないDMARC失敗の概要情報が記載されます。
ruf=mailto:dmarc@exampledomain.com。
ほかのメールタグと同様、「ruf=mailto:」はDMARC失敗に関する詳細なフォレンジックレポートに使用するメールアドレスを指定します。フォレンジックレポートには各失敗に関する広範な詳細が含まれ、メール受信サーバーは発生時にこれらのファイルをリアルタイムで送信します。
この例では「rua」と「ruf」の両方で同じメールアドレスを使用していますが、組織は送信先を別々に選択できます。ただし、組織は「rua」タグの場合とは異なり、「ruf」の「mailto:」メールアドレスは、そのDMARCレコードを公開したドメインのものでなければならないことに注意する必要があります。
rf=afrf。
「rf」、つまりレポート形式は、デフォルトで「afrf」、すなわち「aggregate failure reporting format」です。
pct=100。
「pct」、つまりパーセンテージ変数は、受信メールサーバーに対し、DMARCポリシーの仕様に従う必要がある受信メールの割合を、1～100のパーセント値で指定します。この例の「pct=100」では、DMARCチェックに失敗したメールを100%拒否することになります。一方、5%に設定した場合は、失敗したメールのうち5%だけが拒否されます。
sp。
サブドメインポリシーを表すspタグは、組織のサブドメインにDMARCポリシーを適用するかどうかを、メール受信サーバーに指定します。
aspf=r。
「aspf」、つまりSPFアライメントタグは、MailFROMドメインとヘッダー内の「From」（SPFに対してもチェックされる）が完全一致する必要があるか、親子関係に基づく一致を許可するかを定義します。タグの値に「r」を使用すると緩和（親子関係に基づく一致を許可）を意味し、「s」は厳格な一致、つまり完全一致を意味します。
例：
| Fromドメイン | SPFドメイン | 緩和チェック | 厳格チェック |
|---|---|---|---|
| Example.org | Example.org | 合格 | 合格 |
| Example.org | Mail.Example.org | 合格 | 不合格 |
| Mail.Example.org | Mail.Example.org | 合格 | 合格 |
| Mail.Example.org | Example.org | 合格 | 不合格 |
| Example.Mail.org | Example.org | 不合格 | 不合格 |
adkim。
「adkim」、つまりDKIMアライメントタグは、厳格を表す「s」または緩和を表す「r」に設定できます。厳格設定では、署名の「d=」フィールドが「from」ドメインと完全に一致する場合にのみDKIMを合格とします。緩和設定では、「d=」フィールドが「from」アドレスのルートドメインと一致するあらゆる場合にDKIMを合格とします。
fo。
「fo」、つまり失敗レポートオプションのデフォルトは「0」です。ただし、組織は次のいずれかのオプションを手動で選択できます。
- 0 = SPFとDKIMの両方のアライメントに失敗した場合、DMARC失敗レポートまたはフォレンジックレポートを送信する
- 1 = SPFまたはDKIMのいずれかのアライメントに失敗した場合、DMARC失敗レポートまたはフォレンジックレポートを送信する
- d = DKIMのアライメントにかかわらず、DKIM検証に失敗した場合にDKIM失敗レポートを送信する
- s = SPFのアライメントにかかわらず、SPF検証に失敗した場合にSPF失敗レポートを送信する
ri。
「ri」タグのデフォルト値は「86400」で、連続する2つの集計レポート間の時間間隔を定義します。
DMARCのテストと導入
DMARCレコードを公開すると、対象ドメインでDMARCが確立されます。しかし、DMARCを設定するだけでは、DMARC導入の始まりにすぎません。組織はレコードの正確性をテストし、予期しない結果を監視し、問題を修正したうえで、DMARC設定を強化して不正なメールのブロックを開始する必要があります。
注：DNSの伝播には時間がかかることがあるため、今回のテストの一部はDNS更新から数日後に行う必要があります。
SPF、DKIM、DMARCのテスト
SPFのテスト、DKIMのテスト、DMARCのテストをGoogleで検索すると、書式の問題や変数の誤用をチェックできるオンラインツールの一覧が表示されます。簡単なエラーを見つけるため、まずこれらのテストを実行する必要があります。
ただし、これらのテストでは、ドメイン、メールアドレス、IPアドレスの入力ミスを検出できません。そのため、組織はこの種の問題を確認するため、テストメールを送信する必要があります。トラブルシューティングや一般的なエラーについて詳しくは、DMARCが失敗する理由：DMARC導入における3つの重大な問題。
DMARCの監視
DMARCを初めて設定する際、組織は「p=none」に設定し、予期しない結果がないかレポートを確認する必要があります。例えば、SPFまたはDKIMの設定で見落としていたサードパーティーのメール配信サービスや、予期しないメールサーバーがメールを送信していることが判明する場合があります。さらに、組織はマーケティングプロバイダー、サポートシステム、受信トレイサービス、ドリップメールサービスの大半を事前に特定できることが多い一方で、見落とされがちなメール送信元には、サーバーや管理ツールからのアラートもあります。
一般的な組織では、DMARCの結果を監視し、追加のメールサーバーをSPFとDKIMに登録するまでに、数週間から数か月かかります。
既知のメール送信元をDMARC、DKIM、SPFにアライメントさせる
新しいメール送信元が特定されると、ITチームはDMARCのアライメントを確実にするため、それらの送信元をDKIMとSPFのファイルに追加する必要があります。各送信元の特定は難しい場合があります。これを容易にする方法の1つは、組織内でメール送信元として把握している各送信元の一覧を作成することです。
レポートに新しい送信元が現れたら、組織はそれらをメールプロバイダー、ECシステム、マーケティングサービスなどの既知の送信元と照合できます。一般的な例としては、Google Apps（Gmail）、Salesforce、Intercom、Campaign Monitor、Mailchimp、Microsoft 365などがあります。
重要なデータを整理して強調表示するサードパーティー製ツールを使わなければ、レポートの理解は難しい場合があります。例えば、一部のレポートアナライザーは、メールサーバーの送信元IPアドレスを解決し、そのIPアドレスの所在地や所有者を示すなど、役立つ情報を追加します。この情報は、メール送信元が正当なものかどうかを判断するうえで極めて重要です。
Zendesk、Campaign Monitor、Google Apps、Rackspaceなどのサービスは、DNSに追加すべきSPFレコードまたはDKIMレコードについての記事を公開しています。場合によっては、社内サーバー要件の管理が難しいため、DKIMとSPFの設定も管理できるサービスへメールを移行する組織もあります。
失敗として報告された送信元ドメイン/IPの中には、説明のつかないものもあります。多くの場合、これはSPFおよびDKIMヘッダーを保持できなかったユーザーによって転送された正当なメッセージです。一定期間に送信されたメールが10通未満の小規模な送信元は、通常は無視できます。
DMARCポリシータグを強化する
監視によって把握したすべてのメール送信元をSPFとDKIMに追加したら、組織はポリシータグを「quarantine」または「reject」に強化する必要があります。この最終調整を行うまでは、組織のブランドになりすまそうとするスプーファーやスパマーを阻止できません。
まとめ：効果的なDMARCを設定してメリットを享受する
効果的なDMARCポリシーを導入すると、メールマーケティングキャンペーンの配信率を5～10%向上させ、ドメインの評価を改善し、組織のブランドになりすまそうとするスパムメールやなりすましメールを大幅に減らすことができます。こうした大きなメリットを享受できるのは、組織がDMARCレコードを適切に設定した場合に限られますが、そこにかかる時間と労力は十分に見合うものです。
この記事は、もともとSean Michael Kernerによって2018年1月24日に執筆・公開され、Chad Kimeによって2023年6月1日に更新されました。