DMARCとは？

この記事は What is DMARC? の抄訳です。

DMARC(Domain-based Message Authentication, Reporting & Conformance) とは、メールの認証を行うSPF (Sender Policy Framework) とDKIM (DomainKeys identified mail) を利用して、メールの信頼性を判断するプロトコルです。

DMARCを使うことで、ISPは悪意のあるメール（個人情報を盗もうとする”なりすましメール”など）を見破りやすくなります。

DMARCでは、SPFまたはDKIMで認証されなかったメールを迷惑メールフォルダに振り分けるか、まとめてブロックするかを送信元のドメイン所有者自身がコントロールできます。 こうすることで、スパマーの識別がより正確になり、悪意あるメールの侵入を防ぐだけでなく、誤検知を最小限に抑え、認証状況の透明性をより高めることができます。
DMARCレコードは、次のようなDNSレコードと一緒に登録します。

• SPFレコード
• Aレコード
• CNAMEレコード
• (DKIM)

DMARCに対応していない受信サーバもありますが、主要なISPは対応しており、実装する動きが広まってきています。

DMARCのメリット

1. そのドメインを利用したなりすましメールを防げるのでブランドの信頼性を守ることができます。さらに、DMARCレコードを追加しているということ自体がレピューテーションに良い影響を与える場合もあります。
2. あなたのドメインを使ってメールを送信している人についての「レポート」を受け取ることができるので、メールプログラムの可視性が向上します。
3. メールコミュニティが、認証に失敗したメッセージの取り扱いに関するポリシーを作成するのに役立ちます。メールエコシステムをより安全で信頼できるものとするための助けとなります。

DMARCレコードはどのように書かれているのか？

DMARCレコードがどのように書かれているのかは、ターミナルで次のように打ち込むと確認できます。

dig txt _dmarc.sendgrid.net

また、https://www.valimail.com/ にアクセスすると、公開されているドメインのDMARCレコードを見ることができます。SendGridのDMARCレコードはこのように登録されています。

v=DMARC1;p=none;rua=mailto:dmarc@sendgrid.com;ruf=mailto:dmarc@sendgrid.com;rf=afrf;pct=100

DMARCレコードの読み方

SendGridのDMARCレコードを例に、その内容を読み解いてみましょう。

”v=DMARC1”

Version：受信サーバは、メッセージのヘッダFromのDNSレコードからこのタグを探します。“v=DMARC1”から始まるTXTレコードがないと、受信サーバはDMARCを確認しません。

“p=none”

Policy：DMARCの認証に失敗したメッセージを受信サーバがどう扱うべきかを指示しています。”none”が指定されている場合には、DMARCの認証に失敗したメッセージに対して受信サーバは何もしません。設定できるポリシーには次の3種類があります。

1. p = none – 認証に失敗したメールに対して、何もしないよう受信サーバに指示しますが、違反があった場合はDMARCレコードのmailto:にレポートを送信します。
2. p = quarantine – 認証に失敗したメールを隔離するよう受信サーバに指示します。それにより、大抵は直接迷惑メールフォルダに振り分けられますが、受信トレイに戻すことも可能です。 メールの送信元をある程度把握できているが、100％確証が得られるまでフェイルソフトしたい場合に便利です。
3. p = reject – 認証に失敗したメールは無条件に拒否するよう受信サーバに指示します。100%認証に成功したメールのみが受信トレイに到達し、それ以外はその場で削除されます。

“rua=mailto:dmarc@sendgrid.com“

DMARCの「集計レポート」の送信先を指定しています。この例では、 ”dmarc@sendgrid.com”宛に送信するよう指定されています。
このレポートでは、DMARCの認証に失敗したおおまかな情報はわかりますが、それぞれの失敗についての詳細情報までは提供されません。レポートの送信先は自由に指定できます。

“ruf=mailto:dmarc@sendgrid.com”

DMARCの「認証失敗レポート」の送信先を指定しています。このレポートは、指定したメールアドレス（この例では”dmarc@sendgrid.com”）に即座に送信されます。
認証失敗レポートではそれぞれの失敗に関する詳細な情報が提供されます。指定できるメールアドレスはDMARCレコードに登録されているドメインのアドレスのみです。

“rf=afrf”

認証失敗レポートの種類を指定しています。”rf”はreporting formatを表しており、”afrf”を指定した場合はAuthentication Failure Reporting Using the Abuse Reporting Formatになります。

“pct=100”

DMARCポリシーを適用するメールの割合を指定しています。 ここには1から100までの任意の値を指定できます。”pct=100”で”p=reject”を指定した場合、DMARCの認証に失敗した全てのメールは受信を拒否されます。

DMARCレコードで指定できるタグは他にもありますので、いくつかご紹介します。

“sp=”

DMARCポリシーをサブドメインに適用するかどうかを指定できます。

“adkim=”

DKIMアライメントを指定できます。DKIMアライメントでは、DKIMの認証で利用したドメイン（”d=”で定義されているドメイン）とヘッダFromのドメインの関係性を”s”（strict）または”r”（relaxed）で定義し、その関係性が正しいかどうかを検証します。”s”を指定した場合は、2つのドメインが完全に一致している場合のみDMARCの認証が通過します。”r”を指定した場合は、2つのドメインがサブドメインの関係であれば認証が通過します。

“ri=”

DMARCの集計レポートを、どれくらいの頻度で受け取るかを指定できます。

Twilio SendGridでDMARCに対応するには

DMARCは誰にでも必須というわけではありません。 小さなドメインの場合は非対応でも問題ないでしょう。 しかし、過去にフィッシング詐欺の問題があった場合や、機密情報を扱う金融系のビジネスの場合は、対応するのが賢明だといえます。

もう1つ重要なのは、集計レポートと認証失敗レポートは、機械で読めるよう設計されている点です。 人間が解読するのは難しいため、レポート監視サービスを利用して情報にアクセスする必要があります。Twilio SendGridはValiMailと提携しています。

DMARC対応を決断し、監視サービスを選択したら、次は以下の5つの手順を実施しましょう。

1. 独自ドメイン利用設定（Sender Authentication）でDKIMとSPFを有効化する

SendGridアカウントで独自ドメイン利用設定（Sender Authentication）を行いましょう。これにより、Twilio SendGridを介して送信されたメールが、独自ドメインのDKIMとSPFで適切に署名されます。
設定方法がわからない場合は、こちらを参照してください。

2. ドメインのDKIMとSPFが適切に設定されていることを確認する

テストメールを送信して、設定が正しく機能していることを確認しましょう。 メールヘッダのDKIMとSPF署名が、Sender Authenticationで設定したドメインと一致していて、両方の認証結果がPassしていればOKです！

3. DNSレジストラでDMARCレコードを公開し、結果を監視する

ご自身のドメインホストのDNSレジストラ（お名前.com など）で、DMARCの設定を記述したTXTレコードを追加します（※追加手順は独自ドメイン利用の設定でDNSレコードを追加したときと同様です）。その際、サブドメインではなく親ドメインに追加してください。このレコードは、受信メールサーバが送信元のDMARCの設定を確認するために参照されます。

4. 受け取ったフィードバックを分析し、必要に応じてメールの流れを調整する

DMARCに対応した受信サーバが認証に失敗したメールを受け取ると、レポートを生成してDMARCレコードで指定されたmailtoアドレスに送ります。

レポートには、自分のドメインを名乗っている可能性が高いサービスを特定するのに役立つ情報が含まれています。

以下は、2つのメールの結果を示すサンプルレポートです。(リストされているSPFとDKIMのauth_resultsは、生の結果であることに注意してください。ファイル名は「受信側ドメイン”!”DMARCを設定したドメイン”!”データ範囲の開始時刻”!”データ範囲の終了時刻”.” 拡張子」の形式です。
(例: receiver.org!sender.com!1335571200!1335657599.zip))

<report_metadata>
  <org_name>receiver.com</org_name>
  <email>noreply-dmarc-support@receiver.com</email>
  <extra_contact_info>http://receiver.com/dmarc/support</extra_contact_info>
  <report_id>9391651994964116463</report_id>
  <date_range>
    <begin>1335571200</begin>
    <end>1335657599</end>
  </data_range>
</report_metadata>  
<policy_published>
  <domain>sender.com</domain>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <p>none</p>
  <np>none</np>
  <pct>100</pct>
</policy_published>
<record>
  <row>
    <source_ip>72.150.241.94</source_ip>
    <count>2</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <spf>fail</spf>
      <dkim>pass</dkim>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>sender.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>sender.com</domain>
      <result>fail</result>
    </spf>
    <dkim>
      <domain>sender.net</domain>
      <result>pass</result>
      <human_result></human_result>
    </dkim>
    <dkim>
      <domain>sender.com</domain>
      <result>pass</result>
      <human_result></human_result>
    </dkim>
  </auth_results>
</record>

5. 分析し、DMARCポリシーを段階的に引き上げる

自分のドメインになりすましている送信者を特定する情報が収集できたので、次はポリシーを引き上げてみましょう。

これまでp=noneでレポートを受け取ってきて、メールがどこから来るかは大体把握できたと思います。次は、DMARCレコードのポリシーを変更して、なりすましメールを受け取ったときの制御を開始します。各ポリシーの違いは上記「DMARCレコードの読み方」を参照してください。

DMARCが非常に重要な理由

DMARCは、メール認証におけるすばらしい進化であり、送信者とISPが協力してメールチャネルを保護する優れた例です。 DMARCの詳細はwww.dmarc.orgを、認証の詳細についてはこちらをご覧ください。

参考

• DMARC.org’s FAQ
• 「Yahoo.comのDMARCポリシーが変更されました」
• 「First Yahoo and Now AOL. What Do You Need to Change to Be DMARC Compliant?」
• DMARCについて（Google）
• AppleドメインのDMARCレコードの変更が送信者に与える影響
• DMARC関連技術の紹介