広告運用2026.05.058分堀内宏之助

SPF/DKIM/DMARCのGmail全PASS設定方法

送信専用ドメインを XServer に登録し、UTAGE 配信用の DKIM CNAME と DMARC を設定して Gmail で 3 要素 PASS まで通した記録。最大の罠は既存 p=reject の処理と NS 切替のキャッシュ。

#メール配信#DKIM#DMARC#SPF#XServer#お名前.com

●78% が完読|1,247 views

📚 本記事は 4 本シリーズの第 4 回(最終回)です。
1. UTAGE API/MCPの実装制限と外部連携の現実解
2. Vercel/XServerのデプロイ先誤認を防ぐDNS確認手順
3. 診断ツールのタイプ判定アルゴリズム5つの落とし穴
4. (現在) //のGmail全PASS設定方法 ← この記事

5 月 5 日、午前 0 時 22 分。Gmail で開いたテストメールの「メッセージのソースを表示」を確認すると、3 行全て PASS の文字が並んでいました。

SPF:   PASS
DKIM:  'PASS' (Header From ドメインで署名)
DMARC: 'PASS'

ホスト名	種別	値	役割
(ドメイン)	NS	`ns1.xserver.jp` 〜 `ns5.xserver.jp`	XServer に DNS 委譲
(ドメイン)	A	XServer の IP	XServer 配下の IP アドレス
(ドメイン)	MX	(ドメイン)	XServer メール受信
(ドメイン)	TXT (SPF)	`v=spf1 +a:.xserver.jp +a: +mx include:spf.sender.xserver.jp ~all`	XServer 自動生成
`default._domainkey.<ドメイン>`	TXT	`v=DKIM1; k=rsa; p=...`	XServer 標準 DKIM(自社発信用)
`<セレクタ>._domainkey.<ドメイン>`	CNAME	`<セレクタ>.utage-dkim.com`	UTAGE 配信用 DKIM
`_dmarc.<ドメイン>`	TXT	`v=DMARC1; p=none;`	DMARC(段階引き上げ用に none で開始)

# 権威 DNS で直接確認(これが新しい値を返せば切替成功)
dig @ns1.xserver.jp +short A <ドメイン>

Step 3: ⚠️ 既存 DMARC `p=reject` の存在チェック(最大の罠)

NS 切替直後、何の気なしに dig を叩いて既存 DMARC を確認すると、衝撃の値が:

$ dig +short TXT _dmarc.<ドメイン>
"v=DMARC1; p=reject"

p=reject。最厳格設定が既に有効でした。これは DKIM/SPF アライメントが取れないメールを Gmail が完全拒否する設定です。DKIM の CNAME 反映前に UTAGE から配信したら、全メールが拒否されて配信ロスト する状況でした。

突破: NS 切替時に XServer 側の DMARC レコードを p=none で初期化し、DKIM 反映完了後に段階的に厳格化する方針に切替えました。

v=DMARC1; p=none;

p=none は「DKIM/SPF が失敗しても受信トレイに配送する(警告のみ)」設定で、観測フェーズに最適です。

💡 KEY TAKEAWAYS
NS 切替前に旧 DNS の DMARC を必ず確認してください。p=reject が残っていると、新 DKIM の反映遅延中に配信ロストが発生します。

Step 4: UTAGE 管理画面で DKIM 認証を発行

UTAGE 管理画面 → 「メール・LINE 配信」→「DKIM 認証設定」→「追加する」で送信元ドメインを入力すると、CNAME レコードが発行されます。

レコード名: <セレクタ>._domainkey.<ドメイン>
レコードタイプ: CNAME
値: <セレクタ>.utage-dkim.com

セレクタ部分は UTAGE 側がランダム発行するため、ドメインごとに異なります。

Step 5: XServer の DNS にレコード追加

XServer サーバーパネル → 「DNS 設定」→ ドメイン → 「DNSレコード追加」で 2 件登録します。

1) DKIM CNAME
   ホスト名: <セレクタ>._domainkey
   種別: CNAME
   内容: <セレクタ>.utage-dkim.com

2) DMARC TXT
   ホスト名: _dmarc
   種別: TXT
   内容: v=DMARC1; p=none;

⚠️ ホスト名欄に .<ドメイン> は 含めない(XServer が自動付与)。これを書き込むと壊れた FQDN になります。

送信ドメインの認証、御社は何段階目まで進んでいますか?

細マッチョ企業診断 / 3 分 8 問

診断する

反映確認 — XServer NS 直接問い合わせ

レコード追加後、ローカルリゾルバ経由だとキャッシュで古い情報が返ります。XServer NS に直接問い合わせると即座に確認できます。

# 全 NS で一致しているか
for ns in ns1 ns2 ns3 ns4 ns5; do
  echo -n "$ns: "
  dig @${ns}.xserver.jp +short TXT _dmarc.<ドメイン>
done

# UTAGE DKIM CNAME の最終 TXT(CNAME 追跡)
dig +short TXT <セレクタ>.utage-dkim.com
# → "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

UTAGE で送信元アドレス(設定済の 任意@<ドメイン>)のテストメールを作成
自分の Gmail 宛に送信
受信メールを開いて「︙」 → 「メッセージのソースを表示」

SPF:   PASS
DKIM:  'PASS' (ドメイン: <ドメイン>)
       header.s=<セレクタ>  ← UTAGE発行のセレクタで署名されている
DMARC: 'PASS'

フェーズ	TXT 値	タイミング
Phase 1(現在)	`v=DMARC1; p=none; rua=mailto:postmaster@<ドメイン>`	DKIM 追加と同時または直前
Phase 2(1 週間後)	`v=DMARC1; p=quarantine; pct=25;`	DKIM 安定稼働確認後
Phase 3(2-4 週後)	`v=DMARC1; p=quarantine;`	quarantine 100 % 適用
Phase 4(1 ヶ月後+)	`v=DMARC1; p=reject;`	元の厳格運用に戻す

# 全レコード一括確認
DOMAIN=<ドメイン>
SELECTOR=<UTAGE発行セレクタ>

echo "=== NS ===" && dig +short NS $DOMAIN
echo "=== A ===" && dig @ns1.xserver.jp +short A $DOMAIN
echo "=== MX ===" && dig @ns1.xserver.jp +short MX $DOMAIN
echo "=== SPF ===" && dig @ns1.xserver.jp +short TXT $DOMAIN
echo "=== DMARC ===" && dig @ns1.xserver.jp +short TXT _dmarc.$DOMAIN
echo "=== UTAGE DKIM (CNAME) ===" && dig @ns1.xserver.jp +short CNAME ${SELECTOR}._domainkey.$DOMAIN
echo "=== UTAGE DKIM (最終TXT) ===" && dig +short TXT ${SELECTOR}.utage-dkim.com
echo "=== XServer 標準 DKIM ===" && dig @ns1.xserver.jp +short TXT default._domainkey.$DOMAIN

:::

次のアクション

送信ドメインの認証整備度は、Web マーケ全体の 配信基盤レベル を映します。SPF だけ設定済み、DKIM は未対応、というケースは Gmail 2024 年ガイドラインで配信が止まりつつあります。

御社の配信基盤が「変化に対応できる細マッチョ体型」かどうか、5 軸スコアで見える化したい方は細マッチョ企業診断でセルフチェックしてみてください。骨格(基盤)スコアが、配信基盤を含めたデジタル体力の指標になります。

→ シリーズ目次に戻る: UTAGE API/MCPの実装制限と外部連携の現実解

— DIAGNOSIS

マーケ全体の集客力を 5 軸で診断したい方はこちら。

3 分 8 問で、御社の「変化対応力」を 5 軸スコア + 5 タイプで診断します。登録不要・無料・その場で結果が出ます。

細マッチョ企業診断を試す

よくあるご質問

Q1.SPF レコードは触らなくて良いのですか?

A.UTAGE は SPF をサービス側で対応済みのため、ユーザー側設定は不要です。UTAGE がメールの Envelope From に自社ドメインを使い、Header From だけがユーザードメインになる設計のためです。XServer 自動生成の SPF レコードのままで Gmail SPF=PASS になります。

Q2.DKIM の CNAME はどこに登録するのですか?

A.NS の配信元 DNS(本記事では XServer)側に登録します。UTAGE が CNAME のレコード名(例: xxxx._domainkey)と値(xxxx.utage-dkim.com)を発行するので、XServer サーバーパネルの DNS 設定で CNAME レコードとして追加します。XServer の標準 DKIM(default._domainkey)とは別建てで共存できます。

Q3.DMARC p=reject のまま DKIM 設定すると何が起きますか?

A.反映遅延中の数時間〜2 日間、Gmail で配信が全拒否される可能性があります。p=reject は DKIM/SPF アライメントが取れないメールを完全拒否する最厳格設定で、DKIM CNAME が伝播していない時間帯は危険です。最初に p=none へ一時緩和してから DKIM を追加し、安定確認後に段階引き上げる方針が安全です。

Q4.NS 切替後の DNS 反映時間はどれくらいですか?

A.権威 DNS 自体は即座に切り替わりますが、ローカルリゾルバのキャッシュが切れるまでクライアントによっては数時間〜最大 72 時間かかります。XServer NS で直接問い合わせる(dig @ns1.xserver.jp)とすぐに新しいレコードが返り、ローカル経由では 8.8.8.8 直問い合わせで早めに反映を確認できます。

Q5.DMARC p=none → quarantine → reject の段階引き上げ基準は?

A.1 週間 p=none で観測 → DMARC レポート(rua=)で正規メールが PASS している率を確認 → 95 % 以上なら quarantine に → さらに 2-4 週で 99 % 以上なら reject に、というのが標準フローです。レポート受信用にメールアカウント postmaster@ を作成しておくと観測しやすくなります。

Q6.なぜ送信ドメインを企業サイト本体と分けたのですか?

A.企業サイトとメール配信のリスクを分離する設計のためです。送信レピュテーション低下やスパム判定が企業サイトの SEO に影響しない構造になります。送信専用ドメインを別途用意し、企業サイトとは MX/A レコードで分離するのが定石です。

この施策を御社にも導入しませんか？

無料診断で、御社の状況に合った具体プランをご提案します。

無料診断を受ける

SPF/DKIM/DMARCのGmail全PASS設定方法

Step 3: ⚠️ 既存 DMARC `p=reject` の存在チェック(最大の罠)

Step 4: UTAGE 管理画面で DKIM 認証を発行

Step 5: XServer の DNS にレコード追加

反映確認 — XServer NS 直接問い合わせ

次のアクション

マーケ全体の集客力を 5 軸で診断したい方はこちら。

よくあるご質問

関連する記事

診断ツールのタイプ判定アルゴリズム5つの落とし穴

Vercel/XServerのデプロイ先誤認を防ぐDNS確認手順

EXBANK Insights 公式始動、私たちが書いていく7つの領域

UTAGE API/MCPの実装制限と外部連携の現実解

この施策を御社にも導入しませんか？

Step 3: ⚠️ 既存 DMARC p=reject の存在チェック(最大の罠)

Step 4: UTAGE 管理画面で DKIM 認証を発行

Step 5: XServer の DNS にレコード追加

反映確認 — XServer NS 直接問い合わせ

次のアクション

マーケ全体の集客力を 5 軸で診断したい方はこちら。

よくあるご質問

関連する記事

診断ツールのタイプ判定アルゴリズム5つの落とし穴

Vercel/XServerのデプロイ先誤認を防ぐDNS確認手順

EXBANK Insights 公式始動、私たちが書いていく7つの領域

UTAGE API/MCPの実装制限と外部連携の現実解

この施策を御社にも導入しませんか？

Step 3: ⚠️ 既存 DMARC `p=reject` の存在チェック(最大の罠)