SPF設定ガイド

SendGridのSPF・DKIM・DMARC設定。

SendGrid（現Twilio SendGrid）は、共有のSPFの行を貼り付ける方式ではなく、Sender Authenticationウィザードでドメインを認証します。推奨の「Authenticate Your Domain」フローでは、専用の送信用サブドメインに3つのCNAMEレコードが生成され、SPFと、ローテーションされるDKIM鍵の管理をSendGridに委任します。これらのレコードの確認が完了すると、SendGridから自社ドメイン名義で送信できるようになり、「via sendgrid.net」の表示も消えます。その後、基盤となるSPF/IPの値を触る必要は一切ありません。

CNAMEによるドメイン認証

Your DNSAdd the CNAME / TXT records

SendGridSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

SendGridを認証すべき理由

SendGridでのドメイン認証は形式的な作業ではなく、メールが受信トレイに届くかどうかそのものを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、要件を満たさないメールの拒否を始めました。認証するまで、SendGridは独自の共有ドメインで送信します。受信者には「via sendgrid.net」という表示が見え、Fromアドレスのアライメントは一致せず、DMARCにも成功できません。レピュテーションも、同じ基盤を使う他の未認証の送信者全体とまとめて扱われます。ドメイン認証を行えば、これらをすべて一度に解決できます。SPFとDKIMのアライメントがどちらも自社ドメインと一致し、「via」の表示が消え、DMARCにも成功するようになり、築いた送信レピュテーションは共有プールではなく自社ドメインに蓄積されます。

SendGridにおけるSPFの実情

SendGridはCNAMEで認証するサービスのため、ほとんどの場合、追加すべき「include:sendgrid.net」はありません。Automated Securityをオン（デフォルト）のままAuthenticate Your Domainを実行すると、SendGridはブランド化された送信用サブドメイン（例：em1234.yourdomain.com）を、sendgrid.netを指すCNAMEとして作成します。このサブドメインがReturn-Path/バウンス用ドメインになります。その解決先はSendGrid自身のSPFで許可された範囲なので、そこでSPFの条件が自動的に満たされます。ルートドメインにinclude:sendgrid.netを公開する必要はなく、DMARCにも緩和されたSPFアライメントで成功します（emサブドメインのアライメントは組織ドメインと一致します）。古典的な共有includeが関係するのは、従来方式の手順の場合だけです。Automated Securityをオフにすると、SendGridは代わりにTXTレコードを提示するため、その場合にv=spf1 include:sendgrid.net ~allを追加します。まとめると、現在推奨されるSendGridの設定は、共有のSPFのincludeを使わないCNAMEドメイン認証です。include:sendgrid.netのメカニズムも残っていますが、手動で行う古い代替手段です。

2つの設定方法

推奨

Automated Security：CNAME（推奨）

CNAME経由で、SendGridがSPFの管理とDKIM鍵の自動ローテーションを行います
ルートドメインのSPFレコードのDNSルックアップを1回も消費せず、まとめる作業もありません
鍵は自動でローテーションされ、DNSを編集し直す必要はありません
専用IPやインフラの変更もSendGrid側で処理されます

従来方式

手動のinclude:sendgrid.net（従来方式）

ルートドメインのSPFレコードにv=spf1 include:sendgrid.net ~allを自分で追加します
SPFの10回のDNSルックアップのうち1回を消費します
DKIMは静的なTXTレコードになり、鍵の自動ローテーションはありません
自分で管理する静的なレコードが特に必要な場合にのみ、選ぶ価値があります

設定手順

SendGridで

1
Sender Authenticationを開く
app.sendgrid.comにログインし、左側のメニューからSettings → Sender Authenticationを開きます。
2
ドメイン認証を開始
Domain Authenticationセクション（「Authenticate Your Domain」）で、Get Startedをクリックします。
3
DNSホストを選択
「Which DNS host do you use?」のドロップダウンからDNSホスト（Cloudflare、GoDaddy、Namecheapなど）を選びます。これは画面上の手順を調整するだけのものです。一覧にない場合は「Other Host / Not Listed」を選んでください。
4
リンクをブランド化
「Would you also like to brand the links for this domain?」という質問にはYesと答えます。これで、クリック計測付きのリンクにsendgrid.netではなく自社ドメインが使われます（CNAMEがさらに2つほど増えます）。
5
Automated Securityをオンのままにする
Advanced Settingsを開き、「Use automated security」のチェックを入れたままにします。これでSendGridが、SPFの管理とDKIMのローテーションをCNAME経由で行うため、DNSを編集し直す必要がなくなります。カスタムの送信用サブドメインも任意で設定できます。設定しない場合は、SendGridがem1234のようなサブドメインを割り当てます。
6
送信ドメインを入力
「Domain You Send From」にyourdomain.comを入力し（SendGridはここから送信用サブドメインを導き出します）、Nextをクリックします。

DNSホストで

7
CNAMEレコードを追加
追加すべきレコードがSendGridの画面に表示されます。それぞれCNAMEとして作成します。ホストはSendGridが示すサブドメイン（em1234、s1._domainkey、s2._domainkey、有効にした場合はurl/リンクブランド用のホスト）、値は対応する*.sendgrid.netのホスト名です。タイプをAやTXTに変更しないでください。
8
Cloudflareのプロキシをオフにする
DNSがCloudflareの配下にある場合は、各レコードを「DNS only」（グレーのクラウド）に設定します。オレンジのクラウドのプロキシはCNAMEの解決を妨げ、確認に失敗します。

確認

9
Verifyをクリック
SendGridのSender Authenticationページに戻り、Verifyをクリックします。DNSの反映は通常数分ですが、最大48時間かかることがあります。すべてのCNAMEが解決されると、ドメインにVerifiedと表示されます。
10
認証済みドメインから送信
アプリまたはSMTPの設定で、認証済みドメインのアドレス（例：no-reply@yourdomain.com）から送信するようにします。これで、メールが実際に認証済みの送信用サブドメインを使うようになります。

追加するレコード

正確な値はSendGridのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

タイプ	ホスト	値
CNAME	em1234	u1234567.wl123.sendgrid.net送信用サブドメイン（Return-Path）：これによってSPFの条件が満たされます
CNAME	s1._domainkey	s1.domainkey.u1234567.wl123.sendgrid.netDKIM鍵1（自動ローテーション）
CNAME	s2._domainkey	s2.domainkey.u1234567.wl123.sendgrid.netDKIM鍵2（自動ローテーション）
CNAME	url1234	sendgrid.netリンクのブランド化（任意）
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCポリシー：1つのドメインにつき1つ

ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。SendGridの設定がこの上限のうち何回を消費するかは、次のとおりです。

SPF 10-lookup budget0 used · 10 free

SendGridの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。

DKIM

DKIMは、SendGridが作成するCNAMEレコードのうち2つで自動的に処理されます。s1._domainkey.yourdomain.comはs1.domainkey.uXXXXXX.wlYYY.sendgrid.netを、s2._domainkey.yourdomain.comはs2.domainkey.uXXXXXX.wlYYY.sendgrid.netをそれぞれ指します（uXXXXXX/wlYYYの部分はアカウントごとに固有です）。これらは貼り付けるTXTレコードではなく、SendGridに委任されたCNAMEです。そのためSendGridが秘密鍵を保持し、DNSを編集し直さなくても、2つのセレクターの裏で公開中のDKIM鍵をローテーションできます。DKIMのTXTレコードを自分で作成する必要はなく、コピーする鍵もありません。s1._domainkey / s2._domainkeyの2つのCNAMEを表示どおりに追加し、Cloudflareの場合は「DNS only」（グレーのクラウド）に設定して、Verifyをクリックするだけです。

DMARC

DMARCは、ルートドメインに設定する別のポリシーレコードです。SendGridのフローでも追加を促されますが、CNAMEレコードの1つではありません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを公開します。p=noneは監視のみのため、SendGridのメールがSPFとDKIMに成功し、アライメントが自社ドメインと一致しているかを確認する間も、配信には影響しません。1～2週間、集計レポート（rua）を確認し、アライメントが安定したらp=quarantine、最終的にp=rejectへと段階的に引き上げます。使う送信元の数にかかわらず、_dmarcレコードはドメイン全体で1つだけにしてください。SendGrid用に2つ目を追加してはいけません。

正しく設定できたか確認する

ダッシュボードの「Verified」バッジだけで判断せず、実際のメールで確認してください。認証済みドメインのアドレスから自分宛てにテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASS、DKIM: PASSのどちらにも自社ドメイン（sendgrid.netではなく）が表示され、DMARC: PASSと表示されていれば成功です。レポートで確認したい場合は、check-auth@verifier.port25.comにテストメールを送ると、詳しい内訳がメールで返ってきます。Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決されることを確認することもできます。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。SendGridが、アライメントが一致し、認証に成功している送信元として表示されるはずです。

ドメイン診断 DMARCレポート解析

よくある注意点

DNS設定
Cloudflareのプロキシで動作しなくなります。SendGridのCNAMEはすべて「DNS only」（グレーのクラウド）に設定してください。プロキシが有効なオレンジのクラウドのCNAMEはsendgrid.netに解決されず、確認に失敗します。
DNS設定
ホスト欄の二重化：多くのレジストラはドメインを自動で付け足すため、em1234.yourdomain.comと入力するとem1234.yourdomain.com.yourdomain.comになります。管理画面がドメインを付け足す場合は、サブドメインのラベルのみ（em1234、s1._domainkey、s2._domainkey）を入力してください。
適用範囲
Single Sender Verificationはドメイン認証ではありません。1つのアドレスから送信できるようになるだけで、「via sendgrid.net」は表示されたままで、SPF/DKIMのアライメントも一致しません。必ずAuthenticate Your Domainを実行してください。
DNS設定
CNAME（Automated Security）の設定を使っている場合は、ルートドメインのSPFレコードに余分なinclude:sendgrid.netを追加しないでください。不要なうえ、SPFのルックアップを1回無駄に消費します。
DNS設定
SPFのDNSルックアップの10回制限（RFC 7208）：ルートドメインのSPFレコード内のinclude:はすべて、DNSルックアップ10回という厳格な上限の対象になります。SendGridのCNAME方式はルートドメインのSPFレコードのルックアップを1回も消費しません。Google、Microsoft、Mailchimpなどをすでに併用している場合は、これが大きな利点になります。
認証失敗の原因
ルートドメインのSPFのTXTレコードは1つだけにしてください。他のサービスからも送信する場合は、2つ目のSPFのTXTレコードを公開せず、そのメカニズムを1つのv=spf1レコードにまとめます（SPFレコードが2つあると、それ自体がPermErrorになります）。

SPFレコードを作成

SendGridでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。

送信元

メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。

上の検索欄で利用中のメールサービスを検索するか、してください。

このドメイン自身のサーバー

ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。

a（ドメイン自身のAレコード）mx（ドメインのMXホスト）

その他の送信元・IP

リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。

追加のinclude

接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。

IPv4アドレス

IPv6アドレス

その他すべての送信元へのポリシー

上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。

-all (fail)厳格：記載されていないサーバーからのメールを拒否するよう受信側に求めます。~all (softfail)推奨の初期設定：記載されていない送信元のメールは受け付けられますが、疑わしいものとして扱われます。?all (neutral)判定なし：保護効果はほとんどありません。テスト中のみ使用してください。

生成されたSPFレコードDNSルックアップ0/10回

v=spf1 ~all

送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。

ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。

送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。

リストを検証

SendGridのSPFに関するよくある質問

推奨の設定では不要です。Automated Securityがオンの場合、SendGridは送信用サブドメインのemのCNAMEを通じてSPFを認証するため、ルートドメインのSPFレコードはそのままで構いません。v=spf1 include:sendgrid.net ~allを追加するのは、意図的にAutomated SecurityをオフにしてTXTレコードの手動手順を使う場合だけです。

ドメイン認証ではなく、確認済みのSingle Senderだけを使っている状態です。Settings → Sender Authentication → Authenticate Your Domainを実行してCNAMEを追加してください。ドメインの確認が完了すると、via/on-behalf-ofの表示は消えます。

SendGridは常に送信用/Return-Pathのサブドメインを用意します（それがemのCNAMEです）。表示されるFromアドレスはyou@yourdomain.comのままで構いません。緩和されたSPFアライメントでemサブドメインが組織ドメインと一致するため、DMARCにも成功します。

いいえ。SendGridは独自のサブドメインのCNAMEと独自のs1/s2のDKIMセレクターを使うため、既存のDKIMやルートドメインのSPFレコードを上書きしません。ルールは1つだけです。ルートドメインのSPFのTXTレコードは1つにして、2つ公開しないでください。

Automated Securityがオンなら不要です。CNAMEの裏にあるSPF/IPはSendGridが更新します。手動の手順（Automated Securityがオフ）の場合は、専用IPをip4:メカニズムとして、SPFのTXTレコードに自分で追加する必要があるかもしれません。

CNAMEです。ドメイン認証のレコード（em、s1._domainkey、s2._domainkey、リンクブランド用のホスト）はすべてCNAMEです。TXTレコードなのはDMARCレコードだけで、これは別のレコードです。

SPF・DKIM・DMARCの解説3つのレコードが連携してメールを認証する仕組みを解説します。DMARCの設定手順メールを止めずに、p=noneの監視からポリシー適用へ進めます。GoogleとYahooの送信者ガイドラインSendGridのメールが満たすべき2024年の大量送信者向け要件です。DMARCレポートの読み方SendGridが、アライメントが一致し、認証に成功している送信元として表示されるか確認します。Cloudflareでこれらのレコードを追加DNSホストでCNAMEを公開する手順を解説します。

トランザクションメール・APIの他のサービス

すべてのSPFガイド

SendGridのSPF、DKIM、DMARCを毎日監視レコードの設定は、最初の一歩にすぎません。ドメイン診断の監視は、SPFのルックアップ数、DKIMキー、DMARCポリシーを毎日再チェックし、どれかが壊れたときにメールでお知らせします。ドメイン診断の監視を見る SPFのDNSルックアップが多すぎる場合：数え方とpermerrorの直し方

SendGrid連携QualisendのSendGrid連携で、SendGridアカウント内のメールアドレスを検証できます。

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。

認証の次は、リストをクリーンに保つ

SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。

検証を始める

SendGridの​SPF・DKIM・DMARC設定。