ロリポップのメールがGmailに届かない｜設定の前に「ネームサーバー」を見る

2026年9月14日2026年9月16日

ロリポップのメールがGmailに届かないときは、設定の前に送信経路とDNSを確認

ロリポップから送ったメールがGmailに届かない。迷惑メールに入る。差出人の横に「？」が付く。そんなときは、DNSレコードを追加する前に、送信方法とネームサーバーを確認しよう。

この記事の対象は、独自ドメインのメールをロリポップのメールサーバーから送る場合だ。WordPressをロリポップに置いていても、MailPoet Sending Serviceや別の外部SMTPから送るメールには、その送信サービスの設定が必要になる。

利用している送信サーバーがエックスサーバーなら、エックスサーバーからGmailに届かないときの確認手順を参照してください。

ConoHa WINGのメールサーバーを使っている場合は、ConoHa WINGからGmailに届かないときの確認手順を参照してください。

結論：送信方法とネームサーバーで確認先を分ける

ロリポップDNSの対象ネームサーバーを利用：公式にSPF・DKIM・DMARCへの対応が案内されている。認証のためだけにDNSを切り替えず、まず受信したメールの認証結果を見る。
ムームーDNSへロリポップのアカウントを連携：DKIMは対応済み。SPFとDMARCの現在の設定を確認し、必要な分を設定する。
外部DNSや別の送信サービスを利用：この設定例をそのまま使わず、そのサービスが指定する値とDNSの設定先を確認する。

ロリポップの構成別の対応は、公式のDKIM・DMARC対応のお知らせに記載されている。サイトの設置先だけで、メールの送信経路まで決めつけないのが出発点だ。

送信方法とDNSによる確認先。ロリポップDNSは対象の構成と認証結果、ムームーDNS連携は既存SPF・DMARC、外部送信サービスやその他DNSは指定値と設定先を確認する。 — サイトの設置先だけで判断せず、実際の送信方法と利用中のDNSから確認先を選ぶ。

ロリポップDNSなら、対象の構成を確認する

公式が設定不要と案内しているネームサーバーは次の4つ。ドメインを管理しているサービスのネームサーバー設定で、現在の値と照合する。

uns01.lolipop.jp
uns02.lolipop.jp
dns01.chicappa.jp
dns02.chicappa.jp

この構成でロリポップのメールサーバーから送信する場合は、利用者がSPF・DKIM・DMARCを設定する必要はないという案内だ。同じお知らせでは、Webメーラー、メーリングリスト、メールマガジンからの送信も対応済みとされている。これは、個々のメールが必ず受信トレイへ届くという保証ではない。

ムームーDNSでは、追加前に既存の設定を見る

ムームーDNSへロリポップのアカウントを連携している場合は、SPF・DMARCの設定状況を確認する。以下はロリポップ公式が示す設定例。既存のレコードへ無条件に2行を足すためのものではない。

項目	SPF	DMARC
サブドメイン	空欄	`_dmarc`
種別	TXT	TXT
内容	`v=spf1 include:_spf.lolipop.jp ~all`	`v=DMARC1; p=none;`

ムームーDNSで対象ドメインを開き、既存のSPF・DMARCとサービス連携の設定を確認する。
SPFがすでにある場合は重ねて追加しない。別の送信サービスを使っているなら、そのサービスの指定も確認する。既存のSPFを上の例だけで上書きすると、他の正規の送信元を外してしまうことがある。
DMARCも既存の方針を確認する。すでにquarantineやrejectを運用しているドメインへ、理由なくp=noneを上書きしない。

画面上の入力方法はムームーDNSカスタム設定の公式案内を確認し、サービス別の設定と手動のTXT追加を重複させない。ムームーのDKIM・DMARC設定案内も、ロリポップなどの設定についてはこのサービス別の案内を参照するよう示している。

SPFは同じ名前に複数のSPFレコードを公開しない。DMARCのp=noneは、認証に失敗したメールの隔離や拒否をドメイン所有者が求めない方針だ。認証を省略したり、受信を保証したりする設定ではない。仕様はSPFのRFC 7208とDMARCのRFC 7489で確認できる。

「切り替えれば直る」と考える前に

ムームーDNSへの移行は、同じドメインで対応サービスを併用するための選択肢だ。ロリポップDNSで認証が提供される構成なら、メール認証のためだけに移行する必要はない。

切り替える場合は、移行先のWeb・メールの設定を先に確認する。移行先で必要なSPF・DMARCが未設定なら、認証が通らなくなるおそれがある。必ず未設定になるわけではなく、準備した内容次第だ。

ロリポップのムームーDNS移行マニュアルでは、ネームサーバー変更の反映に24〜72時間程度かかり、その間にホームページが表示されない場合があると案内されている。また、メールは独自ドメインを設定したサービスでのみ利用できる。レコード設定の反映についてムームーが案内する最大1時間とは、対象の違う時間だ。

Gmailで認証結果を確かめる

問題が起きているのと同じ送信方法で、自分の個人用Gmailアドレスへテストする。フォームからのメールが問題なら、フォームから送って確かめよう。

パソコンのブラウザ版Gmailで、受信トレイまたは迷惑メールに届いたテストメールを開く。
メールの返信ボタン横にある「︙」から「メッセージのソースを表示」を開く。
Gmail側の認証結果（Authentication-Results）を確認する。

操作位置はGoogle公式のメールヘッダー確認手順を参照。どこにも届かない場合は、そのメールのヘッダーをこの方法で開けないので、送信側へ返ったエラーの確認に進む。

spf=passとdkim=passは、それぞれの認証に合格したことを示す。dmarc=passなら、SPFまたはDKIMの少なくとも一方で、差出人のFromドメインとの整合も成立している。SPFやDKIMがpassでもDMARCがfailなら、その整合を確認する。

spf=noneはSPFレコードを取得できない場合などの結果で、spf=softfailは既存のSPFレコードを評価した結果だ。SPFを書き忘れれば必ずsoftfailになるわけではない。dkim=noneは署名がないことを示し、DNSの反映待ちとは断定できない。判定の意味はAuthentication-ResultsのRFC 8601とSPFの仕様を参照し、実際の送信経路とレコードを照合する。

ロリポップのSMTPを使うContact Form 7の通知については、Contact Form 7の通知がGmailに届かないときの設定手順も参照してください。DNSの設定だけで終えず、フォームの送信元・返信先、SMTPへの接続、実フォームの送信結果を順に確認します。

認証が通っても届かないとき

認証のpassは受信トレイへの到達保証ではない。別の送信方法のメールに同じ結果を当てはめず、エラー通知、送信量、本文やリンク、迷惑メール判定も確認する。

個人用Gmail宛では、少量でもSPFまたはDKIMが必要だ。同じプライマリドメインから24時間で5,000通近く、またはそれ以上送る一括送信者には、SPF・DKIM・DMARCなどの追加要件がある。サブドメイン分も合算され、一度対象になるとその扱いは続く。認証以外の要件もGoogleの送信者ガイドラインと送信者向けFAQで確認しよう。

ロリポップ公式FAQ「Gmail宛にメールが送信できません」は、エラーメールの有無で確認先を分けている。エラーが返る場合は、そこに記載されたGoogleの案内を確認する。解決しなければ、送信日時やエラー全文などを揃えてロリポップへ相談する。

Gmail送信者ガイドラインの全体像は、WordPress運用で確認する設定と送り方にまとめています。ロリポップ側の認証設定に加え、差出人設定や送信規模に応じた要件も確認してください。