メールドメイン認証は、メッセージの送信元と、受信者に表示されるアドレスが一致しているかを受信側のシステムが確認するために役立ちます。Shopifyのマーケティングメールで大切なのは、正規の送信元をすべて把握し、アカウントに指定されたDNSレコードを設定し、実際に届いたテストメールを確認することです。SPF、DKIM、DMARCはそれぞれ異なる役割を持ち、いずれも受信トレイへの到達を保証するものではありません。
まず、正規の送信元をすべて把握する
顧客サポートへの返信、スタッフ間のメール、注文通知などが、すでに別々のサービスから送られている場合があります。送信元を一覧にし、誰がDNSを管理しているか確認してください。マーケティング用の設定を変更する前に現在の構成を記録しておくと、通常の業務メールが止まるのを防ぎやすくなります。
Sendvioのアカウントに対して指定されたレコードをそのまま使用してください。スクリーンショットや別のストアの値を流用してはいけません。SPFは送信を許可されたインフラを示します。DKIMはメッセージの署名を受信側が検証できるようにします。DMARCは表示されるFromドメインとのアライメントを確認し、認証に失敗したメールの扱いを示します。
各チェックがどの識別情報を見ているか理解する
配信に関係する識別情報は、顧客に表示されるFromアドレスだけではありません。SPFは送信処理で使われるドメインを確認し、DKIMは署名ドメインに関連付けられた署名を検証します。DMARCは、認証に成功した結果と表示上のFromドメインをアライメントによって結び付けます。そのため、認証チェックに合格しても、意図したアライメント条件まで満たしているとは限りません。
実務では、管理者に実際のテストメールから3つの情報を記録してもらいましょう。表示されるFromドメイン、SPFに合格したドメイン、合格したDKIM署名のドメインです。そのうえで、適用されるDMARCのアライメント結果を確認します。名前が似ていることや設定画面でレコードに緑のチェックが付くことは、メッセージ単位の確認の代わりにはなりません。
Reply-Toアドレスには別の役割があります。受信者のメールアプリが返信先として使うアドレスです。顧客対応のために適切な返信先を選ぶことは大切ですが、それによってSPF、DKIM、DMARCのアライメントが修復されるわけではありません。返信対応と認証は、公開前のチェック項目として分けてください。
認証に合格してもアライメントに失敗するケースを追う
例として、表示されるFromアドレスが updates@sendvio.com のメールを考えます。DKIMには合格していますが、署名ドメインは別の送信サービスのものです。署名に成功すれば識別情報は検証されますが、それだけでsendvio.comとのアライメントが成立するわけではありません。管理者はDKIMの横にある「pass」だけでなく、実際の署名ドメインと適用されるアライメントルールを確認する必要があります。
別の合格したDKIM署名が適切にアライメントされたドメインを使っていれば、SPF側のアライメントが成立しなくても、DMARCではDKIMの経路で条件を満たせる場合があります。そのため、ヘッダー内のすべての項目が同じかを見るのではなく、認証された各識別子と表示されるFromドメインとの関係を追うことが大切です。厳格モードと緩和モードではアライメントの要件が異なるため、設定内容を確認しましょう。
この例は、DNSの手順としてではなく、ドメイン管理者に確認する質問として使ってください。どの正規の送信経路を認証しているのか、どの識別子がアライメントされるのか、実際の受信側が何を報告しているのかを尋ねます。マーケティング、サポート、その他の影響を受ける送信経路ごとに結果を記録してください。マーケティングのテストが1通成功しても、無関係なスタッフメールがポリシー変更後も届くとは限りません。
順序を決めて慎重に変更する
ドメイン管理者と一緒に、必要なレコードを追加または更新します。同じホスト名に競合するSPFレコードを作ったり、別の正規の送信元が使う項目を削除したりしないでください。DNSの変更が反映されるまで時間がかかることがあるため、すぐに確認できなくても値が間違っているとは限りません。
DMARCポリシーを強化する前に、現在のポリシーとレポートを確認します。すべての正規の送信元でアライメントが整う前に厳格なポリシーを適用すると、そのメールまで止まることがあります。ポリシー強化をワンクリックの到達性改善策と考えず、実際の送信状況を管理者または有資格者に評価してもらいましょう。
設定上の問題には担当者を割り当てる
DNSレコードの変更はドメイン管理者が担当し、送信者情報の選択とキャンペーンのテストはマーケティング担当者が行います。送信設定の調査ではSendvioサポートが役立つ場合があります。大量配信の前に担当範囲を明確にし、問題が起きたとき複数の人が独自にレコードを変更する状況を防ぎましょう。
チェックに失敗したら、要求されているホスト名と値をDNSの実際の公開内容と照合します。設定では、ドメイン名が自動で付加される欄に完全なホスト名を入力する、誤ったサブドメインに公開する、競合するレコードを残すといったミスがよくあります。値が一致していて変更直後なら、DNSキャッシュを考慮してから再確認し、追加変更を行ってください。
変更前の構成と変更理由を日付付きで記録します。その後、通常のサポートメールに不具合が起きた場合、管理者が影響を調べる手掛かりになります。以前の構成に戻す際も、新しく作ったレコードをすべて無条件に削除しないでください。別の正規サービスが同じ設定に依存している場合があります。
レポートを次の設定判断に活用する
DMARCレポートを利用できる場合は、集約データから送信元と認証の傾向を確認します。見覚えのない送信元は調査が必要です。見落としていた正規サービス、未許可の活動、さらに確認すべき送信経路のいずれかかもしれません。レポートを整えるためだけに、その送信元を許可してはいけません。
レポートの対象範囲や届くタイミングは異なり、集約レポートが受信トレイへの到達を保証するわけではありません。実際のメッセージテストと正規の送信元一覧をあわせて確認してください。ポリシーを強化する前に、正規の送信経路で起きている重要な失敗を担当者と解決し、影響を把握します。変更後も監視を続け、レコードを公開した時点で作業が終わったとは考えないでください。
今後の変更に備えた確認手順を残します。サポート用の新しいツールを追加したり、サービスを停止したりするときは、関連する許可設定とアライメントを見直します。この習慣があれば、以前は正しかった設定が、誰も安全に変更できない記録の寄せ集めになるのを防げます。
設定画面だけでなく実際のメールを確認する
テストメールを送信し、認証結果を調べます。表示されるFromドメイン、認証されたドメイン、期待されるアライメントを確認してください。その後、返信先とリンクを含む通常のキャンペーン設定をテストしてから、大きな対象者へ送ります。
認証とリストの品質は別に扱います。正しく認証されたメールでも、望まれていない内容、誤解を招く内容、頻度の高すぎる配信であれば問題になります。Sendvioの検証機能やウォーミング機能は配信プロセスを支援しますが、許可の管理、認識しやすい送信者、役立つ内容には引き続き責任があります。ドメインや送信サービスを変更したときは設定を再確認し、その結果を公開前のチェックリストに残しましょう。
設定レビューの完了時には、チェックマークだけでなく証拠を残します。アカウント用に指定されたレコード値、送信メールで使われたドメイン、必要な場合は合格したアライメント結果、返信先が機能することを記録します。将来の移行やドメイン変更で照合できるよう、キャンペーンの運用メモと一緒に保管してください。
認証に合格しているのに配信状況が悪い場合は、別の要因を調べます。受信許可、苦情の履歴、送信量、内容、受信側の応答などです。すでに認証されているメールのDNSを繰り返し変更すると、本来の問題を残したまま新しい不具合を作るおそれがあります。認証によって送信元を検証できるようにし、その送信元を信頼する価値は、受信者との望ましい関係を保つことで築きます。