📚 本記事は 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 切替・DKIM 追加・DMARC p=reject の罠への対処を含めて約 60 分かかりました(DNS 反映待ちの 30 分を除く)。本記事は、送信ドメイン認証を構造的に通すための 5 ステップの実装ログ です。

完成形 — 何をどこに配置したか

最終的に有効化された DNS レコードは以下です。

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

ポイントは XServer 標準の DKIM と UTAGE 用 DKIM が 別セレクタで共存 していることです。default._domainkey は XServer 自身の発信メール用、<セレクタ>._domainkey は UTAGE 経由の配信用で、それぞれ独立して機能します。

実装手順 — 5 ステップ

DKIM/DMARC設定の5ステップフロー
DKIM/DMARC設定の5ステップフロー

Step 1: XServer サーバーパネルでドメイン追加

XServer サーバーパネル → 「ドメイン」→「ドメイン設定」→「ドメイン設定追加」 でドメインを追加します。所要 5 分。

このタイミングで「無料独自 SSL を利用する」「X を有効にする」をチェックしておくと後の作業が楽になります(SSL は反映に 30-60 分かかります)。

Step 2: お名前.com で NS を XServer に切替

お名前.com Navi → ドメイン → 該当ドメインのネームサーバー設定 → 「その他のサービス」タブ → ns1〜ns5.xserver.jp を入力して保存。

切替直後の権威 DNS は即座に変わりますが、ローカルリゾルバのキャッシュが原因で dig +short A は古い IP を返し続けます。新 IP が確実に返っているかは XServer NS に直接問い合わせて確認します。

`bash

権威 DNS で直接確認(これが新しい値を返せば切替成功)


dig @ns1.xserver.jp +short A <ドメイン>
`

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

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

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

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

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

`text
v=DMARC1; p=none;
`

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

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

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

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

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

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

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

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

`text
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 に直接問い合わせると即座に確認できます。

``bash

全 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…"

`

5 つの NS 全てで同じ値が返れば、権威 DNS の伝播は完了しています。あとはクライアント側のリゾルバキャッシュが切れるのを待つだけ(通常数時間)です。

Gmail テスト — 3 要素 PASS の確認

UTAGE 管理画面の DKIM 認証ステータスが「完了」になったら、テスト配信を行います。

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

Authentication-Results ヘッダに以下が並んでいれば成功です。

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

特に重要なのは DKIM の header.s=<セレクタ> 部分です。これが UTAGE 発行のセレクタ で署名されていることを示し、Header From のドメインで DMARC アライメントが取れていることを意味します。

💡 KEY TAKEAWAYS
Gmail の「メッセージのソースを表示」は最後の真実です。UTAGE 管理画面で「完了」表示されていても、Gmail で PASS 確認できるまでが本当の完了です。

DMARC 段階引き上げ — 1 週間ごとの判断基準

p=none のまま運用すると認証失敗メールも受信トレイに届くため、なりすまし対策にはなりません。段階的に厳格化していきます。

DMARC段階引き上げのタイムライン
DMARC段階引き上げのタイムライン
フェーズ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;元の厳格運用に戻す

pct=25 は「失敗メールの 25 % だけ quarantine 適用」という段階的展開オプションです。いきなり 100 % にせず、影響を 1/4 に絞って観測できます。

rua=mailto: を追加しておくと、Gmail / Yahoo / Outlook から日次の DMARC 集計レポート(XML)が届きます。受信用メールサーバー(XServer メールアカウント postmaster@)を作成しておくと、レポートを自動受信できます。

落とし穴サマリ

このプロセスで踏みかけた落とし穴を 4 つ共有します。

落とし穴 1: SPF を「念のため」変更してしまう

UTAGE は SPF をサービス側で対応済みなのでユーザー側設定は不要ですが、「念のため include:_spf.utage-system.com を追加しておこう」と思うかもしれません。触らないでください。XServer 自動生成の SPF をそのまま使うのが正解です。

落とし穴 2: DKIM のホスト名にフルドメインを含める

XServer の DNS 設定画面では FQDN ではなくサブドメイン部分のみを入力します。フルドメインを書くと壊れたレコードになり、DKIM 認証が永遠に失敗します。

落とし穴 3: NS 切替直後にローカル dig で確認

NS 切替後にローカル経由で dig を叩くと、ローカルリゾルバのキャッシュで古い IP が返ります。「切替失敗?」と焦る前に dig @ns1.xserver.jp で権威 DNS に直接問い合わせて確認してください。

落とし穴 4: SSL 発行を忘れる

XServer のドメイン追加時に「無料独自 SSL」をチェックし忘れると、 で接続できないままになります。後から追加可能ですが、サーバーパネルで別途「SSL 設定追加」する手間が発生します。

検証用 dig コマンド集

`bash

全レコード一括確認


DOMAIN=<ドメイン>
SELECTOR=

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の実装制限と外部連携の現実解