カスタムReturn-Pathとトラッキングドメインは、多くの送信者が見落としがちな二つのブランディングおよび認証の設定で、それぞれ異なる理由で重要です。カスタムReturn-PathによってSPFがFromドメインとアライメントし、DMARCが成功する経路が二つになります。カスタムトラッキングドメインは、クリックリンクや開封リンクに自社の名前を表示します。このガイドでは両者を説明し、関係するDNSレコードを示し、テスト方法を解説します。
すべてのメールに含まれる三つのドメイン
1通のメッセージには複数のドメイン名が含まれ、それぞれが異なる検証に使われます。その違いを理解すると、これらの設定が存在する理由がわかります。
| 名前 | 現れる場所 | 用途 |
|---|---|---|
| Fromドメイン | Fromヘッダーに表示されるアドレス | DMARCは、他の検証結果をこのドメインと比較する |
| Return-Pathドメイン | エンベロープ送信者(MAIL FROM)。Return-Pathヘッダーに表示される | SPFはここで検証され、バウンスもここに配送される |
| DKIM署名ドメイン(d=) | 署名ヘッダー | DKIM検証と、Fromドメインとのアライメント |
| トラッキングドメイン | 本文中のリンクとトラッキングピクセルの内部 | リンクの評価、セキュリティスキャン、ブランドの信頼性 |
アライメント:Return-Pathドメインが重要な理由
DMARCでは、SPFまたはDKIMの少なくとも一方が成功し、成功したドメインがFromドメインとアライメントしている必要があります。アライメントとは関連しているということです。デフォルトである緩やかなアライメントでは、同じ組織ドメインのサブドメインも一致とみなされます。プラットフォームが自社のドメインをReturn-Pathとして使っている場合、そのドメインについてSPFは成功しますが、自社のドメインとは一致しないため、SPFはDMARCの役に立ちません。自社のサブドメインにカスタムReturn-Pathを設定すれば、SPFが成功し、かつアライメントします。
| 構成 | SPFの結果 | DMARCの結果 |
|---|---|---|
| プラットフォームのドメインのReturn-Path、アライメントしたDKIM | 成功、アライメントなし | DKIMのみで成功 |
| 自社サブドメインのカスタムReturn-Path、アライメントしたDKIM | 成功かつアライメントあり | 両方で成功し、より堅牢 |
| カスタムReturn-Path、DKIMが転送中に破損 | 成功かつアライメントあり | SPFにより引き続き成功 |
| プラットフォームのReturn-Path、DKIMが転送中に破損 | 成功、アライメントなし | 失敗 |
SPFは転送されると維持されません。メールが転送されると、SPFは転送元のサーバーに対して検証されるため、通常は失敗します。転送後も維持されるのはDKIMです。そのため、アライメントしたDKIMが第一の目標であり、カスタムReturn-Pathは代替ではなく第二の防御層です。
カスタムReturn-Pathの設定
- サブドメインを選びます。bounce.mail.example.comのような、バウンス専用の名前を選びます。トラッキング用のサブドメインとは分けてください。
- プラットフォームが指定するレコードを追加します。一般的には、プラットフォームの名前を指すCNAME、またはバウンスをプラットフォームに届けるMXレコードです。そのままコピーしてください。
- サブドメインのSPFレコードを確認します。通常は、CNAMEの先でプラットフォームがSPFポリシーを管理します。そうでない場合は、プラットフォームを許可するSPFレコードをサブドメインに公開してください。
- 待機して検証します。レコードのTTLが経過するのを待ち、送信ドメインの検証のガイドで説明しているとおり、プラットフォームでドメインを検証します。
- テストを送信してヘッダーを確認します。Return-Pathヘッダーが自社のサブドメインを使っていること、認証結果でそのドメインに対するSPFが成功していることを確認します。
Return-Path: <bounce+abc123@bounce.mail.example.com>
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=bounce.mail.example.com;
dkim=pass header.d=mail.example.com;
dmarc=pass header.from=mail.example.comこの例では、Return-PathドメインがFromドメインのサブドメインであるため、緩やかなアライメントが成立し、SPFがDMARCの成功に貢献します。
カスタムトラッキングドメインの設定
リンクトラッキングは、メッセージ内の各リンクをリダイレクトを経由するよう書き換え、クリックを集計できるようにします。開封トラッキングは、読み込みが集計される小さな画像を追加します。どちらもドメインを使います。デフォルトでは、そのドメインはプラットフォームのもので、多くのお客様と共有されています。カスタムトラッキングドメインは、それを自社のサブドメインに置き換えます。
- サブドメインを選びます。たとえばlinks.example.comです。受信者にとって自然に見える名前を使ってください。
- CNAMEを公開します。サブドメインを、プラットフォームから提示された名前に向けます。CNAMEは、その名前における唯一のレコードでなければなりません。
- 証明書を待ちます。CNAMEが解決されると、プラットフォームがそのサブドメインの証明書を要求します。数分から数時間かかることがあります。
- 送信で有効にします。新しいメッセージで使われるよう、送信設定またはストリームごとにトラッキングドメインを選択します。
- テストリンクをクリックします。メッセージを開いてトラッキングリンクをクリックし、ブラウザーの警告なしにHTTPSで読み込まれ、正しいページに移動することを確認します。
HTTPSが任意ではない理由
トラッキングリンクは、受信者、ブラウザー、セキュリティスキャナーが最初に触れるものです。httpで始まるリンクや、証明書の警告が出るリンクは疑われ、クリックを失います。企業のゲートウェイによっては、そうしたリンクを書き換えたり、完全にブロックしたりします。トラッキングを有効にする前に証明書が有効であることを確認し、更新が自動化されていることも確かめてください。
カスタムトラッキングドメインのメリットとトレードオフ
| メリット | トレードオフ |
|---|---|
| リンクの評価が、素性の分からない送信者と共有されず、自社だけのものになる | 自社のミスも自社のドメインに影響するため、クリーンに保つ必要がある |
| リンクがブランドと一貫して見える | 管理するサブドメインと証明書が増える |
| ストリームごとに一つのトラッキングドメインを使うことで、ストリームを分けやすい | 文書化すべきDNSレコードが増える |
| 共有ドメインの別の送信者がブロックリストに載っても影響が少ない | 新しいドメインには実績がないため、段階的に導入する必要がある |
新しいトラッキングドメインは段階的に導入してください。リンクで一度も使われたことのないドメインには、良くも悪くも評価がなく、初日から大量に送信すると不自然に見えることがあります。ウォームアップのガイドで説明している慎重なランプアップと同じ方法に従ってください。
一部のメッセージではトラッキングをオフにすべきか
開封トラッキングとクリックトラッキングは便利な機能であり、必須ではありません。パスワードリセットやログインコードなどのセキュリティ関連メッセージでは、多くのチームがトラッキングをオフにしています。リンクは自社サイトに直接向かうべきで、書き換えられたリンクは、本物のメッセージをユーザーやフィルターにフィッシングのように見せてしまうことがあります。また、メールアプリが画像をプリロードするため、開封トラッキングの信頼性が下がっていることにも注意してください。開封はおおまかな目安として扱い、重視すべき指標はクリックとコンバージョンです。
事例:1つのドメインで2つのストリーム
注文確認と週次のプロモーションを送るショップを想像してください。ルートドメインexample.comはスタッフのメール用に残し、ストリームごとに一つずつ、二つの送信用サブドメインを作成します。それぞれが独自のレコード一式を持つため、二つの評価が混ざることはありません。
| ストリーム | Fromドメイン | Return-Path | トラッキングドメイン |
|---|---|---|---|
| トランザクション | orders.example.com | bounce.orders.example.com | なし(セキュリティ関連メッセージではトラッキングをオフ) |
| プロモーション | news.example.com | bounce.news.example.com | links.news.example.com |
この構成では、プロモーションのストリームで苦情が急増しても、影響を受けるのはnews.example.comとそのリンクドメインだけで、注文確認は自らのクリーンな履歴を保てます。すべてのReturn-Pathは、それぞれのFromドメインのサブドメインなので、緩やかなアライメントのもとでSPFがアライメントします。各ストリームは独自のDKIMセレクターで署名するため、一方に影響を与えずにもう一方の鍵をローテーションすることも簡単です。コストはDNSレコードが少し増えることですが、分離できることを考えれば小さな代償です。
後からストリームを追加する場合は、新しい方式を考え出すのではなく、このパターンをそのまま踏襲してください。名前の付け方が一貫していれば、ヘッダー、DMARCレポート、ブロックリストの通知を見たときに、そのメッセージがどのストリームのものかがすぐにわかり、あらゆる調査が速くなります。
トラブルシューティング
| 問題 | 考えられる原因 | 対処 |
|---|---|---|
| Return-Pathがまだプラットフォームのドメインのまま | そのストリームでカスタムReturn-Pathが有効になっていない | 送信設定でドメインを選択し、再送信する |
| SPFは成功するがDMARCは失敗する | Return-PathドメインがFromとアライメントしていない | Fromドメインのサブドメインを使う |
| CNAMEを追加できない | その名前に別のレコードが存在する | CNAME用に新しいサブドメインを使う |
| トラッキングリンクで証明書の警告が出る | 証明書が未発行または期限切れ | CNAMEとプラットフォーム上のドメインの状態を確認する |
| トラッキングリンクがエラーになる | CNAMEが誤った宛先を指している | アカウントに表示されている値と比較する |
| リンクが受信側のゲートウェイにブロックされる | 評価のない新しいトラッキングドメイン | 段階的にランプアップし、短縮URLは避ける |
継続的に維持する
- すべてのサブドメインとその用途を、一か所に文書化します。
- DNSの移行やレジストラの変更の後は、レコードを確認します。
- トラッキングドメインの証明書の有効期限を監視します。
- プラットフォームを変更したり、新しい送信サービスを追加したりした後は、アライメントを再テストします。
- DMARCレポートを確認し、アライメントに失敗している送信元がないか調べます。
DNSの設定を第三者の目で確認しませんか?送信ドメインをお知らせいただければ、Return-Pathとトラッキングのレコードを確認します。
参考資料と出典
よくある質問
Return-Pathアドレスとは何ですか?
エンベロープ送信者のことで、MAIL FROMやReturn-Pathとも呼ばれ、バウンスの送り先になるアドレスです。受信者に表示されるFromアドレスとは別のものです。SPFは、表示されるFromアドレスではなく、このエンベロープアドレスのドメインに対して検証されます。
カスタムReturn-Pathが重要なのはなぜですか?
DMARCは、SPFまたはDKIMのいずれかが成功し、かつFromドメインとアライメントしている場合に成功します。Return-Pathがプラットフォームのドメインを使っていると、SPFは成功してもFromドメインとはアライメントしません。自社のサブドメインにカスタムReturn-Pathを設定すれば、SPFがアライメントし、DKIMに加えてDMARCが成功するもう一つの経路ができます。
DKIMがアライメントしていれば、カスタムReturn-Pathは不要ですか?
DMARCに必要なのは、アライメントした成功が一つだけなので、アライメントしたDKIMがあれば十分です。それでも、カスタムReturn-Pathは第二の防御層として設定する価値があります。DKIM署名が転送中に壊れてもDMARCの成功を維持でき、バウンスも自社ドメインのブランドで扱えるためです。
トラッキングドメインとは何ですか?
書き換えられたリンクや開封トラッキング用ピクセルで使われるドメインです。カスタムトラッキングドメインを使うと、共有のプラットフォームドメインではなく、links.example.comのような自社のサブドメインにリンクが向くようになります。そのため信頼されやすく、リンクの評価も他の送信者から切り離せます。
トラッキングドメインにHTTPSが必要なのはなぜですか?
ブラウザーやメールクライアントは、安全でないリンクに警告を出したり、ブロックしたりします。httpで始まるリンクは警告の原因となってクリック率を下げることがあり、一部のセキュリティスキャナーも不審なものとして扱います。トラッキング用サブドメインの証明書が、プラットフォームによって発行および更新されるようにしてください。
バウンスとトラッキングに同じサブドメインを使えますか?
使わないほうがよいでしょう。この二つの役割は、レコードの種類が異なり、扱うシステムも別です。サブドメインを分けることで、同じ名前でCNAMEとMXレコードが衝突するといった競合を避けられます。
トラッキングリンクで証明書の警告が出るのはなぜですか?
トラッキング用サブドメインの証明書がまだ発行されていない、期限が切れている、あるいはCNAMEがプラットフォームの想定する宛先を指していないことが原因です。レコードを確認し、証明書の発行を待って、プラットフォーム上でドメインが有効と表示されていることを確かめてください。
カスタムトラッキングドメインで到達率は向上しますか?
間接的に役立つ場合があります。自社の評価を持つブランド化されたリンクドメインを使えば、素性の分からない送信者とリンクドメインを共有せずに済み、メッセージにも一貫性が出ます。ただし、リストの品質の低さや苦情の多さを帳消しにするものではありません。
リンクトラッキングをオフにできますか?
はい、ほとんどのプラットフォームで、メッセージごと、またはデフォルトで、クリックトラッキングと開封トラッキングを無効にできます。パスワードリセットのような機密性の高いメッセージでは、書き換えられたリンクがユーザーやセキュリティツールを混乱させることがあるため、トラッキングをオフにするのが一般的です。