Klaviyoメール認証が通らない時の確認手順
目次
この記事でわかること
- Klaviyo で「Verify Domain」が緑にならない時の確認順序
- 設定したのに DMARC が fail する典型的な原因
- DNS レコードを 1 つずつ点検するチェックリスト
Klaviyo（クラビヨ。EC でよく使われるメール配信サービス）で独自ドメイン送信を設定したのに、「Verify Domain」が緑にならない、あるいは届いたメールが DMARC で fail している。本記事はこうした「設定したはずなのに通らない」状況の切り分けに絞った確認ガイドです。
独自ドメイン送信（Dedicated Sending Domain）の初期設定そのものの手順は Klaviyo の SPF・DKIM・DMARC 設定手順 にまとまっています。まだ設定していない方はそちらが先です。本記事は 設定後につまずいた人向け の点検手順としてお読みください。メール認証の前提となる DMARC の仕組みは DMARC とは？ を参照してください。
つまずきは大きく 3 か所で起きる
Klaviyo の認証トラブルは、原因が次の 3 か所のどれかに集中します。やみくもに再設定する前に、どこで止まっているかを切り分けるのが近道です。
- A. DNS レコードが Klaviyo に見えていない: Verify Domain が緑にならない段階。CNAME や TXT の入力ミス、反映待ちが原因。
- B. 認証は通るが DMARC でアラインメントが取れない: Verify は通ったのに、受信側で DMARC が fail する段階。return-path（戻り先アドレス）の設定漏れが典型。
- C. SPF レコードが壊れている: 既存の SPF と二重に書いた、または参照数が上限を超えた段階。
以下、A から順に点検します。
A. Verify Domain が緑にならない時
「Add a Sending Domain」で表示された DNS レコードを追加したのに緑にならない場合、次の順で確認します。
ホスト名を入れすぎていないか。 最も多い原因です。Klaviyo が kl1._domainkey.mail と表示している場合、Cloudflare やお名前.com などの管理画面では 末尾の .example.co.jp を付けない のが正解です。DNS 側が親ドメインを自動で補うため、kl1._domainkey.mail.example.co.jp と入力すると mail.example.co.jp が二重になって一致しません。
反映を待てているか。 DNS の変更が世界中に行き渡るには 5〜30 分かかります。設定直後に Verify を押して失敗しても、しばらく待ってから再度試します。dig コマンドや公開の DNS チェックサービスで、設定したレコードが返るか確認してから Verify を押すと無駄足が減ります。
CNAME を TXT で入れていないか。 Klaviyo が発行する DKIM（メールに署名して改ざんやなりすましを検知する仕組み）は CNAME 形式です。これを誤って TXT で登録すると検証に失敗します。レコードタイプが Klaviyo の指示どおりかを 1 件ずつ照合します。
B. Verify は通ったのに DMARC が fail する
ここが最も気づきにくい段階です。Klaviyo 上は「Verified」なのに、Gmail などに届いたメールのソースを見ると DMARC が fail している。これは多くの場合、 return-path（bounce 用 CNAME）の設定漏れ が原因です。
DMARC は「DKIM か SPF のどちらかが通り、かつ送信ドメインと表示上のドメインが揃っている（アラインメント）」ことを求めます。Klaviyo の 4 レコードのうち、return-path の CNAME（例: bounce.mail を Klaviyo 側へ向ける行）が抜けていると SPF のアラインメントが取れず、DKIM だけに依存することになります。DKIM 側に何か問題があると、その時点で DMARC 全体が fail します。
確認手順は次のとおりです。
- 自分宛に Klaviyo からテスト配信し、受信メールのヘッダ（または DMARC レポート）を開く
dkim=passとspf=passの両方が出ているかを見る- SPF 側が fail または none なら、return-path の CNAME が DNS に存在するかを点検する
アラインメントの考え方そのものは DMARC アラインメントの基礎 で詳しく解説しています。なお _dmarc.example.co.jp の DMARC はサブドメイン（mail.example.co.jp）にも自動で効くため、_dmarc.mail.example.co.jp を別途作る必要はありません。むしろ別途作ると意図しない上書きが起きます。
C. SPF が壊れていないか
Klaviyo を追加したあとに、別のメール送信もまとめて壊れた場合は SPF（許可した送信元を宣言するレコード）を疑います。
SPF を 2 行に分けていないか。 SPF はドメインごとに 1 行だけ が原則です。既存に v=spf1 include:_spf.google.com -all があるのに、Klaviyo 用にもう 1 行 v=spf1 ... を追加すると、ルール違反で両方とも無効化されます。1 行にまとめます。
v=spf1 include:_spf.google.com include:_spf.klaviyomail.com -all
include の参照数が 10 個を超えていないか。 Klaviyo に加えて Google Workspace、別の配信サービスなどを併用していると、SPF が内部で参照する数（DNS ルックアップ）が 10 個の上限を超え、認証全体が壊れることがあります。これは Klaviyo 固有ではなく SPF の仕様上の制限です。原因の特定と対処は SPF レコードの 10 ルックアップ問題と平坦化 を参照してください。
点検が終わったら段階強化へ
3 か所すべてが解消し、テスト配信で dkim=pass と spf=pass、DMARC が pass になれば、認証は正しく機能しています。ここまで来たら、DMARC ポリシーを p=none から p=quarantine、最終的に p=reject へと段階的に強化していきます。一気に reject にすると正規メールの誤拒否が起きるため、必ず段階を踏みます。進め方は DMARC ポリシーの段階的強化 にまとめています。
よくある質問
Verify Domain は緑なのに DMARC が fail します。なぜですか？
Klaviyo の Verify は DKIM と所有確認の成立を見ているだけで、受信側の DMARC 判定とは別物です。多くは return-path（bounce 用 CNAME）の設定漏れで SPF のアラインメントが取れていないケースです。本記事の「B」の手順で点検してください。
設定が反映されているか確認する方法は？
dig（または公開の DNS チェックサービス）で、Klaviyo が指示した CNAME・TXT が実際に返ってくるかを確認します。返ってこなければ DNS 側の入力ミスか反映待ちです。Klaviyo の Verify を連打しても解決しません。
サブドメインに DMARC を別途設定すべきですか？
不要です。_dmarc.example.co.jp の DMARC は組織ドメイン一致のルールにより mail.example.co.jp などのサブドメインにも自動適用されます。別途 _dmarc.mail.example.co.jp を作ると意図しない上書きの原因になります。
どうしても原因が特定できません。
DNS レコードの 1 文字違いやレコードタイプの取り違えは、目視では見つけにくいものです。自社で切り分けが難しい場合は、現状を診断したうえで設定支援をご利用ください。
まずは現状を把握しましょう
ドメイン番人の 無料ドメイン診断 なら、ドメインを入れるだけで SPF・DKIM・DMARC の設定状況を数十秒で確認できます。Klaviyo 切り替え後の検証にもそのまま使えます。
切り分けに迷う場合は お問い合わせ からご相談ください。専門家がわかりやすくサポートいたします。関連記事として Klaviyo の SPF・DKIM・DMARC 設定手順、Brevo のメール認証 も合わせてご覧ください。