Eメール配信におけるDMARCの重要性

February 02, 2023
執筆者
レビュー担当者

この記事はTwilio SendGridチームがこちらで公開した記事(英語)を日本語化したものです。

メールマーケティングには分かりにくい略語がたくさんあり、DMARCも例外ではありません。

DMARC(Domain-based Message Authentication, Reporting & Conformance)は、ハッカーの攻撃からお客様の(メール送信)ドメインを保護するためのセキュリティ対策です。このブログ記事でDMARCについて説明し、メール配信の制御とブランドの評判の保護に役立つ方法を紹介します。

日本語編集上の補足: 2023年になってから、日本経済新聞の記事「フィッシング検知機能、カード250社に導入要請 経産省」や「なりすましメール対策、日本は世界最低水準 米社調べ」を偶然目の当たりにすることがあり、あらためて皆さまの注意喚起を促したいと思い、Twilioの日本チームとして翻訳版をお読みいただきたいと思った次第です。

Eメール配信 〜 DMARCとは?

DMARCは一言で言えば、メール配信におけるドメイン認証の標準的なプロトコルで、サイバー攻撃と戦うために使用されます。

DMARCの役割は、サイバー攻撃者が正当な組織であるかのようになりすましてメールを送信することを管理者が捕捉するのを支援することです。このために、Sender Policy Framework(SPF; 英語ブログ)やDomain Keys Identified Mail(DKIM; 英語ブログ)といった他の標準認証プロトコルが使用されます。このようななりすまし行為はスプーフィングと呼ばれ、攻撃メールの「送信元」アドレスが正当なドメインと同じであるかのように見えることで起こります。

このように、DMARCはメールの配信側とその受信者の安全を守るために不可欠なものです。

DMARCの動作原理

DMARCは、SPFまたはDKIMを使用して認証されたEメールの処理方法を、Eメールの送信者が指定できるようにするものです。DMARCで指定された処理方法に応じて、これらのメールを迷惑フォルダに送るか、完全にブロックするかを選択できます。

これにより、インターネットサービスプロバイダ(ISP)は、より効果的にスパマーを特定し、消費者の受信トレイに悪意のあるメールが届くのを防ぐことができます。また、DMARCによってISPは誤検出を最小限に抑え、より良い認証レポートを提供することができ、かつ市場の透明性を大幅に向上させることができます。

DMARCのレコードは、ドメインネームシステム(DNS)のレコードと一緒に表示されます。

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

すべての受信サーバーがEメールを受信する前にDMARCチェックを行うわけではありませんが、主要なISPはすべてDMARCに対応しており、DMARCチェックの実装は増え続けていることにも注意が必要です。DMARCの詳細については、こちら(英語ブログ)をご確認ください。

DMARCの利点

DNSサーバー管理者がDMARCレコードを追加し、ドメインの監視を開始することを望む主な理由は4つあります。

  1. 送信元のレピュテーションを保護 〜 未認証の第三者がお客様のドメインからメールを送信するのを防ぐことで、DMARCはお客様のブランドを保護します。場合によっては、DMARCレコードを公開するだけで、ポジティブなレピュテーションの向上につながります。
  2. メール配信プログラムの可視性を向上 〜 DMARCレポートにより、お客様のドメインから誰がメールを送信したかを知ることができ、メール配信プログラムの可視性を向上できます。
  3. 将来のメール配信の安全性を確保 〜 DMARCにより、認証に失敗したメッセージに対してメールコミュニティが対処するための一貫したポリシーを確立するのに役立ちます。これにより、Eメールのエコシステムがより安全で信頼性の高いものになり、スパムメールの拒否リストに載らないようにすることができます。
  4. BIMIでロゴを表示 〜 DMARCでは、ブランドロゴを含むBrand Indicators for Message Identification(BIMI)仕様のメッセージを送信することができます。これにより、お客様のブランド認知度を高め、対応するメールクライアントを持つお客様に視覚的にアピールできます。

DMARCレコード

ターミナル上でコマンド「dig txt _dmarc.sendgrid.net」と入力すると、DMARCレコードがどのようなものかを確認することができます。その後、DMARCレコードが公開されているドメインについては、Valimailで確認することができます。

以下はTwilio SendGridのDMARCレコードの例です。

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

上記のレコード出力は、このブログの英語オリジナル版が発行された2020年頃の状況を現しているものと考えられます。ブログの日本語翻訳を行った2023年2月初旬段階では以下のようになっており、多少変化しています。この変化は、このブログ記事の後半に記載のあるDMARC実装のステップ「Escalate your DMARC policy tags as you learn more」をTwilio SendGrid自身が実践した結果であると考えています。

v=DMARC1; p=reject; sp=reject; pct=100; adkim=r; aspf=r; rua=mailto:dmarc_agg@vali.email,mailto:dmarc_rua@sendgrid.com; ruf=mailto:dmarc@sendgrid.com; fo=1; rf=afrf; ri=86400

DMARCの仕組みを分解

DMARCがどのように機能するかについて、上記のレコード出力を少し分解しながら見てみましょう。

"v=DMARC1"

このタグは、Eメールを送信したドメインのDNSレコードをスキャンする際に、受信サーバーが参考とするDMARCのバージョン識別子を示します。ドメインに "v=DMARC1 "で始まるレコードタグがない場合、受信サーバーはDMARCチェックを行いません。

"p=none"

ユーザーが選択したDMARCポリシーで、参加する受信メールサーバーに、SPFとDKIMの標準を満たしていないにもかかわらず、あなたのドメインからだと主張するメールをどう処理するかを指示します。3種類のポリシーがあります。

  1. p=none 〜 ドメイン認証されていると思えないメールに関して、その違反レポートを指定された宛先に送信するよう受信側に指示します。(指定された宛先=DMARCレコードの “ruf” などのタグ(後述)に記載のアドレス。)メール配信上の特段のアクションは行いません。
  2. p=quarantine 〜 不適格なメールを隔離するよう受信側に指示します。(通常、スパムフォルダに隔離されます。)
  3. p=reject 〜 ドメイン認証されていると思えないメールをすべて拒否するように受信機に指示します。逆に言えば、送信ドメイン認証状、正しく署名されたと確認されたメールだけが受信トレイに到達できます。他のすべてのメールは、誤検出を軽減するために拒否されます。

"rua=mailto:dmarc@sendgrid.com"

DMARCの失敗ケースの集計レポートメールを送信する宛先(「mailto:」で始まります)を受信側に指示します。これら集計レポートは、DMARC失敗に関するハイレベルな粒度の情報を含んでおり、DMARCレコードのオーナーであるドメイン管理者に毎日送信されます。

"ruf=mailto:dmarc@sendgrid.com"

DMARCの失敗に関するフォレンジックレポートの宛先を受信側に指示します。このフォレンジックレポートは、各失敗に関する詳細情報を含み、DMARCレコードのオーナーであるドメイン管理者にリアルタイムで送信されます。「rua」とは異なり、「mailto:」で始まる宛先アドレスは、DMARCレコードを公開したドメイからのものである必要があります。

"rf=afrf"

DMARCポリシー管理者の希望するレポートの書式を受信側に伝えるタグです。「afrf」 は「失敗の集計情報をレポートする書式」を意味します。

"pct=100"

受信したメールがどれだけDMARCポリシーの仕様に適合しなければならないかを、1~100のパーセント値で指示します。仮りに「pct=100」かつ「p=reject」であれば、DMARCチェックに失敗したメールはすべて(=100%)拒否されることを意味し、逆に「pct=1」に設定すると、不適合と判断されたメールの1%が拒否される、という意味になります。

実際には、DMARCレコードには他にも注目すべき仕組みがたくさんあり、以下でその幾つかを紹介します。

"sp="

受信側がサブドメインにDMARCポリシーを適用するかどうかを決定します。

"adkim="

DMARC認証のDKIM部分の処理モードを、「s」(strictを表す)または「r」(relaxedを表す)のいずれかに設定します。「s」の場合、署名の「d=」フィールドが「from」ドメインと正確に一致する場合にのみ、「DKIM認証=OK」となります。「r」の場合、「d=」フィールドが「from」アドレスのルートドメインと一致する場合にのみ、そのメールは「DKIM認証=OK」となります。

"ri="

DMARCの失敗に関する集計レポートを受け取る際の頻度(間隔)を設定します。

Twilio SendGridでDMARCを実装するには?

過去にフィッシングの問題があった場合、または機密情報を処理する金融業を営んでいる場合(あるいは機密情報を扱う任意のビジネスの場合)、DMARC認証を有効にすることは貴重な対策となります。実際、サイバー攻撃によるメール認証にまつわる将来の問題を先取りする方策として、今すぐDMARCポリシーを導入することにデメリットはないでしょう。

また、DMARCの集計レポートやフォレンジックレポートはプログラミグやツールによる処理を前提としているため、人間が即座に意味を理解するのは難しいことも念頭に置いておく必要があります。そのため、Twilio SendGridのパートナー企業であるValimailのようなDMARCレポート監視サービスを利用してレポートを収集し、その含意を読み解く必要があります。

DMARCを実装するかどうかを決定し、有効にしたいサービスを選択したら、DMARCを設定するための以下の5つのステップを実行してください。

1. SendGridのIPに送信者認証付きDKIM&SPFを導入する

ご利用のTwilio SendGridアカウントについて送信ドメイン認証プロセスを完了させます。SendGridアカウントで送信されるメールが、ご利用の独自ドメインに対して、DKIMとSPFで適切に署名されるようになります。

このステップを実行するにあたっては、ドキュメント(英語)をお読みください。

2. DKIMとSPF署名がSendGridアカウント上で許可されているドメインに対して適切であることを確認する

テストメールを数通送信し、すべてが正しく動作していることを確認します。具体的には、メールヘッダのDKIMとSPF署名が、SendGridアカウントの許可リストに含まれるるドメインと一致していることを確認します。

dmarc1

3. DNSレジストラに対してDMARCレコードを発行し、結果を監視する

メールの受信サーバーがDMARC設定を決定するために使用する(DNSの)TXTリソースレコードを、DNSレジストラに対して作成します。このタスクは、ドメインホストのDNSレジストラで実行します。通常、送信ドメイン認証用のレコードを作成したのと同じ場所(サブドメインではなく、ドメインのルートレベル)になります。

dmarc2JP

4. 受信したフィードバックを分析し、必要に応じてメール配信を調整する

DMARCに参加している受信サーバーに受信された不適合メールは、(DMARC設定に従い)以下のように処理されることに留意してください。

  • 不適合メールに関するレポートが作成される
  • DMARCレコードで指定された「mailto:」アドレスにメールが返送される

これらレポートには、どのサービスがあなたのドメインの代わりに(=だと偽り)メールを送信しているかを評価するのに役立つ情報が含まれています。

以下は、2通のメールに対するDMARC評価結果を示すレポート例です。(レコード数は1つのみです。)

<report_metadata>
<org_name>receiver.com
noreply-dmarc-support@receiver.com
<extra_contact_info>http://receiver.com/dmarc/support
<report_id>9391651994964116463
<date_range>
1335571200
1335657599
<policy_published> sender.com
r
r
none
none
100
<source_ip>72.150.241.94
2 <policy_evaluated> none
fail
pass
<header_from>sender.com
<auth_results>
sender.com
fail
<human_result>
sender.net
pass
<human_result>
sender.com
pass

記載されているSPFとDKIMのauth_resultsは、「s=」のアライメントに関係なく、生の結果です。ファイル名は、「ファイル名 = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension」 と表示されます。

(例: receiver.org!sender.com!1335571200!1335657599.zip)

また、集計レポートは.zip形式の添付ファイルとして送信されるため、「rua」タグで設定したアドレスがこのファイル形式の添付ファイルを受け入れられることを確認してください。

5. 動作状況に応じてDMARCポリシーのタグを調整していく

さて、あなたのドメインの代わりにメールを送信するのが誰かを決定するために、メールストリームをテスト・調整したのですが、それをさらに強化するタイミングです。

最初は「p=none」ポリシーを使って、メールの送信元を知り、悪い行動の報告を受けるだけだったはずです。段階的にDMARCレコードのポリシーを調整し、あなたのドメインからのメールであると主張するメールを受信サーバーがどのように処理するかを制御し始める時です!

Twilio SendGridでDMARCを実装し、なりすましに対抗しよう!

DMARCレコードは、洗練されたメール認証の進化に欠かせないものです。さらにこれらは、メール送信者とISPが協力してメール配信のセキュリティを最大化することの重要性を示す優れたケーススタディとなるはずです。

DMARCのウェブサイトをご覧になり、この貴重な認証プロトコルの詳細をご確認ください。そして、Twilio SendGridを使用してメールを認証する方法(英語ブログ)をお読みください。簡単なステップが、たった5つだけです!

DMARCに関する実装手順の日本語ドキュメントページもご用意いたしましたので、ぜひご活用ください!