SendGridのSPF/DKIM設定ガイド（CNAME方式）
目次
この記事でわかること
- SendGridの「Domain Authentication」がなぜCNAME方式なのか
- 旧来の
include:sendgrid.net方式との違いと、いま選ぶべき構成 - Single Sender VerificationとDomain Authenticationの使い分け
- Mailchimp / HubSpot等の他配信サービスを併用するときのSPF設計
SendGridでGmailに届かない原因はだいたい認証不足
SendGridを契約しただけでは、自社ドメインからの送信はメール認証されません。デフォルトでは送信元の見え方が bounces.sendgrid.net などの共有ドメインのままで、Gmail / Yahoo / Microsoftの送信者要件を満たせず迷惑メール判定されやすくなります。
ここで必要になるのがDomain Authentication（旧称: Sender Authentication / Whitelabel）。SendGrid公式が推奨するのはSPF includeではなく、CNAMEを3〜5本追加するCNAME方式です。最新の管理画面操作は公式マニュアルをご確認ください。
CNAME方式とSPF include方式の違い
「とりあえずSPFに include:sendgrid.net を足せばよいのでは」という質問をよく受けますが、結論として新規構築でこの方式は選ばないでください。理由は3つです。
- SPF lookup を消費する: includeを足すと10ルックアップ上限に近づき、他SaaSを併用したときに
permerrorを起こします - DKIMが別管理になる: includeだけではDKIMは設定されず、署名なしの送信はDMARCで弾かれます
- Return-Pathが共有ドメインのまま: DMARCのSPFアライメントが成立せず、DKIMが正しくてもDMARC評価が
passにならないケースがあります
CNAME方式にすると、Return-Pathが em1234.example.jp のような自社サブドメインになり、SPFチェーンも自動追従します。鍵ローテーションもSendGrid側で行われるため、運用負荷が下がります。SPFのlookup上限の詳細はSPFフラットニング解説を参照してください。
Domain Authenticationで追加されるDNSレコード
CNAME方式で実際に追加するレコードは次の通りです。
ポイントはDMARCはSendGridが自動で追加しないこと。Domain Authenticationを完了しても、_dmarc のTXTレコードは自分でDNSに書く必要があります。最初は v=DMARC1; p=none; rua=mailto:[email protected] から開始し、レポートを2〜4週間収集してから段階的に quarantine → reject に強化します（詳細はDMARC設定ガイド）。
サブドメイン（例: mail.example.jp）でDomain Authenticationを設定するか、ルートドメインにするかも選択肢になります。同じ親ドメインから別の手段（Google Workspace等）でも送る場合は、サブドメイン分離のほうがDMARCアライメント設計が楽になります。
Single Sender VerificationとDomain Authenticationの使い分け
SendGridには軽量な認証としてSingle Sender Verificationもありますが、これは「特定の送信元アドレス1件だけ」をSendGridが許可するもので、DNS認証ではありません。Gmail / Yahooの2024年要件以降、Single Senderだけで運用されているドメインは到達率が大きく落ちる傾向があります。
| 用途 | 推奨方式 |
|---|---|
| プロダクション運用（顧客への通知・トランザクション・マーケ配信） | Domain Authentication |
| 評価フェーズで動作確認だけしたい | Single Sender Verification（暫定） |
| 1日5,000通超の配信予定がある | Domain Authentication 必須 |
5,000通基準の根拠はGmail要件のチェック観点で詳しく解説しています。
他のSaaSと併用する場合のSPF設計
実務では「SendGridでトランザクション送信、Mailchimpでメルマガ、Google Workspaceで人間が送る」のように複数サービスが同居します。CNAME方式のSendGridを採用していれば、SPFにはSendGrid分のincludeを追加する必要はありません（CNAME経由でSPFチェーンが委譲されるため）。
ただし他のサービスがSPF includeを要求する場合があります。代表例:
- Mailchimp: 詳細はMailchimpのDKIM設定ガイド
- HubSpot: include方式が中心になる場合があり、別途設計が必要（HubSpotのメール認証）
- Google Workspace:
include:_spf.google.com
複数のSaaSが混ざるとSPF lookup上限10個に到達しやすいため、「CNAME方式で済むサービスはCNAMEで吸収し、SPFには本当に必要なincludeだけ並べる」設計が結果的に長持ちします。
設定後の検証
DNS反映後は外部から実値を確認します。具体的なコマンドや確認ポイントはSPFレコード設定ガイドとDKIM設定 確認方法にまとめています。SendGridの管理画面側でも「Verified」表示が出ますが、DNS伝播タイムラグで管理画面とdig結果が食い違うことがあるため、両方を確認してください。
最終確認はGmail宛にテスト送信し、ヘッダの Authentication-Results で spf=pass dkim=pass dmarc=pass が揃うことを確認します。
まとめ
- SendGridはCNAME方式のDomain Authenticationが公式推奨
include:sendgrid.netの旧方式はSPF lookupを消費し他SaaSと衝突しやすい- Single Sender Verificationは暫定。プロダクションはDomain Authenticationを使う
- DMARCはSendGridが自動追加しないので自分で書く
- 他SaaSと併用するときはCNAMEで吸収できるものは吸収し、SPFは最小構成にする
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSLの状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。