こんにちは。バナナデスクです。
「Gmailにメルマガが届きません」と連絡が来たとき、件名を変えてもう一度送る前に、確認したいものがあります。配信システムの記録では、成功、保留、エラーのどれになっているでしょうか。
送信側で止まったメールと、Gmailに受け取られた後で迷惑メールに入ったものでは、調べる場所が違います。同じ「届かない」でも、最初から認証や文章の問題と決めつけない方が、解決に近づきやすくなります。
この記事では、独自ドメインからメルマガを配信する個人事業主向けに、エラー、認証、受信側の状態を切り分けます。DNSの値を自己流で書き換える手順ではなく、配信サービスやドメイン管理担当へ何を渡せばよいかまで整理します。
最初に三つの状態へ分ける
| 配信側の記録 | 考える範囲 | 先に集めるもの |
|---|---|---|
| 送信されていない・除外 | 解除、エラーによる抑止、対象条件、配信開始前の状態 | 読者の配信状態、対象条件、予約日時 |
| 保留・拒否・エラー | 受信側の応答、認証、送信量、接続など | 送信日時、メッセージID、エラーコードと本文 |
| 配信成功 | 成功の定義、迷惑メール、受信ルール、宛先の取り違え | 到達記録、受信側で確認した場所 |
解除済みの人が対象から外れているなら、配信の不具合とは限りません。届かないという問い合わせだけを理由に、解除状態を勝手に戻すのは避けます。本人が再登録を希望する場合は、サービスの正規の手続きと同意の記録に沿って進めます。
配信成功という表示も、必ずメインの受信箱に表示されたという意味ではありません。配信サービスがどの段階を成功としているかを確認し、読者には迷惑メールやフィルタ、別のGmailアカウントを見ていないかを確かめてもらいます。
Gmailの要件は、すべての送信者と大量送信者で区別する
Googleの送信者ガイドラインは、個人用Gmailアカウントへのメールについて要件を示しています。一般の送信者にはSPFまたはDKIMによる認証などが求められ、1日5,000件以上を送信する送信者にはSPFとDKIM、DMARC、ドメインの整合など追加要件があります。閾値の数え方を含め、実際の送信形態で該当条件を確認してください。Google公式：メール送信者のガイドライン
「すべての送信者に同じ三つが必須」と混同しない一方、少量なら認証を気にしなくてよいわけでもありません。配信サービスが推奨する認証設定を整え、自分の送信ドメインで何が設定されているかを確認します。
大量送信者のマーケティングメールなどには、ワンクリックで登録解除できる仕組みと、本文に分かりやすい解除リンクを置く要件もあります。本文にURLを書けば、メールヘッダーを用いたワンクリック解除の条件まで満たすとは限りません。対応は配信サービス側の機能も確認します。
SPF・DKIM・DMARCは、別々の役割として確かめる
認証をざっくり整理すると、SPFはそのドメインの送信元として許可されたサーバーか、DKIMは署名を検証できるか、DMARCは表示上の差出人ドメインとの整合や認証結果に応じた扱いを確認する仕組みです。細かな設定は送信サービスとドメイン構成で変わります。
| 項目 | 担当者へ確認すること |
|---|---|
| SPF | いま使う配信サービスが許可されているか。既存の業務メールの送信元も保持されているか |
| DKIM | 配信サービス指定の署名設定が有効か。実際のメールで検証が成功するか |
| DMARC | 差出人との整合、現在のポリシー、他の送信サービスへの影響 |
| ほかの要件 | TLS、DNS、迷惑メール率、送信形態に応じた解除機能など |
DNSへ追加する値は、配信サービスが発行したものを使います。別の記事の例をコピーしたり、既存のSPFレコードを消して新しいものだけを置いたりすると、普段の業務メールへ影響する可能性があります。自分で判断できない部分は、既存の設定と送信サービスの一覧を担当者へ渡して確認します。
設定画面に値を保存できたことと、実際のメールで認証が通ったことも別です。受信できる検証用メールでヘッダーの認証結果を確認します。認証が成功していても、受信箱への配置や必着を保証するものではありません。
三つのログ例から、問い合わせ先を決める
以下は説明用に作った仮の記録です。実際の宛先や運用ログではありません。エラーはコードだけでなく全文と発生状況を読み、サービス側の説明で判断します。
| 仮の記録 | 分かること | 次の連絡先 |
|---|---|---|
| A：配信対象から除外、状態は配信停止 | 受信側へ届く前に対象から外れている | 運用担当。停止の経緯と本人の希望を確認 |
| B：拒否、5.7.26、認証に関する説明あり | 認証について受信側が拒否理由を示している | 配信サービスとドメイン管理担当へ全文を共有 |
| C：配信成功、Gmailの迷惑メール内で発見 | 未送信ではない。受信箱の配置を調べる段階 | 配信サービスへ送信状況を確認し、読者側の設定も照合 |
5.7.26はGoogleの公式ガイドにも認証に関するエラーとして説明されています。ただし、コードを見つけただけで、SPFの一か所を直せば必ず解決するとは言えません。実際に受信側が返した説明と、どのドメインの認証が失敗したかを確認します。
一時的な保留と恒久的な拒否も同じ扱いにしません。配信サービスに再試行の仕組みがあるのに、運営者が何度も手動送信すると、重複や送信量の増加を招きます。まず再試行中なのか、最終失敗なのかを確認してください。
サポートへ送る確認依頼の完成例
「届きません。直してください」だけでは、担当者も対象を特定できません。公開してよい情報と、サポートの安全な窓口で共有する情報を分け、次のようにまとめます。
件名：Gmail宛メルマガの送信結果確認のお願い
対象配信：10月8日10:00開始の定期配信
差出人ドメイン：当社が管理する配信ドメイン
対象範囲：今回のGmail宛の一部
配信画面の状態：拒否と表示
直近の変更：配信サービスの切替を実施
確認済み：対象者の解除状態、宛先の入力、予約日時対象メールのメッセージIDとエラー全文を、指定の安全な窓口で共有します。認証結果、送信元の設定、再試行の有無について確認をお願いします。業務メールも同じドメインを使用しているため、既存設定への影響を含めて変更方法をご案内ください。
これは問い合わせ文の仮例です。実際の日時や変更点に置き換え、分からないことは分からないまま書きます。エラー全文にメールアドレスなどが含まれる場合は、SNSや公開フォーラムへ無加工で貼り付けないようにしてください。
認証が通っているときは、送信の仕方と読者の期待も確認する
技術設定が整っていても、古いアドレスへ急に大量送信する、登録時に説明していない内容を繰り返す、解除の入口を見つけにくくする、といった運用は見直しが必要です。Googleのガイドラインも迷惑メール率や送信量、解除方法などを扱っています。
ただし「この単語を書いたら必ず迷惑メール」という単純な禁止語表だけで原因を判断しません。同じ内容でも送信元や受信者の状態などの条件が異なります。件名を何度も変えて繰り返し送るより、同意を得た対象へ、認識できる差出人で、期待された内容を送ることを確認します。
しばらく送っていない読者へ再開する場合は、配信サービスの案内に従って対象と送信量を検討します。解除者や恒久エラーのアドレスを、新しいリストへ移して再度送る運用はしません。
変更後は、一つのテストで終わらせず確認範囲を記録する
修正したら、変更日時、変更した項目、対象配信、認証結果、受信場所を残します。自分のGmail一つに届いたから全員に届くと報告しないこと。確認できたのは、その宛先と条件での受信です。
| 段階 | 残す内容 |
|---|---|
| 変更 | 誰が何を変更したか。元の業務メールへの影響確認 |
| 検証送信 | 日時、対象の検証用宛先、メッセージID |
| 送信側 | 成功・保留・エラー、認証結果 |
| 受信側 | 受信箱・迷惑メール等、確認した時刻 |
| 通常配信 | 次の配信で同種のエラーが再発していないか |
Gmailに届かない問題は、文章だけでもDNSだけでも説明できない場合があります。まず送信の状態を分け、エラーの根拠を取り、必要な担当者へ渡す。その順に進めると、無関係な設定変更や重複送信を減らしながら原因を絞れます。