さくらのレンタルサーバのメールがGmailに届かない｜ネームサーバーとログイン方法から確認する

2026年9月16日

さくらのレンタルサーバからGmailに届かないときに、DNS管理先・ログイン・送信経路を確認する

この記事には広告が含まれます。

さくらのレンタルサーバのメールがGmailに届かないときは、まず「どのサーバーから送ったか」と「メールに使うドメインのDNSをどこで管理しているか」を分けて確認します。さくらでドメインを取得したか、WordPressを置いているかだけでは、設定先は決まりません。

この記事は、さくらのメールサーバーを送信に使う独自ドメイン向けに、公式マニュアルの分岐と確認順を整理したものです。2026年9月16日に一次資料を確認しました。さくらの契約環境での操作・送信試験を行った実測記事ではありません。

送信に使っているのがmixhostのメールサーバーなら、mixhostからGmailに届かないときの確認手順を参照してください。DNSの管理先と現在の認証設定を、利用中のサービスの手順に沿って確認します。

Gmail以外にも送れない、メールの送受信やWebサイト自体を利用できない場合は、DNSを変える前に契約状態、さくら公式のお知らせ、送信サービスへの接続・認証エラーを確認してください。

最初に確認する3点

確認するもの	判断の手がかり
送信経路	メールソフト、ウェブメール、WordPress、外部配信サービスのどれか。さくらのSMTPを通っているか。
DNS管理先	対象のメールドメインが使うネームサーバー。ドメインの購入先と同じとは限りません。
ログイン方法	サーバーコントロールパネルへドメインでログインしているか。メールアドレスでのログインとは表示項目が異なります。

変更前に、現在のSPF・DKIM・DMARCの値と、同じFromドメインを使う送信サービスを控えます。すでに動いている鍵やポリシーを、この記事の例に合わせて作り直す必要はありません。

DNSの管理先で、DKIM・DMARCの設定場所が分かれる

さくら公式のDKIM・DMARC手順は、ネームサーバーがさくら指定のものかどうかで分岐します。メールアドレスに使っているドメインの現在の指定先を確認してください。

現在のネームサーバー	設定の進め方
NS1.DNS.NE.JP NS2.DNS.NE.JP	さくらのサーバーコントロールパネルで対象ドメインのDKIM・DMARCを設定します。
上記以外	さくら側で署名用の設定・公開鍵を確認し、実際のDNS管理サービスへ必要なTXTレコードを登録します。さくら側の操作だけでDNS公開まで完了したとは判断しません。

メールドメインのネームサーバーがさくら指定か他社かで、DKIM・DMARCの設定先を分ける確認図 — DNSの設定先を確認した後、実際に使う送信経路で認証結果を確かめます。公式手順をもとにOpsoryが作成した説明図です。

設定項目が見えないときは、ログイン方法を確認する

サーバーコントロールパネルには、初期ドメインまたは追加したドメインでログインします。メールアカウントでログインしていると、メールドメインやDKIMの設定項目は表示されません。項目がないことだけを理由に、機能が使えないと判断しないでください。

基本の入口は「メール」→「メールドメイン」→対象ドメインの「設定」→「DKIM設定」です。ビジネス以上のプランでは「メール」の代わりに「ユーザー・メール」を開きます。メールドメイン一覧では認証設定の状況も確認できます。画面の表記はさくら公式の操作説明と照合してください。

DKIM未設定なら、鍵の設定とDNSへの公開を進める

未設定の対象ドメインでDKIM設定を開き、秘密鍵の新規作成とセレクタを設定します。すでに有効な鍵がある場合は、先に現状と送信結果を確認します。
「DKIMレコード」の「利用する」にチェックを入れます。DMARCを同時に設定する場合は、次の節で説明する現在のポリシーと正規送信経路を先に確認します。
他社DNSを使う場合は、公式手順に表示されるレコード名と公開鍵などの値を、実際のDNS管理先へ登録します。秘密鍵をDNSへ登録する操作ではありません。
保存後は設定画面を開き直し、公開DNSと受信メールの認証結果を確認します。設定画面のチェックだけでは、受信側での認証成功までは分かりません。

さくら公式はDKIM・DMARCの反映に数時間かかる場合があると案内しています。他社DNSでは管理サービスの反映時間やTTLも確認してください。時間が経過したことと、正しい値が公開されたことは別です。

DMARCは、正規メールを確認してから強める

DMARCは、自分のドメインをFromに使ったメールが認証条件を満たさないときに、受信側へ扱いを求める仕組みです。設定を強くすれば、正規メールも届かなくなることがあります。さくらの画面にある選択肢は、次のように読み分けます。

ポリシー	受信側に求める扱い
none	DMARCを理由とした隔離・拒否を求めません。受信箱への配信を保証する設定ではありません。
quarantine	DMARCに失敗したメールを迷惑メール扱いなどにするよう求めます。
reject	DMARCに失敗したメールの受信を拒否するよう求めます。

実際の処理は受信側の判断にもよります。意味の確認にはDMARCの仕様（RFC 7489）を参照できます。

さくら公式には迷った場合のquarantine案内と、Googleの初期導入時のnone案内が併記されています。Opsoryでは、レポートを読めるかどうかだけで選ぶのではなく、正規メールを見落とさない次の順序を勧めます。

同じFromドメインを使うメールソフト・ウェブメール・フォーム・外部配信サービスを洗い出し、SPF・DKIMとFromの整合を確認する。
DMARCを初めて導入する場合は、noneとレポートを受け取れる仕組みを用意して観測する。すでにquarantineやrejectを運用している場合は、この記事を理由にnoneへ戻さない。
正規メールの認証失敗を直し、普段の送信と定期配信を確認できてから、隔離・拒否へ段階的に進める。レポートを読み解けない場合は、管理担当者や解析サービスなどを使って判断できる状態を作る。

GoogleのDMARC導入手順も、認証の確認、レポートによる観測、ポリシーの強化という段階を設けています。日数だけが過ぎても、月次メールなど未確認の経路があれば確認完了とはしません。

レポート先と、さくらのダッシュボードを分けて考える

DKIMだけを有効にしても、DMARC集計レポートは届きません。DMARCの公開と、ruaなどを通じたレポート先の設定が必要です。ruaには、受信可能な集計用メールアドレスを指定します。

同じドメインの宛先が基本ですが、別ドメインでも宛先側DNSの承認設定を行う方式があります。さくら公式ではこの別ドメイン方式はサポート対象外です。空欄の入力欄だけを見てレポート設定の有無を決めず、実際に公開された値を確認してください。

さくらのDMARCレポートダッシュボードを有効にすると、集計用の専用宛先が追加されます。他社DNS利用時に使えないのはこのダッシュボードであり、適切に設定したrua宛の集計レポート受信まで不可能になるわけではありません。条件はさくら公式のDMARC設定・注記とGoogleのDMARCレポート説明を確認してください。

また、隔離フォルダーをPOPでは取得できずIMAPなどで確認するという注意は、受信側のメールの読み方です。送信者のメールソフトをIMAPに変えても、Gmailへの到達問題を解決する設定にはなりません。

SPFは別の入口から確認する。重複追加に注意

さくら指定のDNSを使っている場合、SPFの入口は「ドメイン/SSL」内の「ドメイン/SSL」→対象ドメインの「設定」→「メールドメイン設定」です。「SPFレコードの使用」を「利用する」にして保存する手順がさくら公式のSPFマニュアルに掲載されています。他社DNSの場合は、そのDNS管理先で設定します。

同じ名前に、v=spf1で始まるTXTレコードを複数作らないでください。すでに別の配信サービスを許可している場合、その条件を消さずに一つのSPFレコードとして見直す必要があります。「1行に見えるか」ではなく、SPFレコードの数を確認します。

公式の例にあるサーバー番号は、契約ごとの値に置き換える前提です。別の記事の例をそのまま貼ったり、既存の~allや-allの後ろへ許可条件を足したりせず、現在の送信元と公式手順を照合してください。allより後の条件は評価されません。SPFの仕様（RFC 7208）でも、同じ名前の複数SPFレコードと評価順が定められています。

SPFの反映時間について、さくら公式は数時間から2日程度かかる場合があると案内しています。反映を待つ間も、レコードを重ねて追加するのではなく、公開値と設定先を確認します。

DKIMが付く送信経路かを確認する

さくら公式がDKIM署名の対象として挙げるのは、さくらのSMTP AUTHで認証した送信、ウェブメール、同サーバーのsendmailコマンド、同サーバーからlocalhostの25番ポートを経由する送信です。DKIM設定と公開DNSが正しいことが前提になります。

PHP・CGIが相手先のメールサーバーへ直接送る場合は、さくらのDKIM署名は付きません。また、外部SMTPや配信サービスのAPIを使う場合は、そのサービスの署名設定を確認します。WordPressがさくら上にあるだけでは、すべてのメールがさくらの署名対象になるとは限りません。

ARCはDKIM設定に伴って自動的に利用開始されますが、さくら内部での配送にはARC署名されません。確認には、普段の経路から自分で管理するGmailなど外部の宛先へ送ったメールを使います。送信経路の条件はさくら公式の「DKIM署名が行われる経路」を確認してください。

フォーム通知だけ届かない場合は、Contact Form 7の送信元・返信先・SMTPの確認手順も参照してください。フォームの表示上の送信成功と、実際のメール到達は分けて確かめます。

Gmailの認証結果と、実際の受信を記録する

Gmailで対象メールを開き、「メッセージのソースを表示」から、Gmailが付けた認証結果を確認します。DKIMの署名ヘッダーが存在することだけでは、検証に成功したかは分かりません。

見る項目	確認したいこと
SPF	結果と、認証された送信元ドメイン（smtp.mailfromなど）。
DKIM	結果と、署名ドメイン（header.dなど）。noneなら署名がない可能性、failなら署名検証の失敗として切り分けます。
DMARC	Fromドメインとの整合を含む結果。SPFまたはDKIMの少なくとも一方が成功し、Fromと整合していることが必要です。
受信状態	受信箱・迷惑メール・未着、送信日時、利用した経路。認証成功でも受信箱に届く保証にはなりません。

SPF・DKIM・DMARCが全部passでなければDMARC失敗、という読み方ではありません。一方で、DMARCがpassでも、認証できたのはドメインや経路に関する条件であり、送信者本人や本文の安全性まで証明するものではありません。整合の条件はGoogleのDMARC設定とアラインメントの説明を参照してください。

メールソフトからの1通で成功しても、フォームや外部配信の成功までは確認できません。経路ごとに結果を残します。Gmail全体の要件はWordPressでGmail送信者ガイドラインを確認する記事、送信サーバーがエックスサーバーの場合はエックスサーバー向けの確認手順を使ってください。