SOBOO：他者の名義でDMARC準拠のメールを送信する方法
DMARCに準拠した方法で他者のメールを送信するには、いくつかの方法があります。この記事は、メールサービスプロバイダー（ESP）および、自社の顧客のドメインを使用してメールを送信するあらゆる企業（例：CRM、人材管理会社、請求システムなど）を対象としています。
dmarcianは、DMARCコンプライアンスを満たすための設定方法を含むメール送信元のディレクトリを掲載した「DMARC運用リソースセンター」を運営しています。
このディレクトリは、多くの人々の時間を大幅に節約してくれます：
- ドメイン所有者は、自社のCRM、人材管理システム、または請求システムがDMARC準拠のメールを送信できるかどうか、また可能であればその方法を確認できます。インターネット上のアーカイブを何時間も探したり、サポートに電話をかけたり、不完全な情報をもとに解決策を模索したりする必要はありません。
- メール配信元のプロダクトマネージャーは、DMARCのサポートを要望された際に、ユーザーが具体的に何を求めているのかを正確に把握できます。これにより要件が明確になり、実装が迅速化され、最終的に顧客を満足させる機能を提供できるようになります。
この記事では、ドメインを代表してメールを送信するための認証取得方法、DMARC準拠のメールを送信するために必要な機能、顧客のオンボーディングプロセスにおける変更点、およびDMARC導入後の対応について解説します。
お客様のドメインを使用して送信する方法
DMARCに準拠したメールは簡単に識別でき、送信者のドメインとメール本文との間に紐付けを行う仕組みになっています。DMARCの仕組みについて解説した短い動画をご覧ください。
顧客のドメインと関連付ける方法はいくつかあり、それによって顧客に代わってDMARC準拠のメールを送信できるようになります。
注：DMARC を使用すると、サブドメイン（例： email.company.com)、かつ、 From: ヘッダー（例： From: offers@company.com).
まず、以下の最適な手法を挙げ、その後に効率の低い手法を記載します：
ドメインの委任
お客様が、管理を依頼するサブドメイン（例： email.company.com)、サブドメインへの認証を経たメールを送信できるようになり、ほとんどの場合、 From: ヘッダー（例： From: Best Offers <[email protected]>). サブドメイン全体を管理・運用するため、DMARC準拠のメール送信に関わるすべての処理は、現在、お客様に代わって管理されています。サブドメインの委任には、以下の2つの方法があります：
完全委任
顧客は、サブドメイン全体をあなたに管理を委任します。これにより、あなたはそのサブドメインおよびその下位にあるすべてのもの（そのサブドメインのサブドメインも含む）に対して責任を負うことになります。顧客が行うべきことはサブドメインの委任のみであるため、この方法が推奨されます。
CNAME
顧客は、自社のドメインを指す複数のCNAMEレコードを作成します。これは実質的に委任の一形態ですが、個々のサービスがそれぞれのCNAMEによって委任される点が異なります。これは完全な委任と同様ですが、顧客が最初に作成しなければならないDNSエントリが多くなるため、推奨される完全な委任アプローチに次ぐ選択肢となります。
CNAMEは通常、以下の目的で作成されます：
- SPFおよびバウンス処理たとえば、ある顧客が、
marketing.customer-domain.org～にbounces.email-service-provider.com. 顧客に代わって送信されたメールでは、バウンス先アドレスとして@marketing.customer-domain.org. 対応するSPFレコードは、あなた自身が管理しているだけでなく（実際には、これはbounces.email-service-provider.com)、ただし、バウンスが発生した場合は、顧客ではなくあなたに返送されます。(SPFの概要をまとめた短い動画をこちらに公開しました。) - DKIM。お客様は、ご自身が公開した公開鍵を指すCNAMEレコードを複数作成することができ、そのCNAMEレコードを使用して、お客様に代わって送信するメールにDKIM署名を追加することができます。複数のCNAMEレコードを設定しておくことで、お客様に何らかの操作を依頼することなく、DKIMキーをローテーションさせることが可能になります。（DKIMの概要を解説した短い動画はこちらで公開しています。）
- 顧客のドメインにリンクを紐付ける。自社ドメインを指すリンクを埋め込む代わりに、顧客のメール内に顧客のドメインを使用したリンクを追加することができます。メール内のリンクがクリックされると、CNAMEレコードが解決され、トラッキングなどの目的で自社サービスにリダイレクトされます。
中継
顧客に代わって送信するメールの量がごくわずかである場合、リレー送信が選択肢となることがあります。リレー先となるメールサーバー自体がDMARC準拠のメールを送信できる場合、顧客が自身のメール設定を変更して別のメールサーバー経由でリレー送信できるようにすることは、DMARC準拠を実現する一つの方法です。
これを許可するには、2つの方法があります：
SMTPリレー
顧客が、貴社に代わって送信するすべてのメールについて、SMTPリレーを設定できるようにします。（SMTPに関する概要動画はご用意していますが、リレーについては扱っていません。）リレーを管理する担当者は、DMARCへの準拠について責任を負うことになります。
欠点は以下の通りです：
- リレーがバウンスを処理のためにあなたに転送できない限り、バウンスの処理は行われません。
- メールの配信はリレー事業者の責任となります。つまり、メールサービスは、顧客が運営するシステムに依存することになります。
ユーザー認証情報の設定
顧客がユーザー認証情報を設定できるようにします。これには、顧客がサービス用のアカウントをプロビジョニングし、その後、新しいユーザーの認証情報を使用するようにサービスを設定する必要があります。その後、あたかもそのユーザーであるかのようにメールを送信することになります。
欠点は以下の通りです：
- 自社の顧客がGmail、Yahoo、Microsoft、Exchangeなどを利用している可能性があるため、多数のメールプラットフォームに対するユーザーレベルのアクセス権限を管理する必要があります。
- お客様のリソースを利用して、お客様に代わってメールを送信しています。
手動設定
委任されたサブドメインを運用する（またはCNAMEを使用する）代わりに、DMARC準拠のメールを送信できるよう、顧客にドメインの設定を依頼することができます：
SPF
顧客に対し、自社のネットブロックを顧客のSPFレコードに追加するよう依頼することができます。これはよくある依頼ですが、その理由が間違っていることがよくあります。これを行うと、顧客のドメインが送信メールのバウンス先アドレスに使用されている場合に限り、顧客に代わって正当なメールを送信できるようになります。
欠点：
- 配信に失敗したメッセージは、送信者であるあなたに戻されるのではなく、顧客に転送されます。その結果、メール送信者としてのパフォーマンスに影響を与える問題について、あなたは全く把握できなくなり、顧客は不快なユーザー体験を強いられることになります。
- 顧客は、SPFレコードを維持しながら、貴社についても考慮しなければなりません。これは、不当な理由でSPFレコードへの追加を要請してきた多数の送信者を管理しなければならない顧客にとって、煩わしいことです。
DKIM
お客様には、ご自身のドメインにDKIM関連の鍵を追加していただくことができます。
欠点：
- お客様は、長い文字列をドメイン管理ソフトにコピー＆ペーストしなければなりません。その際、頻繁にエラーが発生し、ユーザーもあなた自身もイライラさせられてしまいます。
- 顧客に何らかの作業を依頼せずにDKIMキーをローテーションすることはできません。これは、良くても面倒な作業です。最悪の場合、緊急事態（しかも休日中に！）でDKIMキーをローテーションしなければならないこともあり、その際は顧客とのやり取りが最悪の事態を招く恐れがあります。「お客様のキーが不正なメールの送信に使用されています。今すぐ他の作業をすべて中断して、この問題の解決にご協力いただけますか？」
もし、共有する価値のある新しい方法を見つけたら、ぜひお知らせください。
必須要件
前述の通り、顧客に代わってDMARC準拠のメールを送信するには、さまざまな方法があります。いずれの方法も、「自分にとっての利便性」と「顧客にとっての利便性」のバランスを取るというトレードオフになります。設定や運用にかかる作業量は決まっているため、以下の選択肢があります：
- この作業は、お客様の代わりに実施してください。
- 自分と顧客の間で作業を分担するか、あるいは
- お客様に作業を行ってもらう。
どのような方法を採用する場合でも、顧客に代わって送信できるようにするには、ある程度の作業が必要となります：
サブドメインの委任
お客様
サブドメインやCNAMEを実装するための、一度きりのドメイン設定。
あなた
- サブドメインの委任およびCNAMEの処理、検証、監視を行うドメインシステムの運用。
- バウンス先アドレスおよびDKIM署名に顧客のサブドメインを使用するメールサーバー機能。
- SPFレコードのメンテナンス。
中継
お客様
- お客様ご自身でリレーリソースをご用意いただく必要があります。
- システムにリレー情報を追加するための初期設定。
あなた
- メールサーバーには、顧客のリレー機能を利用できるようにする機能や、メール送信を本格的に行うのであれば、バウンス処理に対応する機能が必要です。ほぼすべてのメールサーバーがメールのリレー機能をサポートしているため、ここでの作業は、顧客がこの機能を活用できるようにすることです。
手動設定
お客様
- SPFレコードとDKIM署名鍵を追加するための、一度限りのドメイン設定。
- SPFレコードの更新やDKIM署名鍵の交換が必要な場合の追加設定。
あなた
- バウンス先アドレスおよびDKIM署名に顧客のドメインを使用するメールサーバー機能。
- SPFレコードの維持管理、およびインフラストラクチャを変更する際に、顧客がSPFレコードを更新するよう確実に促すこと。これは、顧客が
include:SPF を通じてインフラストラクチャを管理するか、あるいは顧客がいる場合は、次のようなものを追加するように依頼してくださいip4:SPFレコードに追加する。
鋭い読者の皆様ならお気づきでしょうが、どちらのアプローチを採用する場合でも、いくつかの変更を加える必要があります。いずれの場合も、メールサーバーの機能は必須となります。
リレーを使用しないアプローチ間には、多くの共通する「必須機能」がありますが、主な違いは、顧客があなたに代わってメールを送信できるようにドメインを設定する方法が異なる点にあります。この点を踏まえると、すでに顧客に代わってメールを送信することを決めているのであれば、顧客にとってその設定を簡単にするよう努めることは非常に有意義です。
顧客のオンボーディング
最初の方法（サブドメインの委任）は、顧客に代わってDMARC準拠のメールを送信できるようになるまでに、顧客が実装しなければならない作業量を最小限に抑えるという点で効率的です。
2つ目のアプローチ（リレー）は、本質的にDMARC準拠のメール送信業務を顧客に委ねるものです。顧客に代わって送信するメールの量がごくわずかで、DMARC準拠のメール送信に必要なコストが見合わない場合、このアプローチが適しているかもしれません。
3つ目の方法（手動設定）は、サブドメイン委任の方法と同程度の導入作業が必要ですが、開始するにはより具体的な変更が必要となります。
さらに、3つ目のアプローチは脆弱であると言える。自社のインフラストラクチャに変更が生じた場合、顧客側でもそれに応じたドメイン設定の変更が必要になる可能性があるからだ。こうした変更の調整は、手間がかかり、コストもかかり、エラーが発生しやすい。
顧客に代わってメールを送信する
DMARC準拠のメールを送信することは、自社にとっても顧客にとっても多くのメリットがあり、メールの識別性を高める上で非常に有効です。最高水準のメール（あるいは単に確実に届くメール）を送信したいとお考えなら、一歩踏み込んで、メールに関連するあらゆる場面で顧客のドメインを使用することを検討してみてください：
- メール内のリンクは、一見すると顧客のドメインから送信されたように見えますが、誰かがそのリンクをクリックすると、実際には自社のインフラを通じて処理される場合があります。
- 画像やその他のオブジェクトについても同様です。これらは顧客のドメインから配信されているように見えますが、実際には自社のインフラストラクチャから提供されています。
- メール配信に関連するサーバー名は、お客様のドメインに合わせて変更することができます。
サブドメイン方式を採用すれば、上記の変更が可能になります。これにより、顧客に代わって送信するメールの識別と配信が極めて容易になります。
メール配信元のディレクトリへの掲載をご希望の方は、[email protected] までご連絡ください。
ご質問やご意見がございましたら、[email protected] までご連絡ください。
私たちがお手伝いします
dmarcianは、メールセキュリティの専門家チームを擁し、「ドメインセキュリティを通じてメールとインターネットの信頼性を高める」ことを使命としています。私たちは、組織が保有するドメイン群の現状評価から、DMARCの導入、そして長期的な運用管理に至るまで、手厚くサポートいたします。
この会話を続けたいですか？dmarcianフォーラムへどうぞ。
