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

- さくらインターネットを「メールサーバー」として使うか「DNS だけ預ける」かで設定が変わる理由
- SPF・DKIM・DMARC それぞれで追加すべき DNS レコードの中身（type / name / value の指針）
- 既定の SPF と外部サービスの SPF が衝突したときの考え方と検証方法

## なぜ「さくら + メール認証」が混乱しやすいのか

「さくらでの SPF や DKIM の正解がわからない」という相談は、Gmail と Outlook の送信者要件強化以降に増えました。混乱の原因は、さくらには複数商品があり挙動が異なる点と、**メールを送る場所と DNS を管理する場所が一致するとは限らない**点の 2 つです。

「ドメインはお名前.com、DNS はさくら、メールは Google Workspace」という構成も珍しくありません。整理せず手順を検索すると、自分のケースに当てはまらない設定でメールが止まります。まず**送信経路と DNS 管理者を切り分けて図にする**ことから始めます。

![さくら：メール利用パターン 2 ルート判定](/blog/sakura-email-auth-setup/sakura-routing.svg)

## パターン A: さくらをメールサーバーとして使う場合

さくらのメールボックスやレンタルサーバーのメール機能を実際に送信元として使うケースです。問い合わせフォームの自動返信などがさくら側から出ていく構成を指します。SPF・DKIM・DMARC の 3 点を、さくら側のメールサーバーを許可する形で組みます。

### SPF レコード

SPF（エスピーエフ：送信元 IP を許可する仕組み）は、ドメインの apex に TXT レコードとして 1 件だけ追加します。

- **type**: TXT
- **name**: `@`（apex）
- **value の方針**: `v=spf1` で始め、さくら公式マニュアルが提示する include 文字列を 1 つだけ入れ、最後を `~all` または `-all` で締める

複数のメール送信元を併用する場合は、それぞれの include を 1 行に並べます。SPF レコードはドメインあたり 1 件しか持てないので、TXT を複数行作らないこと。**include の合計が 10 個を超えると Permerror になり、SPF 全体が無効になります**（RFC 7208）。

### DKIM レコード

DKIM（ディーキム：電子署名による改ざん検知）は、さくら側で秘密鍵と公開鍵を発行し、`<セレクタ>._domainkey.<ドメイン>` の TXT に公開鍵を入れる方式が一般的です。

- **type**: TXT
- **name**: `<セレクタ>._domainkey`（さくら側で発行される値）
- **value の方針**: `v=DKIM1; k=rsa; p=<公開鍵>`

セレクタ名と公開鍵は推測で書けません。**最新の管理画面操作と発行されるセレクタ名は、[さくらインターネットの公式マニュアル](https://help.sakura.ad.jp/)で確認**してください。さくらが DNS も預かっている構成では、DKIM 用 TXT が自動追加される設計になっている場合があります。

### DMARC レコード

DMARC（ディーマーク：SPF と DKIM の結果をどう扱うかのポリシー）は、`_dmarc.<ドメイン>` という名前の TXT レコードに 1 件だけ追加します。

- **type**: TXT
- **name**: `_dmarc`
- **value の方針**: 最初は `v=DMARC1; p=none; rua=mailto:dmarc@example.com` から始め、レポートを 2〜4 週間観察してから `quarantine` → `reject` と段階的に強化する

いきなり `p=reject` にすると、設定漏れの正規メールまで拒否されるリスクがあります。段階的強化のフローは[DMARC 設定ガイド](/blog/dmarc-setup-guide)で解説しています。

## パターン B: DNS だけさくらに預けて、メールは別サービスを使う場合

ネームサーバーはさくら、送信は Google Workspace や Microsoft 365、Resend、SendGrid などの外部サービスから行うケースです。**さくらは DNS の入れ物として使うだけ**で、SPF・DKIM は外部サービスが指定する値を転記します。

### 既定 SPF との衝突に注意

さくら側で「メール送信機能を使う」が ON のままだと、apex に `include:_spf.sakura.ne.jp` 系の SPF が既定で入っていることがあります。この状態で Google が指示する `include:_spf.google.com` を「別の TXT」として追加すると、SPF が 2 件並び、**全体が Permerror で無効化**します。受信側は DKIM がパスしない限り認証失敗扱いです。

正しい対応は次のいずれかです。

1. さくらの既定 SPF を 1 行に統合し、外部サービスの include を同じ TXT に並べる
2. さくらのメール送信機能を使っていないなら、既定 SPF をパネルから無効化したうえで外部サービスの SPF を追加する

![既定 SPF と外部サービス SPF の衝突パターン](/blog/sakura-email-auth-setup/spf-conflict.svg)

DKIM も同様で、外部サービスが提示するセレクタと公開鍵を、さくらの DNS 編集画面で TXT または CNAME として追加します。CNAME 方式なら、外部サービスの DKIM 鍵ローテーションに自動追従できる利点があります。

## 設定後の検証方法

DNS の伝搬は最大数時間。設定が反映されたかは次のいずれかで確認します。

- **dig**: `dig TXT example.com` / `dig TXT _dmarc.example.com` / `dig TXT <selector>._domainkey.example.com`
- **mxtoolbox**: SPF / DKIM / DMARC の各チェッカー
- **`/diagnose`**: ドメイン番人の[無料ドメイン診断](/diagnose)で一括チェック

実際に送って、Gmail / Outlook の「メッセージのソースを表示」で `Authentication-Results` ヘッダに `spf=pass`・`dkim=pass`・`dmarc=pass` が並ぶところまで確認すると安全です。

他社のホスティングを併用している場合、エックスサーバーは[Xserver の SPF/DKIM/DMARC 設定の進め方](/blog/xserver-email-auth-setup)を、SPF の基礎は[SPF レコード設定ガイド](/blog/spf-setup-guide)を参照してください。

### まとめ

- まず「送信元はどこか」「DNS 管理者は誰か」を切り分ける
- パターン A（さくらから送信）では、さくら発行の DKIM セレクタを使い、SPF と DMARC を DNS に追加
- パターン B（DNS だけ預ける）では、既定 SPF と外部 SPF が衝突しないよう 1 行に統合
- セレクタ名・公開鍵・include 文字列は推測せず公式マニュアルの値を使う

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

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