Claude Media
ClaudeでSPF・DKIM・DMARCを確認する手順 — メルマガ送信前にGmail要件と照らす
Claudeチュートリアル

ClaudeでSPF・DKIM・DMARCを確認する手順 — メルマガ送信前にGmail要件と照らす

digの結果と受信メールのヘッダー原文をClaudeに渡し、SPF・DKIM・DMARCの通過状況とGmail送信者ガイドラインの要件を照らして、直す点を出す手順です。

読了目安 約13分

メルマガを配信する前に、送信ドメインの認証設定がGmailの要件を満たしているかを確かめたい。そんなときは、DNSの設定値と、自分宛てに送ったテストメールのヘッダー原文をClaudeに渡すと、どこが足りないかを要件ごとに読み分けてもらえます。

Claudeに渡すのは、お手元の端末で取った dig の出力とヘッダーの文字列です。ClaudeにDNSを引かせるのではなく、取ってきた結果を読ませる使い方です。この記事では、Gmailの送信者ガイドラインのどの要件がどの条件で効くかを先に整理し、材料の集め方、プロンプトの雛形、返ってきた指摘の裏取りまでを順に説明します。

1日5,000通を境に、求められる認証が変わる

Gmailの送信者ガイドラインは、2024年2月1日から、Gmailアカウント宛てに送るすべての送信者に要件を課しています。個人のGmailアカウントとは、@gmail.comまたは @googlemail.comで終わるアカウントです。1日に5,000通を超えて送る場合は、さらに厳しい要件が加わります。

要件全送信者1日5,000通超
SPFまたはDKIM全送信者どちらか一方1日5,000通超SPFとDKIMの両方
DMARC全送信者記載なし1日5,000通超設定が必要(ポリシーはnoneでもよい)
Fromのドメインの整合全送信者記載なし1日5,000通超SPFまたはDKIMのドメインと整合させる
ワンクリック配信停止全送信者記載なし1日5,000通超マーケティング・購読メールで必要
迷惑メール率全送信者Postmaster Toolsで0.3%未満1日5,000通超同左

このほか、全送信者に共通する要件として、送信ドメインまたはIPの正引き・逆引き(PTR)レコード、TLS接続、RFC 5322に沿ったメッセージ形式があります。他人のGmailのFromヘッダーを装わない、という要件もあります。

数千人規模の読者に送るメルマガなら、5,000通超の列を基準に確認しておくのが安全です。通数が少ないうちは「SPFまたはDKIM」で足りますが、リストが伸びて境目を越えたときに慌てて直すことになります。

手順の全体像

手順

送信前の認証チェックの流れ

  1. 1

    材料を集める

    送信ドメインのSPF・DMARCレコード、DKIMの公開鍵、テストメールのヘッダー原文を手元に揃えます。

  2. 2

    Claudeに要件表と一緒に渡す

    材料と、上の要件表に当たる条件を同じ会話に置き、通過・不通過と、直す点を表で出させます。

  3. 3

    指摘をDNSの現物と突き合わせる

    Claudeの読みが合っているかを、レコードの文字列で確かめます。

  4. 4

    直して再送し、もう一度読ませる

    直したら新しいテストメールを送り、ヘッダーを読み直させます。

材料を集める

Claudeに渡す材料は3種類です。コマンドは example.com を自分の送信ドメインに読み替えて実行します。

# SPF と DMARC(TXT レコード)
dig +short TXT example.com
dig +short TXT _dmarc.example.com
 
# DKIM の公開鍵(セレクタは配信サービスごとに異なる)
dig +short TXT selector1._domainkey.example.com

SPFのレコードは、ドメイン直下のTXTレコードのうち v=spf1 で始まるものです。DMARCのレコードは、_dmarc. を付けた名前のTXTレコードで、v=DMARC1 で始まります。

DKIMは、名前が セレクタ._domainkey.ドメイン の形になります。Google Workspaceの既定のセレクタは google なので、名前は google._domainkey です。メルマガ配信サービスを使っている場合、セレクタはサービスごとに違います。テストメールを自分宛てに送ると、ヘッダー原文の署名欄にセレクタが入っています。

ヘッダー原文は、受信側のメールソフトのメッセージ原文を表示する機能から取ります。本文は貼らず、ヘッダー部分(Received: から Authentication-Results:、DKIM-Signature:、List-Unsubscribe: までの行)だけを渡せば足ります。

ヘッダーの量が多いときは、テキストファイルに保存して添付できます。Claudeは、TXTファイルを含む複数の文書形式を読めます。1つの会話に添付できるのは20ファイルまでです。

Claudeに渡すプロンプトの雛形

要件の基準を毎回書き直さないよう、先に基準を貼り、その下に材料を置きます。次の雛形は、そのまま貼って使えます。

あなたはメール配信の認証設定を点検する担当です。
下の<requirements>を基準に、<dns>と<headers>を読み、
要件ごとに「通過」「不通過」「材料不足」のどれかを表で示してください。
材料にない事実は推測せず、「材料不足」とだけ書いてください。
 
<requirements>
全送信者: SPFまたはDKIM / PTR(正引き・逆引き)/ TLS / 迷惑メール率0.3%未満
1日5,000通超: SPFとDKIMの両方 / DMARC(ポリシーは none でも可)/
  FromのドメインがSPFまたはDKIMのドメインと整合 /
  ワンクリック配信停止(List-UnsubscribeとList-Unsubscribe-Post)
DKIM鍵は1024ビット以上(2048ビット推奨)
</requirements>
 
<dns>
(dig の出力を貼る)
</dns>
 
<headers>
(テストメールのヘッダー原文を貼る)
</headers>
 
最後に、直す点を優先度の高い順に3つまで、
具体的なレコードの書き換え案つきで示してください。

ポイントは「材料にない事実は推測せず『材料不足』とする」の一文です。貼られていない項目(たとえばPTRレコードや迷惑メール率)は、材料がない以上、判定できないからです。

返ってきた指摘を読むときの観点

出力が返ってきたら、次の観点で読み合わせます。

SPF

SPFレコードには、メールを送るすべての送信元を含める必要があります。配信サービスやフォームの通知メールなど、第三者の送信元がレコードに入っていないと、迷惑メールとして扱われやすくなります。

Googleの手順では、include: で送信元を並べ、末尾に ~all を付ける形が例示されています。たとえば次の形です。

v=spf1 include:_spf.google.com include:amazonses.com ~all

include: は10個までという記述もあります。配信サービスを足すたびに増えるので、Claudeが列挙した送信元の数を数えてもらい、10に近いかどうかを見ます。

DKIM

「SPFまたはDKIM」の要件を満たすだけなら片方で足りますが、5,000通超ではSPFとDKIMの両方が必要です。個人のGmailアカウントへ送るには、1024ビット以上のDKIM鍵が必要で、2048ビットが推奨されています。dig で取った公開鍵の長さは、Claudeに数えさせるより、鍵を発行した配信サービスの管理画面で確かめるほうが確実です。

DMARCと整合

DMARCは、SPFまたはDKIMのどちらかが通り、かつそのドメインがFromヘッダーのドメインと整合していて初めて通ります。SPFが通っていても、そのドメインがFromと別物なら、SPF側の整合は取れていません。

ここは一番読み違えやすい箇所です。配信サービスの既定の設定では、Return-Path(エンベロープの送信元)やDKIMの d= がサービス側のドメインになっていることがあります。ヘッダーの Authentication-Results: に spf=pass や dkim=pass と出ていても、どのドメインで通ったのかを見ないと、DMARCの整合は判断できません。プロンプトに「passと出たドメインがFromと一致しているかを、別の列に書く」と足すと、この点を拾いやすくなります。

DMARCのポリシーは、運用を始める段階では p=none から入り、レポートで状況を見ながら quarantine、reject へ上げていくのがGoogleの案内です。5,000通超の要件では none のままでも満たせます。レポートの宛先 rua は任意ですが、Googleは常に入れることを勧めています。

ワンクリック配信停止

5,000通超のマーケティング・購読メールでは、ワンクリック配信停止が必要です。ヘッダーに次の2行が入っているかを見ます。

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxx>

あわせて、本文に配信停止のリンクが見える形で入っている必要があります。配信サービスによっては設定画面に項目があるので、ヘッダーに無いときはサービス側の設定を先に見ます。

出力の形の例

雛形で頼むと、次のような表が返ってきます。以下は形を示すための例で、実際の出力はヘッダーの中身で変わります。

要件判定根拠
SPF判定通過根拠spf=pass。ドメインは bounce.example-esp.com
DKIM判定通過根拠dkim=pass、d=example.com
DMARC判定通過根拠DKIMのドメインがFromと一致
SPFの整合判定不通過根拠SPFが通ったドメインがFromと異なる
ワンクリック配信停止判定不通過根拠List-Unsubscribe-Post の行が無い
PTR・TLS判定材料不足根拠ヘッダーのみでは判断できない

この例では、DKIMの整合でDMARCを通っているので、SPFの整合が欠けていてもDMARCは通ります。それでも、配信サービス側でFromのドメインに揃えた送信元の設定ができるなら、揃えておくほうが片方が壊れたときの保険になります。

Claudeに任せず、人が確かめること

次の項目は、貼られた材料からは読み切れません。

  • DNSの現物: Claudeが書き換え案として出したレコードは、必ず自分で dig し直して、文字列を目で突き合わせます。TXTレコードの値は、ドメイン管理画面で自動的にドメイン名が補われる場合があります。Googleも、追加後にドメイン名の形式を確かめるよう案内しています。
  • PTRとTLS: 送信サーバーのIPアドレスに、正引きと逆引きが一致するPTRレコードが必要です。共用IPの配信サービスを使うなら、サービス側の責任範囲です。
  • 迷惑メール率: Postmaster Toolsで確認します。0.3%以上にならないようにし、0.10%未満を保つのが目安として示されています。
  • 開封率: Googleは開封率を追跡しておらず、第三者の開封率の正確さも検証できないと述べています。開封率が低くても、配信の問題とは限りません。

落とし穴

SPFのレコードを2つ作ってしまう

配信サービスを追加するたびに、新しいTXTレコードを足してしまうことがあります。SPFのレコードはドメインに1つにまとめ、include: を追記する形で更新します。Claudeに現在のレコードを渡し、「新しい送信元 include:xxx を足した完成形を1行で出して」と頼むと、書き換え案を作りやすくなります。

直したあとの再確認

DNSを書き換えたら、新しいテストメールを自分宛てに送り、ヘッダー原文を取り直します。同じ会話に新しい材料を貼り、「前回の不通過の項目が解消したか」を聞けば、変化だけを読ませられます。

毎回雛形を貼り直す手間は、Projectsに要件の基準と雛形を置いておくと省けます。送信ドメインが複数あるなら、ドメインごとにチャットを分けると、材料が混ざりません。

配信文面の作り方はメルマガの件名と本文のバリエーションの手順に、複数通を順に送る設計はステップメールの設計手順にあります。配信ツール側の連携はMailchimpとの連携で扱っています。ドメインのDNS自体をClaude Codeから操作する場合は、Hostinger MCPでドメインとDNSを管理する手順が参考になります。

まとめ

Gmail宛ての配信では、1日5,000通を超えるかどうかで、必要な認証が「SPFまたはDKIM」から「SPF・DKIM・DMARC」に変わります。Claudeは、digの出力とヘッダー原文を要件表と並べて読むのが得意で、材料不足の項目を「不明」と言わせれば、点検表として使えます。

ただし、DNSの現物、PTR、迷惑メール率は、貼られた材料からは分かりません。Claudeの指摘は、レコードの文字列と管理画面の値で裏を取ってから反映します。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →