この記事には広告が含まれます。
mixhostのメールがGmailに届かないときは、SPF・DKIMの自動設定を前提にして、すぐDMARCを足すのではなく、「実際の送信元」「現在のDNS管理先」「公開されている認証設定」を順に確認します。自動で設定が作られることと、受信側で認証に成功することは別です。
この記事は、mixhostのメールサーバーから独自ドメインで送信する人向けの確認手順です。2026年9月16日に公式資料を確認しました。mixhostの契約環境で操作・送信試験を行った実測記事ではありません。
Gmail以外にも送れない場合は、まず送信サービスへの接続・ログインエラーや契約状態、公式の障害情報を確認します。Gmail宛てだけの問題なら、返送されたエラーも残してから認証設定へ進みます。
変更前に、送信元・DNS管理先・既存の値を確認する
| 確認するもの | 確認のポイント |
|---|---|
| 送信元 | メールソフトやWordPressが、mixhostのSMTPを使っているか。外部のSMTPや配信APIなら、そのサービスの認証設定が確認先です。 |
| DNS管理先 | メールドメインの現在のネームサーバーを確認します。ドメインの購入先やWordPressの設置先だけでは決まりません。 |
| 既存の値 | 現在のSPF・DKIM・DMARCと、同じFromドメインを使う送信サービスを控えます。変更前の状態を残してください。 |

フォーム通知だけ届かない場合は、Contact Form 7の送信元・返信先・SMTPの確認手順を先に見ると、どこから送っているかを切り分けられます。WordPressがmixhost上にあるだけで、mixhostからの送信とは断定できません。
SPF・DKIMの自動設定には対象がある
mixhost公式のSPF・DKIM説明では、プライマリドメインやアドオンドメインとして追加したドメインは、SPFとDKIMが自動設定されると案内されています。これは、外部DNSへの公開や別サービスからの送信まで保証する説明ではありません。
- cPanelへログインし、「ドメイン」内の「ゾーンエディタ」を開く。
- メールに使う対象ドメインの「管理」を開き、TXTレコードの現在値を確認する。
- SPFはv=spf1、DKIMはv=DKIM1などを手がかりに、対象ドメインの公式設定値と照合する。DKIMのレコード名・セレクタも確認する。
- 現在のネームサーバーが他社なら、そのDNS管理画面で同じ公開用レコードが正しく登録されているか確認する。
サーバーやドメインごとの値を確認し、別の記事の値をそのまま貼り付けないでください。同じ名前にv=spf1で始まるSPFレコードを複数作ると認証エラーの原因になります。既存の外部配信サービスの許可も消さず、一つのSPFレコードとして見直します。SPFの仕様(RFC 7208)でも複数のSPFレコードはエラーとされています。
外部DNSと、外部メールサービスは別の分岐
外部DNSを使う場合、mixhost側で設定を保存しても、実際に参照される他社DNSへ自動反映されるとは限りません。cPanel公式のメール認証説明も、別のネームサーバーを使う場合は、その管理先でSPF・DKIM・DMARCを公開するよう案内しています。DNSへ登録するのは公開用の値で、DKIMの秘密鍵ではありません。
mixhostの外部ネームサーバーに関する案内では、外部DNSは動作保証の対象外です。ただし、未着の確認だけを理由にネームサーバーを変更すると、Webサイトや他のメール設定にも影響します。まず現在の管理先と公開値を調べてください。
一方、Google Workspaceなどへメール機能自体を移した場合は、そのサービスのSMTP接続や認証設定を確認します。mixhost内にも受信先ドメインがあり、同じ独自ドメイン宛てのメールが外部の受信先へ届かず内部配送される場合は、外部メールサーバー利用時の公式FAQのメールルーティング設定が確認候補になります。外部DNSを使うだけの人へ、この変更を一律に適用しません。
DMARCは既存設定を確認してから、必要な場合だけ追加する
DMARCは、Fromドメインとの整合を含めて認証を判定し、失敗したメールの扱いを受信側へ求める仕組みです。SPFまたはDKIMの少なくとも一方が成功し、その認証済みドメインがFromと整合していることが必要です。SPFかDKIMの片方が失敗しただけで、DMARC失敗とは限りません。
追加前に、対象ドメインの_dmarcにあるTXTレコードを調べます。すでにDMARCがあれば二つ目を作らず、現行の値と必要な差分を確認してください。サブドメインは上位ドメインの方針が適用される場合もあるため、直接のレコードが見当たらないだけで未設定と決めません。根拠はDMARCの仕様(RFC 7489)で確認できます。
未設定で、mixhost側が実際のDNS管理先である場合の入口は、mixhost公式のDMARC手順に沿って次の順になります。他社DNSの場合は、実際の管理先で必要なレコードを登録します。
- cPanelの「ドメイン」→「ゾーンエディタ」を開く。
- 対象ドメインの「管理」を選ぶ。
- 「+ 記録を追加」の横の▼から「DMARC」記録を追加する項目を選ぶ。
- ポリシーと必要な項目を、以下の考え方に沿って入力する。
- 「記録を保存」を押し、画面を開き直して値を確認する。
- 公開DNSの値と、普段使う送信経路の認証結果を確認する。保存完了だけで解決とは判断しない。
ポリシーは、正規メールを確認して段階的に強める
| 確認するもの | 確認のポイント |
|---|---|
| none | DMARCを理由とした隔離・拒否を求めません。迷惑メール判定を避けたり、受信箱への配信を保証したりする設定ではありません。 |
| quarantine | DMARCに失敗したメールを迷惑メール扱いなどにするよう、受信側へ求めます。 |
| reject | DMARCに失敗したメールの受信拒否を求めます。最終的な処理は受信側の判断にもよります。 |
初めて導入する場合は、同じFromを使う正規の送信経路を洗い出し、SPF・DKIMとFromの整合を確認したうえで、noneと集計レポート受信から観測を始めます。正規メールの失敗を直してから、隔離・拒否へ段階的に進めます。GoogleのDMARC導入手順もこの順序を案内しています。
すでにquarantineやrejectで運用しているドメインは、この記事に合わせてnoneへ戻す必要はありません。既存の方針を保ち、失敗する経路と運用への影響を確認してから変更を判断します。
アラインメントとレポート欄の読み方
mixhost公式で初期値とされるRelaxedは、単に文字列の一部が似ていればよいという意味ではありません。Fromと認証済みドメインの「組織ドメイン」が同じかを見ます。例えばexample.comとnews.example.comは整合し得ますが、example.comとexample.netは別です。Strictはドメインの完全一致を求めます。
SPFでは通常MAIL FROMのドメイン、DKIMでは署名のd=のドメインをFromと照合します。SPFやDKIM自体の認証成功も必要です。GoogleのDMARC設定・アラインメント説明を確認し、名前を似せるだけの修正をしないでください。
| 確認するもの | 確認のポイント |
|---|---|
| rua | 集計レポートの受信先です。受信可能な専用宛先を用意します。別ドメインの宛先なら、宛先側DNSの承認も必要になります。 |
| ruf | 個別の認証失敗レポートの宛先です。Gmailはrufに対応していないため、Gmailの診断目的で入力を必須にしません。 |
| 割合(pct) | 公式画面の案内は初期値100、入力範囲1〜100。隔離・拒否などを段階適用する割合で、認証成功率や配信成功率ではありません。 |
| 間隔(ri) | 公式の初期値は86400秒です。集計レポートを求める間隔であり、24時間以内の到着や全受信事業者からの送信を保証しません。 |
Optional Parametersの欄は必要に応じて設定します。公式にはfo=d/fo=sを指定する際の「生」タブも案内されていますが、Gmail向けの初期設定として一律に追加する項目ではありません。レポートの仕組みはGoogleのDMARCレポート説明も参照してください。
Gmailの受信結果を、経路ごとに記録する
自分で管理するGmailへ、普段使うメールソフト・フォーム・配信サービスからそれぞれ確認用メールを送ります。受信できたメールは「メッセージのソースを表示」で、Gmailが付けた認証結果を確認します。
| 確認するもの | 確認のポイント |
|---|---|
| SPF・DKIM | pass/fail/noneなどの結果と、認証対象ドメインを記録します。DKIM署名が存在するだけでは成功と判断できません。 |
| DMARC | Fromとの整合を含む結果を確認します。認証が通っても、送信者本人や本文の安全性まで証明されるわけではありません。 |
| 受信状態 | 送信日時、使った経路、受信箱・迷惑メール・未着を記録します。認証成功と到達は別です。 |
メール自体が届かなければ、Gmail側でそのメールのソースを開くことはできません。返送メールのエラー番号、送信サービスの配信ログ、日時と宛先を控えて、送信失敗なのか受信側の拒否なのかを切り分けます。認証以外の共通要件はWordPressでGmail送信者ガイドラインを確認する記事も参照してください。
解決しないときに、DNS初期化を最初の手段にしない
mixhost公式は規定値以外への変更をサポート対象外としています。ただし、DNS全体の初期化は、外部サービス用のメールやWebサイトの設定にも影響し得ます。現在値と利用サービスを残し、誤っている項目を特定して必要な差分を確認してください。判断できない場合は、その記録を添えてサポートへ相談します。
送信サーバーがさくらのレンタルサーバだった場合は、さくらのネームサーバー・ログイン方法・認証の確認手順へ進んでください。各社の管理画面や署名対象の条件を、別サービスへそのまま当てはめないことが大切です。
Opsoryの見解:自動設定を出発点に、現在の状態を確かめる
mixhostで確認を始める順序は、送信元を特定する、実際のDNS管理先を見る、既存の認証値を控える、必要な差分だけ変更する、普段の経路で結果を確かめる、です。これなら自動設定の問題と、外部DNS・外部送信サービスの問題を分けて調べられます。
DMARCの追加やサーバーの乗り換えだけでGmailへの到達が保証されるわけではありません。現在の構成を維持しながら原因を絞り、変更ごとに結果を残すことを勧めます。
広告:サービス仕様や申込み条件を確認したい場合は、次の公式サービス案内を参照できます。
mixhost
コメント