ConoHa WINGから送ったメールがGmailに届かない。迷惑メールに入る。そんなとき、DMARCのスイッチを切り替える前に、確認したいことがある。
この記事では、ConoHa WINGのメールサーバーから独自ドメインで送るメールを対象に、送信経路、DNSの管理先、SPF・DKIM・DMARCの認証結果を順に確認する。WordPressのフォームやニュースレターも、実際にどのサービスから送っているかで設定が変わる。「サイトをConoHaで動かしている」だけでは、メールの送信元までは決まらない。
SPF・DKIMが標準でも、送信経路は確認する
ConoHa WINGのメール機能では、作成したメールアドレスにSPFとDKIMを標準で設定し、DMARCもコントロールパネルから設定できると案内されている。認証の仕組みが用意されている点は心強いが、現在のDNSや外部サービスまで設定が整っていることを保証するものではない。
- メールソフトやWordPressの送信設定で、使っているSMTPサーバー・配信サービスを確認する。
- 差出人（From）に設定されているメールアドレスのドメインを確認する。
- そのドメインのDNSを、どの事業者で管理しているか確認する。
外部SMTPや配信サービスを使う場合は、そのサービスのドメイン認証手順も必要になる。ConoHaの値だけを登録すればすべての経路で認証される、とは考えない。Gmail宛に送ることと、Googleのサーバーを使って送信することも別だ。
DNSは「ドメインを買った場所」と分けて見る
ドメインの購入先と、現在DNSを管理している事業者は同じとは限らない。ドメイン提供元のネームサーバー設定を見て、どこに問い合わせる構成になっているかを確認する。
公式の「DNSを使う」は、ConoHa WINGに必要なDNSレコードがドメイン追加時に自動追加されると説明している。このガイドで案内されているネームサーバーは、次の2つだ。
ns-a1.conoha.io
ns-a2.conoha.io実際の指定は契約側の案内とも照合する。この2つ以外の名前が含まれるだけで、設定が誤っているとは判断しない。
他社のDNSを使っているなら、ConoHaの画面だけを編集しても、受信側が参照するDNSは変わらない。SPFやDKIMの情報は、実際に使っているDNS側に設定する。メール認証のためだけにネームサーバーを急いで変更する必要はない。切り替える場合は、Webサイトやメールの既存レコードも引き継ぐ必要がある。
ConoHaのDNSを使っている場合も、メニューの「DNS」から対象ドメインを開き、現在のレコードを照合する。必要な値が自動追加される仕組みでも、その後の移行や手動編集で変わっている場合があるためだ。
SPF・DKIMの正しい値はメールアドレスのDNS情報で見る
値は別サイトの設定例からコピーせず、対象メールアドレスの情報を使う。公式の「SPF/DKIMのレコード情報を確認する」に沿うと、確認場所は次の順番になる。
- コントロールパネルで「WING」を選ぶ。
- 「メール管理」から「メール設定」を開く。
- 対象のメールアドレスをクリックする。
- 詳細画面の「DNS情報」と、利用中のDNSに登録されたホスト・値を照合する。
サブドメインで使う場合はホスト名にも注意したい。公式には、example.conoha.jpで使うときの例として、SPFのTXTのホストを「example」、DKIMのTXTのホストを「default._domainkey.example」とする案内がある。値はそれぞれ画面に表示されたものを使う。
このexampleは例示なので、自分のドメインにそのまま追加するものではない。他社DNSではホスト名の入力方法も確認し、対象ドメインを二重に付けたり、違うドメインのレコードを編集したりしないようにする。
同じドメインから外部サービスでも送っている場合は、既存の送信元を消さないことが大切だ。SPFは実際に利用する送信元を含めて整え、DKIMはサービスごとの指定を確認する。同じホストにSPFレコードを複数作らず、v=spf1で始まる既存のTXTへ、必要な送信元をまとめる。見慣れないレコードを削除してConoHaの値だけに置き換える前に、何のための設定かを確かめる。
DMARCは、送信側の設定と受信側の処理を区別する
「メール管理」から「メールセキュリティ」を開くと、セキュリティ設定とDMARC認証設定がある。同じ画面に並んでいても、役割を混同しないようにしたい。
ConoHaのDMARC認証設定の公式リリースは、「認証失敗時設定」を送信側の制御として説明している。自分のドメインを名乗るメールがDMARCに失敗したときの扱いに関わる機能だ。一方、受信側が送信ドメインのDMARCを参照してメールを処理する機能は、セキュリティ設定側の説明に分けられている。
「メールセキュリティを設定する」では、認証失敗時設定を有効にするときは「ON」を選び、確認画面で「はい」を選ぶ手順が示されている。扱いの選択肢は「迷惑メール」と「配送拒否」。ただし、Gmailでの最終的な処理や受信トレイへの到達まで、送信側が保証できるわけではない。
DMARCは、SPFまたはDKIMの少なくとも一方が成功し、その認証に使ったドメインとFromドメインが整合していれば合格する。SPFとDKIMの両方を整えることは大切だが、片方が失敗しただけで必ずDMARCも失敗するわけではない。反対に、認証がpassでもFromと整合していなければ、DMARCには合格しない。
失敗時の扱いを厳しくする前には、普段のメールに加え、フォーム通知など同じドメインを使う送信経路も確認する。外部サービスの認証漏れがあるまま進めると、正当なメールにも影響が出るおそれがある。
また、画面の「OFF」だけを見て「DMARCレコードがない」「p=noneになっている」とは判断しない。実際に使っているDNSの_dmarcのTXTを別に確認する。すでに運用中のポリシーを、届かないという理由だけで無条件に弱めるのも避けたい。
運営者の別サイトでは、管理画面にSPF・DKIMのTXTレコードがあり、_dmarcの値は「v=DMARC1; p=quarantine;」だった。認証失敗時設定はON、振り分けは「迷惑メール」、レポート通知はOFFと確認できた。これは一つの環境の現在の状態で、推奨設定やGmailへの到達実験の結果ではない。
レポート通知は、使える条件と通知先を確認する
公式ガイドには、DMARCの認証失敗に関するレポートを1日ごとに通知する機能も案内されている。鉛筆マークから設定を開き、通知を有効にして通知先を指定する。通知先は、設定元と同じドメインを使ったメールアドレスに限られる。
ただし、認証失敗時設定をOFFにしたまま通知機能だけを使えるかは、このガイドの説明だけでは判断できない。「まずレポートだけONにすればよい」と決めつけず、現在の設定との組み合わせや必要なDNSの状態を確認してから利用する。
レポートに失敗が出た場合も、それだけで自分の設定ミスとは限らない。利用している送信元か、心当たりのない送信元かを分けて見る。レポートの件数は、Gmailの受信トレイに届いた件数を示すものでもない。
同じ送信経路でGmailの認証結果を見る
確認用メールは、問題が起きているのと同じ経路で送る。Webメールからの送信に成功しても、別のSMTPを使うWordPressのフォームまで確認できたことにはならない。
- Gmailの受信トレイと迷惑メールフォルダを確認する。
- 届いたメールをパソコン版Gmailで開き、メールのメニューから「メッセージのソースを表示」を選ぶ。
- 表示されるSPF・DKIM・DMARCの結果を確認する。詳細ではGmail側が付けたAuthentication-Resultsを参照し、認証に使われたドメインも見る。
passは、そのメールについて認証に成功したことを示す。失敗や結果なしの場合は、送信元、DNSに公開された値、Fromとの整合をたどる。認証はドメインや送信経路に関する検証であり、メールを書いた個人の本人確認や、内容の安全性の保証ではない。
メール自体が届いていない場合は、Gmailでソースを開くことはできない。送信元に戻ったエラーメールの全文やエラーコード、送信サービス側で確認できる履歴を先に見る。DNSを直した直後なら、公開される値が変わったことを確認してから再度テストする。
ConoHa WINGのSMTPを使ってContact Form 7の通知を送る場合は、Contact Form 7の通知がGmailに届かないときの設定手順も参照してください。ConoHa側の認証設定とは別に、フォームの送信元・返信先と接続先を確認するための手順です。
認証が通っても届かないときに残る確認
SPF・DKIM・DMARCがすべてpassでも、受信トレイに入るとは限らない。Googleのメール送信者ガイドラインは、認証に加えて送信の仕方、メールの形式、迷惑メールの申告なども扱っている。
- フォームのFromに、訪問者が入力した他社のメールアドレスをそのまま使っていないか。
- 宛先の誤りや返送エラーがなく、送信サービス側で実際に送信処理が進んでいるか。
- 意図しない転送経路が入っていないか。直接送る場合と転送する場合を区別できているか。
- 急な大量送信や、受け取りを望んでいない相手への配信になっていないか。
サポートに相談するときは、送信日時、送信方法、エラーコード、認証結果をそろえると切り分けやすい。アカウントのパスワードを伝える必要はない。
認証以外も含めたGmail側の要件は、WordPress運用で確認するGmail送信者ガイドラインで整理しています。送信経路に応じた設定と、差出人や配信方法の確認をあわせて進めてください。
Opsoryの見解：スイッチより、メールが通る経路を見る
ConoHa WINGは認証機能が用意されているからこそ、「標準だから大丈夫」「DMARCをONにすれば解決」と短絡せず、現在の設定と実際のメールを結び付けて見るのがよい。送信経路を確かめ、その経路に必要な情報が利用中のDNSで公開されているかを照合し、Gmailの結果で確かめる。この順番なら、変更が必要な場所を絞り込める。
認証の仕組みはメール到達率の基本で、サーバーを選ぶ際の契約や運用面はConoHa WINGレビューで整理している。別のサーバーを使っている場合は、エックスサーバーのメールがGmailに届かないときの確認手順、ロリポップのメールがGmailに届かないときの確認手順も参照してほしい。
コメント