## この記事でわかること

- SendGridの「Domain Authentication」がなぜCNAME方式なのか
- 旧来の `include:sendgrid.net` 方式との違いと、いま選ぶべき構成
- Single Sender VerificationとDomain Authenticationの使い分け
- Mailchimp / HubSpot等の他配信サービスを併用するときのSPF設計

## SendGridでGmailに届かない原因はだいたい認証不足

SendGridを契約しただけでは、自社ドメインからの送信はメール認証されません。デフォルトでは送信元の見え方が `bounces.sendgrid.net` などの共有ドメインのままで、Gmail / Yahoo / Microsoftの[送信者要件](/blog/google-sender-requirements-2024)を満たせず迷惑メール判定されやすくなります。

ここで必要になるのが**Domain Authentication（旧称: Sender Authentication / Whitelabel）**。SendGrid公式が推奨するのはSPF includeではなく、**CNAMEを3〜5本追加するCNAME方式**です。最新の管理画面操作は[公式マニュアル](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication)をご確認ください。

![SendGrid CNAME方式とSPF include方式の比較](/blog/sendgrid-email-auth/cname-vs-spf-include.svg)

## CNAME方式とSPF include方式の違い

「とりあえずSPFに `include:sendgrid.net` を足せばよいのでは」という質問をよく受けますが、結論として**新規構築でこの方式は選ばないでください**。理由は3つです。

1. **SPF lookup を消費する**: includeを足すと10ルックアップ上限に近づき、他SaaSを併用したときに `permerror` を起こします
2. **DKIMが別管理になる**: includeだけではDKIMは設定されず、署名なしの送信はDMARCで弾かれます
3. **Return-Pathが共有ドメインのまま**: DMARCのSPFアライメントが成立せず、DKIMが正しくてもDMARC評価が `pass` にならないケースがあります

CNAME方式にすると、Return-Pathが `em1234.example.jp` のような自社サブドメインになり、SPFチェーンも自動追従します。鍵ローテーションもSendGrid側で行われるため、運用負荷が下がります。SPFのlookup上限の詳細は[SPFフラットニング解説](/blog/spf-flattening)を参照してください。

### Domain Authenticationで追加されるDNSレコード

CNAME方式で実際に追加するレコードは次の通りです。

![SendGrid Domain Authenticationで追加されるDNSレコード](/blog/sendgrid-email-auth/dns-records.svg)

ポイントは**DMARCはSendGridが自動で追加しない**こと。Domain Authenticationを完了しても、`_dmarc` のTXTレコードは自分でDNSに書く必要があります。最初は `v=DMARC1; p=none; rua=mailto:postmaster@example.jp` から開始し、レポートを2〜4週間収集してから段階的に `quarantine` → `reject` に強化します（詳細は[DMARC設定ガイド](/blog/dmarc-setup-guide)）。

サブドメイン（例: `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要件のチェック観点](/blog/dmarc-5000-mails-check)で詳しく解説しています。

## 他のSaaSと併用する場合のSPF設計

実務では「SendGridでトランザクション送信、Mailchimpでメルマガ、Google Workspaceで人間が送る」のように複数サービスが同居します。CNAME方式のSendGridを採用していれば、SPFには**SendGrid分のincludeを追加する必要はありません**（CNAME経由でSPFチェーンが委譲されるため）。

ただし他のサービスがSPF includeを要求する場合があります。代表例:

- Mailchimp: 詳細は[MailchimpのDKIM設定ガイド](/blog/mailchimp-email-auth)
- HubSpot: include方式が中心になる場合があり、別途設計が必要（[HubSpotのメール認証](/blog/hubspot-email-auth)）
- Google Workspace: `include:_spf.google.com`

複数のSaaSが混ざるとSPF lookup上限10個に到達しやすいため、**「CNAME方式で済むサービスはCNAMEで吸収し、SPFには本当に必要なincludeだけ並べる」**設計が結果的に長持ちします。

### 設定後の検証

DNS反映後は外部から実値を確認します。具体的なコマンドや確認ポイントは[SPFレコード設定ガイド](/blog/spf-setup-guide)と[DKIM設定 確認方法](/blog/dkim-verification)にまとめています。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は最小構成にする

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSLの状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。