---
title: "SPF、DKIM、DMARC：メール認証完全ガイド"
description: "SPF、DKIM、DMARC を徹底解説し、メール認証を使いこなすための包括的なガイドです。各プロトコルの役割、DNS レコードの設定方法、よくある問題のトラブルシューティング、到達率の改善方法を学べます。"
url: https://tajo.io/jp/blog/spf-dkim-dmarc-guide/
markdown: https://tajo.io/jp/blog/spf-dkim-dmarc-guide.md
lang: ja-JP
author: "Set Noa"
author_url: https://tajo.io/jp/set-noa/
published: 2026-03-08
updated: 2026-05-14
alternates: {en-US: /blog/spf-dkim-dmarc-guide.md, bg-BG: /bg/blog/spf-dkim-dmarc-guide.md, cs-CZ: /cz/blog/spf-dkim-dmarc-guide.md, de-DE: /de/blog/spf-dkim-dmarc-guide.md, da-DK: /dk/blog/spf-dkim-dmarc-guide.md, es-ES: /es/blog/spf-dkim-dmarc-guide.md, fr-FR: /fr/blog/spf-dkim-dmarc-guide.md, el-GR: /gr/blog/spf-dkim-dmarc-guide.md, hi-IN: /hi/blog/spf-dkim-dmarc-guide.md, id-ID: /in/blog/spf-dkim-dmarc-guide.md, hr-HR: /hr/blog/spf-dkim-dmarc-guide.md, it-IT: /it/blog/spf-dkim-dmarc-guide.md, ko-KR: /kr/blog/spf-dkim-dmarc-guide.md, ar-SA: /ar/blog/spf-dkim-dmarc-guide.md, nl-NL: /nl/blog/spf-dkim-dmarc-guide.md, pl-PL: /pl/blog/spf-dkim-dmarc-guide.md, ro-RO: /ro/blog/spf-dkim-dmarc-guide.md, ru-RU: /ru/blog/spf-dkim-dmarc-guide.md, sv-SE: /se/blog/spf-dkim-dmarc-guide.md, zh-CN: /zh-cn/blog/spf-dkim-dmarc-guide.md, sl-SI: /sl/blog/spf-dkim-dmarc-guide.md, sr-Latn-RS: /sr/blog/spf-dkim-dmarc-guide.md, th-TH: /th/blog/spf-dkim-dmarc-guide.md, tr-TR: /tr/blog/spf-dkim-dmarc-guide.md, ur-PK: /ur/blog/spf-dkim-dmarc-guide.md, vi-VN: /vi/blog/spf-dkim-dmarc-guide.md, sk-SK: /sk/blog/spf-dkim-dmarc-guide.md}
---

[メール](https://tajo.io/jp/blog/?category=email)

# SPF、DKIM、DMARC：メール認証完全ガイド

SPF、DKIM、DMARC を徹底解説し、メール認証を使いこなすための包括的なガイドです。各プロトコルの役割、DNS レコードの設定方法、よくある問題のトラブルシューティング、到達率の改善方法を学べます。

SPF DKIM DMARC

SPF・DKIM・DMARC の違いは？

SPF は送信元の許可を確認し、DKIM はメールに署名し、DMARC は認証に失敗したメールの扱いを指定します。

[詳しく見る](https://tajo.io/jp/blog/spf-dkim-dmarc-guide/#%E3%83%A1%E3%83%BC%E3%83%AB%E8%AA%8D%E8%A8%BC%E3%81%8C%E9%87%8D%E8%A6%81%E3%81%AA%E7%90%86%E7%94%B1)

メール認証は、信頼性の高いメール配信の基盤です。適切な SPF、DKIM、DMARC の設定なしでは、丁寧に作成したメールが顧客の受信トレイに届かないかもしれません。代わりに、迷惑メールフォルダに入ったり、完全に拒否されたりします。

この包括的なガイドでは、各メール認証プロトコルが何をするか、ステップごとの DNS 設定手順、よくある問題のトラブルシューティング、設定が正しく動作していることを確認する方法を説明します。

## メール認証が重要な理由

メールはセキュリティが主要な関心事でない時代に設計されました。元々の SMTP プロトコルには、メールが本当に主張する人から送られてきたことを確認する組み込みの検証メカニズムがありません。この根本的な弱点がメールのなりすまし、フィッシング攻撃、スパムを可能にします。

メール認証プロトコルはこの問題を解決し、ドメイン所有者が以下を指定できるようにします。

- **どのサーバーがドメインに代わってメールを送信できるか**（SPF）
- **メッセージが本物で変更されていないことの暗号的証明**（DKIM）
- **認証に失敗したメッセージをどう処理するか**（DMARC）

### 不適切な認証のビジネス影響

適切なメール認証がない場合：

- **低い到達率**：Gmail、Microsoft、Yahoo などの主要プロバイダーが認証されていないメールをより積極的にフィルタリング
- **高いスパム率**：正当なメールがドメインを使用したなりすましメールと競合
- **ブランドの損害**：ブランドを模倣したフィッシング攻撃が顧客の信頼を損なう
- **収益損失**：マーケティングキャンペーンが購読を申し込んだ購読者に届かない
- **コンプライアンスリスク**：多くの規制が適切なメール認証を要求

### 認証の三頭体制

SPF、DKIM、DMARC は完全な認証システムとして連携します。

| プロトコル | 何をするか | 例え |
| --- | --- | --- |
| SPF | 許可された送信サーバーを一覧化 | 承認されたオフィスを持つ会社レターヘッド |
| DKIM | メッセージを暗号的に署名 | 真正性を証明する封蝋 |
| DMARC | 失敗時のポリシーとレポートを設定 | 不審な手紙の処理方法についての指示 |

各プロトコルは異なる攻撃ベクトルに対処します。SPF は無許可のサーバーがあなたとして送信するのを防ぎます。DKIM は送信後のメッセージの改ざんを防ぎます。DMARC は両者を結び付け、認証結果の可視性を提供します。

## SPF（Sender Policy Framework）の理解

SPF（Sender Policy Framework）は、ドメインに代わってメールを送信することが許可されているメールサーバーを指定する DNS ベースのメール認証方式です。

### SPF の仕組み

受信サーバーにメールが届くと、そのサーバーが送信者のドメイン SPF レコードを検索します。次に、メールを送信した IP アドレスが許可リストに登録されているか確認します。IP が一致すれば SPF はパス。一致しなければ SPF は失敗します。

**SPF 検証プロセス：**

1. マーケティングプラットフォームからメールを送信
2. 受信サーバーが Return-Path（エンベロープ送信者）からドメインを抽出
3. サーバーがドメインの SPF レコードを DNS に問い合わせ
4. 送信 IP を SPF レコードの許可リストと比較
5. サーバーがパス、フェイル、ソフトフェイル、またはニュートラル結果を記録

### SPF レコードの構文

SPF レコードはドメインの DNS に TXT レコードとして公開されます。基本的な構造は以下のとおりです。

```
v=spf1 [mechanisms] [qualifier]all
```

**バージョンタグ：** 常に `v=spf1` で始まる

**メカニズム：** 誰が送信できるかを定義

| メカニズム | 説明 | 例 |
| --- | --- | --- |
| include: | 別のドメインの SPF を信頼 | include:spf.brevo.com |
| ip4: | 特定の IPv4 を許可 | ip4:192.168.1.1 |
| ip6: | 特定の IPv6 を許可 | ip6:2001:db8::1 |
| a | ドメインの A レコード IP を許可 | a |
| mx | ドメインのメールサーバー IP を許可 | mx |
| ptr | リバース DNS（非推奨） | ptr:example.com |
| exists: | 条件付きチェック | `exists:%{i}.spf.example.com` |

**クオリファイア：** マッチをどう処理するかを定義

| クオリファイア | 意味 | 結果 |
| --- | --- | --- |
| + | パス（デフォルト） | 許可 |
| - | フェイル（ハード） | 無許可、拒否 |
| ~ | ソフトフェイル | 無許可、受け入れるがマーク |
| ? | ニュートラル | ポリシーなし |

**all メカニズム：** 前のメカニズムに一致しないものすべてに適用

### SPF レコードの例

**1 つのメールプロバイダーでの基本設定：**

```
v=spf1 include:spf.brevo.com -all
```

これは Brevo がドメインのメールを送信することを許可し、他のすべての送信者を拒否します。

**複数のメールサービス：**

```
v=spf1 include:spf.brevo.com include:_spf.google.com include:spf.protection.outlook.com -all
```

これは Brevo、Google Workspace、Microsoft 365 を許可します。

**自社メールサーバーを含める：**

```
v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all
```

これは特定の IP アドレス（自社サーバー）と Brevo を許可します。

**テスト中はソフトフェイルで始める：**

```
v=spf1 include:spf.brevo.com ~all
```

`-all` の代わりに `~all` を使うと、失敗をマークするが拒否しません。初期設定に便利です。

### SPF レコードの設定

**ステップ 1：送信元を特定する**

ドメインからメールを送信するすべてのサービスをリストアップします：

- メールマーケティングプラットフォーム（Brevo、Mailchimp など）
- トランザクションメールサービス
- CRM システム
- ヘルプデスクソフトウェア
- 会社メール（Google Workspace、Microsoft 365）
- 自社メールサーバー

**ステップ 2：SPF include 文を収集する**

各メールサービスプロバイダーが必要な SPF include を文書化しています。一般的な例：

| プロバイダー | SPF Include |
| --- | --- |
| Brevo | include:spf.brevo.com |
| Google Workspace | include:\_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |

**ステップ 3：SPF レコードを作成する**

すべての include を 1 つのレコードにまとめます：

```
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**ステップ 4：DNS レコードを追加する**

DNS 管理インターフェイスで：

- タイプ：TXT
- ホスト/名前：@（またはルートドメインを空白のまま）
- 値：完全な SPF レコード
- TTL：3600（またはデフォルト）

**ステップ 5：レコードを確認する**

DNS ルックアップツールで確認します：

```bash
dig TXT yourdomain.com
```

または MXToolbox SPF Lookup のようなオンラインツールを使用します。

### SPF の制限とベストプラクティス

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

SPF は最大 10 回の DNS ルックアップがあります。各 `include:` は 1 回のルックアップとしてカウントされ、含まれるレコードには独自の include が含まれる場合があり、上限に向けてカウントされます。これを超えると SPF permerror（永続的エラー）が発生し、すべてのチェックが失敗します。

**上限以下に抑える戦略：**

- 可能な場合は IP アドレスを直接使用（ip4: はルックアップとしてカウントされない）
- 同じプロバイダーを使用しているサービスを統合
- include を IP アドレスに変換する SPF フラット化サービスを使用
- 古いサービスの未使用の include を削除

**その他の SPF ベストプラクティス：**

- ドメインごとに 1 つの SPF レコードのみ（複数のレコードは失敗を引き起こす）
- 設定中は `~all`（ソフトフェイル）で始め、確認後 `-all` に移行
- メールプロバイダーを変更するときは SPF を更新
- 非推奨の `ptr` メカニズムは使用しない
- レコードをできるだけシンプルに保つ

### よくある SPF のミス

**複数の SPF レコード：**

```
誤り：
v=spf1 include:spf.brevo.com -all
v=spf1 include:_spf.google.com -all

正解：
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**DNS ルックアップ制限を超える：**

多くの include がある場合は、合計ルックアップ数を確認してください。SPF アナライザーを使って 10 回未満であることを確認します。

**プロバイダー変更後の更新を忘れる：**

あるメールサービスから別のものに切り替える際は、古い include を削除して新しいものを追加してください。

**+all を使用する：**

`+all` は使用しないでください。ドメインからのメール送信を全員に許可してしまいます。

## DKIM（DomainKeys Identified Mail）の理解

DKIM（DomainKeys Identified Mail）はメールに暗号署名を追加し、メッセージがドメインから発信され、転送中に変更されていないことを証明します。

### DKIM の仕組み

DKIM は公開鍵暗号を使用します。

1. メールプロバイダーが公開鍵と秘密鍵のペアを生成
2. DNS に公開鍵を公開
3. プロバイダーが秘密鍵で送信メールに署名
4. 受信サーバーが DNS から公開鍵を取得
5. 公開鍵を使って署名を検証
6. 有効な署名が真正性と整合性を証明

**DKIM が署名するもの：**

DKIM 署名は通常、特定のヘッダーとメッセージ本文をカバーします：

- From ヘッダー（必須）
- Subject ヘッダー
- Date ヘッダー
- メッセージ本文
- 設定に応じたその他のヘッダー

これにより攻撃者が送信後にこれらの要素を変更するのを防ぎます。

### DKIM レコード構造

DKIM レコードは特定の命名形式で TXT レコードとして公開されます。

```
selector._domainkey.yourdomain.com
```

**セレクター**は、複数の DKIM キーを持てるようにする一意の識別子です。異なるメールサービスは異なるセレクターを使用します（例：brevo、google、s1、s2）。

**DKIM レコードのコンテンツ：**

```
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
```

| タグ | 説明 | 例 |
| --- | --- | --- |
| v= | バージョン（常に DKIM1） | v=DKIM1 |
| k= | キータイプ（通常 rsa） | k=rsa |
| p= | 公開鍵（base64） | p=MIGfMA0… |
| t= | フラグ（オプション） | t=s（厳格モード） |
| h= | ハッシュアルゴリズム（オプション） | h=sha256 |

### DKIM の設定

**ステップ 1：DKIM キーを生成する**

メールサービスプロバイダーは通常、キーを代わりに生成します。Brevo では：

1. 「設定」>「送信者、ドメイン、専用 IP」へ
2. ドメインを選択
3. DKIM セクションに移動
4. 提供された DNS レコードをコピー

セルフホストのメールサーバーの場合は、OpenSSL を使ってキーを生成します：

```bash
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
```

**ステップ 2：DKIM の DNS レコードを追加する**

DNS 管理で：

- タイプ：TXT
- ホスト/名前：selector.\_domainkey（例：brevo.\_domainkey）
- 値：プロバイダーからの DKIM レコード
- TTL：3600

**ステップ 3：DKIM 署名を有効化する**

メールプロバイダーの設定でドメインの DKIM 署名を有効化します。これによりプロバイダーが送信メッセージに署名します。

**ステップ 4：設定を確認する**

テストメールを送信し、DKIM-Signature のヘッダーを確認します。ツールを使用します：

- mail-tester.com
- DKIM Validator
- MXToolbox DKIM Lookup

### DKIM のベストプラクティス

**2048 ビットキーを使用：**

古い 1024 ビットキーは弱いとされています。現代のセキュリティ標準では最低 2048 ビット RSA キーが推奨されます。

**定期的にキーをローテーション：**

厳密には必須ではありませんが、DKIM キーを年 1 回ローテーションすることは良いセキュリティプラクティスです。ギャップを避けるために古いキーを削除する前に新しいキーを追加してください。

**キーの漏洩を監視：**

秘密鍵が侵害されると、攻撃者があなたとしてメッセージに署名できます。異常な認証パターンを監視してください。

**サービスごとに異なるセレクターを使用：**

各メールプロバイダーは一意のセレクターを使用する必要があります。これにより独立したキー管理が可能になり、他のサービスと競合しません。

**DNS の伝播を確認：**

DKIM キーは長くなることがあります。DNS プロバイダーが十分な長さの TXT レコードをサポートしていることを確認してください。一部のプロバイダーはキーを複数の文字列に分割する必要があります。

### DKIM ヘッダーの読み方

メールを受信すると、DKIM-Signature ヘッダーが表示されます：

```
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=brevo;
  h=from:to:subject:date:message-id;
  bh=base64hashofbody;
  b=base64signature;
```

| タグ | 意味 |
| --- | --- |
| v= | バージョン（常に 1） |
| a= | アルゴリズム（rsa-sha256 推奨） |
| c= | 正規化（relaxed は軽微な変更を許可） |
| d= | 署名ドメイン |
| s= | セレクター |
| h= | 署名済みヘッダー |
| bh= | 本文ハッシュ |
| b= | 署名 |

## DMARC（Domain-based Message Authentication, Reporting, and Conformance）の理解

DMARC は SPF と DKIM の上に構築され、ポリシー適用とレポート機能を提供します。認証が失敗したときに受信サーバーがすべきことを指示し、認証結果に関するレポートを送信します。

### DMARC の仕組み

DMARC は 2 つの重要な機能を追加します。

1. **ポリシー適用**：受信者が認証失敗をどう処理すべきかを定義
2. **レポート**：ドメインを使ってメールを送信している人に関するデータを受け取る

**DMARC 検証プロセス：**

1. 受信サーバーがドメインから来たと主張するメールを受け取る
2. SPF を確認（送信 IP は一致するか？）
3. DKIM を確認（署名は有効か？）
4. DMARC アライメントを確認（認証されたドメインは From ヘッダーと一致するか？）
5. アライメントが失敗すれば、DMARC ポリシーを適用
6. 集約または個別レポートを送信

*How DMARC decides what happens to a message*

### DMARC アライメント

DMARC は From ヘッダーのドメインと SPF または DKIM をパスするドメイン間の**アライメント**を要求します。

**SPF アライメント：** Return-Path（エンベロープ送信者）のドメインが From ヘッダードメインと一致するか、そのサブドメインである必要があります。

**DKIM アライメント：** DKIM 署名のドメイン（d= タグ）が From ヘッダードメインと一致するか、そのサブドメインである必要があります。

**アライメントモード：**

| モード | 説明 |
| --- | --- |
| Strict（s） | 完全なドメイン一致が必要 |
| Relaxed（r） | サブドメインを許可（デフォルト） |

relaxed アライメントでは、From ヘッダーが `marketing@example.com` を示し、DKIM が `brevo.example.com` で署名している場合、両方が `example.com` という組織ドメインを共有しているためアライメントはパスします。

### DMARC レコードの構文

DMARC レコードは `_dmarc.yourdomain.com` に TXT レコードとして公開されます。

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

**必須タグ：**

| タグ | 説明 | 値 |
| --- | --- | --- |
| v= | バージョン | DMARC1（常に） |
| p= | ポリシー | none、quarantine、reject |

**オプションタグ：**

| タグ | 説明 | デフォルト |
| --- | --- | --- |
| rua= | 集約レポートアドレス | なし |
| ruf= | 個別レポートアドレス | なし |
| pct= | ポリシーを適用する割合 | 100 |
| sp= | サブドメインポリシー | p= と同じ |
| adkim= | DKIM アライメントモード | r（relaxed） |
| aspf= | SPF アライメントモード | r（relaxed） |
| fo= | 個別レポートオプション | 0 |
| ri= | レポート間隔（秒） | 86400 |

### DMARC ポリシーの説明

**p=none（監視のみ）：**

失敗時にアクションなし。メールは通常通り配信されます。レポートを分析し、認証の問題を修正している間に使用します。

```
v=DMARC1; p=none; rua=mailto:dmarc@example.com
```

**p=quarantine（迷惑メールフォルダ）：**

失敗したメールが迷惑メール/ジャンクフォルダに送られます。完全な拒否前の良い中間ステップです。

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
```

**p=reject（ブロック）：**

失敗したメールが完全に拒否されます。最大限の保護ですが、先にすべての正当な送信元がパスすることを確認してください。

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

### DMARC の設定

**ステップ 1：SPF と DKIM が機能していることを確認する**

DMARC は SPF と DKIM に依存します。DMARC を追加する前に両方が正しく設定されていることを確認してください。

**ステップ 2：監視から始める（p=none）**

配信に影響なくデータを収集するため、最も寛容なポリシーから始めます：

```
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
```

**ステップ 3：DNS レコードを追加する**

DNS 管理で：

- タイプ：TXT
- ホスト/名前：\_dmarc
- 値：DMARC レコード
- TTL：3600

**ステップ 4：2〜4 週間レポートを分析する**

DMARC 集約レポートは XML ファイルとして毎日届きます。レポートには以下が含まれます：

- ドメインを使ってメールを送信した IP アドレス
- SPF と DKIM のパス/フェイル率
- DMARC アライメント結果
- 受信サーバーのアクション

以下の DMARC レポートアナライザーを使ってこのデータを可視化します：

- DMARC Analyzer
- Postmark DMARC
- Valimail
- dmarcian

**ステップ 5：認証の問題を修正する**

レポートで明らかになった一般的な問題：

- SPF に含まれていない正当なサービス
- 送信サービスで DKIM が有効化されていない
- 適切な認証なしに送信するサードパーティサービス
- 転送が SPF アライメントを壊している

**ステップ 6：段階的に適用する**

正当な送信元が一貫してパスするようになったら：

1. `p=quarantine; pct=10`（失敗の 10% を隔離）に移行
2. pct を 25、50、75、100 に増やす
3. `p=reject; pct=10` に移行
4. 完全な拒否まで増やす

**ステップ 7：メンテナンスと監視**

レポートのレビューを続けてください。新しい送信元、プロバイダーの変更、設定のドリフトが認証の失敗を引き起こす可能性があります。

### DMARC レポートの理解

**集約レポート（rua）：**

日次の XML サマリーで以下を示します：

- レポート組織
- 日付範囲
- 公開されたポリシー
- ソース IP 別の認証結果
- メールの量

例の抜粋：

```xml
<record>
  <source_ip>203.0.113.10</source_ip>
  <count>1250</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</record>
```

**個別レポート（ruf）：**

失敗の個別のメッセージ詳細。より詳細ですがプライバシーに敏感です。多くの受信者は個別レポートを送信しません。

### DMARC のベストプラクティス

**常に p=none から始める：**

直接 reject に移行すると正当なメールをブロックする可能性があります。まず監視してください。

**レポート用の専用メールアドレスを使用：**

DMARC レポートは大量になる可能性があります。専用アドレスまたはサードパーティサービスを使用してください。

**サブドメインポリシーを設定（sp=）：**

サブドメインからメールを送信しない場合は、`sp=reject` を設定してなりすましから保護してください。

**段階的ロールアウトに割合（pct=）を使用：**

pct タグを使うと、残りを監視しながら失敗の割合にポリシーを適用できます。

**専用の DMARC サービスを検討：**

大規模な組織には、Valimail、dmarcian、Postmark DMARC などのサービスが生の XML ファイルよりも優れたレポート分析を提供します。

## DNS レコード設定：完全なウォークスルー

メール認証を設定するには、特定の DNS レコードを追加する必要があります。このセクションでは主要な DNS プロバイダーの完全なウォークスルーを提供します。

### 必要な値の収集

開始前に、メールプロバイダーからこれらの値を収集してください。

**SPF 用：**

- すべての include 文（例：include:spf.brevo.com）
- 許可する必要がある特定の IP アドレス

**DKIM 用：**

- セレクター名（例：brevo、google、s1）
- 完全な DKIM キー値

**DMARC 用：**

- レポート用メールアドレス

### 一般的な DNS プロバイダーへのレコード追加

**Cloudflare：**

1. Cloudflare ダッシュボードにログイン
2. ドメインを選択
3. 「DNS」>「レコード」へ
4. 「レコードを追加」をクリック
5. SPF 用：Type=TXT、Name=@、Content=SPF レコード
6. DKIM 用：Type=TXT、Name=selector.\_domainkey、Content=DKIM キー
7. DMARC 用：Type=TXT、Name=\_dmarc、Content=DMARC レコード
8. 「保存」をクリック

**Google Domains/Squarespace：**

1. ドメインの DNS 設定へ
2. 「カスタムレコード」までスクロール
3. 「カスタムレコードの管理」をクリック
4. 適切なタイプ、ホスト、データで各レコードを追加
5. SPF 用：Host=@、Type=TXT、Data=SPF レコード
6. DKIM 用：Host=selector.\_domainkey、Type=TXT、Data=DKIM キー
7. DMARC 用：Host=\_dmarc、Type=TXT、Data=DMARC レコード

**GoDaddy：**

1. 「マイ製品」>「ドメイン」へ
2. ドメインの隣の「DNS」をクリック
3. 「レコード」セクションまでスクロール
4. 新しいレコードごとに「追加」をクリック
5. Type に「TXT」を選択
6. Name を入力（SPF は @、DKIM は selector.\_domainkey、DMARC は \_dmarc）
7. 値を入力
8. 保存

**Namecheap：**

1. 「ドメインリスト」>「管理」へ
2. 「詳細 DNS」をクリック
3. それぞれに「新しいレコードを追加」
4. 「TXT レコード」を選択
5. ホスト：SPF は @、DKIM は selector.\_domainkey、DMARC は \_dmarc
6. 値：レコードのコンテンツ
7. 「すべての変更を保存」

### DNS の伝播

レコードを追加した後、変更がグローバルに伝播するまで時間がかかります。通常：

- 最初の可視性まで 5〜30 分
- 完全なグローバル伝播まで最大 48 時間

dig または nslookup で確認します：

```bash
dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com
```

または whatsmydns.net のようなオンラインツールを使って世界中での伝播を確認します。

### 完全な設定例

Brevo と Google Workspace を使用するドメインの場合：

**SPF レコード（@ に TXT）：**

```
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**Brevo 用 DKIM レコード（brevo.\_domainkey に TXT）：**

```
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [Brevo ダッシュボードからのキー]
```

**Google 用 DKIM レコード（google.\_domainkey に TXT）：**

```
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [Google 管理者からのキー]
```

**DMARC レコード（\_dmarc に TXT）：**

```
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
```

## よくある問題のトラブルシューティング

慎重に設定してもメール認証が失敗することがあります。よくある問題と解決方法をご紹介します。

### SPF のトラブルシューティング

**SPF レコードが見つからない：**

症状：SPF チェックが「none」または「レコードなし」と表示

原因：DNS にレコードが追加されていない、間違った場所にレコードが追加された（ルートの代わりにサブドメイン）、DNS 伝播が未完了

解決策：`dig TXT yourdomain.com` でレコードが存在することを確認、Name/Host フィールドを確認（ルートドメインには @ または空白）、DNS 伝播を待つ（最大 48 時間）

**SPF PermError（ルックアップが多すぎる）：**

症状：SPF 結果が「permerror」と表示

原因：SPF レコードに 10 回を超える DNS ルックアップ、過剰なネストされた include を持つ include

解決策：include を監査して未使用のものを削除、可能な場合は ip4: エントリで include を置き換え、SPF フラット化サービスを使用、より少ないプロバイダーにサービスを統合

**正当なメールの SPF ソフトフェイルまたはフェイル：**

症状：正当なメールが SPF に失敗

原因：SPF に含まれていない送信サービス、許可されていない IP からの送信、エンベロープ送信者を変更するリレーの使用

解決策：送信サービスの不足している include を追加、実際にメールを送信した IP を確認（ヘッダーから）、正しい SPF 設定についてメールプロバイダーに連絡

### DKIM のトラブルシューティング

**DKIM 署名が欠けている：**

症状：メールに DKIM-Signature ヘッダーがない

原因：メールプロバイダーで DKIM 署名が有効化されていない、ドメイン検証が未完了、DKIM のないパスを通じて送信

解決策：プロバイダーの設定で DKIM を有効化、ドメイン検証手順を完了、DKIM 設定のプロバイダードキュメントを確認

**DKIM 検証が失敗：**

症状：認証結果で DKIM が「fail」と表示

原因：DNS レコードが公開されていないか不正確、間違ったセレクターが使用された、DNS と署名間のキーの不一致、転送中にメッセージが変更された

解決策：selector.\_domainkey.domain に DNS レコードが存在することを確認、DKIM-Signature ヘッダーのセレクターと DNS を比較、不一致が疑われる場合はキーを再生成、メッセージを変更するメールフィルターまたはリレーを確認

### DMARC のトラブルシューティング

**DMARC アライメントの失敗：**

症状：SPF と DKIM はパスするが DMARC が失敗

原因：認証されたドメインが From ヘッダードメインと一致しない、自社ドメインを使用するサードパーティ送信サービス、誤設定されたエンベロープ送信者

解決策：メールプロバイダーがドメインで署名していることを確認（カスタム DKIM）、カスタム Return-Path/エンベロープ送信者を設定、relaxed アライメントモードを使用（adkim=r; aspf=r）

**DMARC レポートを受信していない：**

症状：集約レポートが届かない

原因：rua アドレスが不正確、メールアドレスが外部メールを受信できない、レポートが迷惑メールに振り分けられている、受信サーバーがレポートを送信していない

解決策：rua の構文を確認：`rua=mailto:address@domain.com`、レポートアドレスが外部メールを受信できることをテスト、レポートの迷惑メールフォルダを確認、注意：すべての受信者が DMARC レポートを送信するわけではない

### 一般的なトラブルシューティングツール

**オンラインバリデーター：**

- MXToolbox（mxtoolbox.com）：SPF、DKIM、DMARC ルックアップ
- Mail Tester（mail-tester.com）：完全な分析のためにテストメールを送信
- DMARC Analyzer：レポートの可視化
- Google 管理ツールボックス：MX、SPF、DKIM を確認

**コマンドラインツール：**

```bash
# SPF を確認
dig TXT yourdomain.com

# DKIM を確認
dig TXT selector._domainkey.yourdomain.com

# DMARC を確認
dig TXT _dmarc.yourdomain.com

# 特定の DNS サーバーから確認
dig @8.8.8.8 TXT yourdomain.com
```

**メールヘッダー分析：**

受信したメールの Authentication-Results ヘッダーを確認します：

```
Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com header.s=brevo;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass action=none header.from=example.com
```

## メール認証と Brevo

Brevo は包括的なメール認証サポートを提供し、送信ドメインの SPF、DKIM、DMARC の設定を簡単にします。

### Brevo での認証設定

**ステップ 1：ドメインを追加する**

1. Brevo アカウントにログイン
2. 「設定」>「送信者、ドメイン、専用 IP」へ
3. 「ドメインを追加」をクリック
4. ドメイン名を入力

**ステップ 2：SPF を設定する**

Brevo が DNS に追加する SPF include を提供します：

```
include:spf.brevo.com
```

既存の SPF レコードに追加するか、新しいものを作成します：

```
v=spf1 include:spf.brevo.com -all
```

**ステップ 3：DKIM を設定する**

Brevo は DKIM キーを自動的に生成します。提供されたレコードをコピーします：

1. Brevo でドメイン設定へ
2. DKIM セクションを見つける
3. DNS レコード名と値をコピー
4. DNS に TXT レコードを追加

**ステップ 4：設定を確認する**

Brevo は DNS レコードを自動的に確認します。緑のチェックマークは設定成功を示します。

### 適切な Brevo 認証のメリット

Brevo で認証を適切に設定すると：

- **より高い受信トレイへの配置**：Gmail、Microsoft、その他のプロバイダーが認証されたメッセージを信頼
- **ブランド保護**：DMARC がドメインのなりすましを防ぐ
- **より良いアナリティクス**：開封とクリックの正確な追跡
- **評判の構築**：一貫した認証が送信者評判を構築

## まとめ

SPF、DKIM、DMARC によるメール認証は、メールコミュニケーションに依存するビジネスにとって、もはやオプションではありません。これらのプロトコルはブランドをなりすましから守り、到達率を改善し、効果的なメールマーケティングに必要な信頼を構築します。

**重要なポイント：**

- **SPF** は DNS を通じて送信サーバーを許可
- **DKIM** は暗号署名でメッセージの真正性を証明
- **DMARC** はポリシーを適用し、レポートを通じた可視性を提供
- 拒否を適用する前に監視（p=none）から始める
- すべての正当な送信元が適切に設定されていることを確認
- 定期的な監視が設定のドリフトを防ぐ

トランザクションメールが確実に顧客に届き、マーケティングキャンペーンのより良い受信トレイ配置が達成され、ブランドがなりすまし攻撃から保護されます。

メールの到達率を改善する準備はできましたか？まず、このガイドで紹介したツールで現在の認証設定を監査し、次に提供されたステップごとの手順に従って SPF、DKIM、DMARC を体系的に設定してください。

## Tajo の役割

Tajoはエージェント型の統合ビルダーです。プロバイダーはそのままに。ほかのすべてはエージェントがつなぎ、各同期はあなたが承認します。Tajo は現在アーリーアクセス中です。 [早期アクセスを申し込む](https://tajo.io/jp/#early-access)

## よくある質問

**SPF、DKIM、DMARC とは何ですか？**

SPF は送信サーバーを検証し、DKIM はメールにデジタル署名を追加し、DMARC は認証されていないメッセージの処理方法を受信者に指示します。三者が連携してメールを認証し、なりすましから保護します。

**3 つすべて（SPF、DKIM、DMARC）が必要ですか？**

はい。Google と Yahoo は現在、すべての送信者に SPF と DKIM を、1 日 5,000 通以上送信する場合は DMARC を要求しています。3 つを組み合わせることで、最良の到達率とセキュリティが得られます。

**SPF、DKIM、DMARC の設定方法は？**

ドメインに DNS レコードを追加します。SPF は許可された送信者を一覧にした TXT レコード、DKIM は公開鍵を持つ TXT レコード、DMARC はポリシーを持つ TXT レコードとして追加します。メールプラットフォームが具体的な値を提供します。

**SPF、DKIM、DMARC の違いは何ですか？**

SPF はどのサーバーがドメインのメールを送信できるかを指定します。DKIM はメッセージの真正性を証明する暗号署名を追加します。DMARC は受信者が認証失敗をどう処理すべきかのポリシーを設定し、レポートを提供します。3 つが連携して完全なメール認証を実現します。

**SPF、DKIM、DMARC の 3 つは本当にすべて必要ですか？**

最適な到達率とセキュリティのためには、必要です。SPF だけではなりすましに弱く、DKIM だけではポリシーを指定できません。DMARC が機能するには SPF か DKIM が必要です。3 つを組み合わせることで、包括的な保護と最も高い受信トレイ到達率が得られます。

**メール認証が機能するまでどれくらいかかりますか？**

DNS の変更は通常 30 分から 48 時間以内に伝播します。伝播後、認証はすぐに適用されます。ただし、一貫した認証に基づく送信者評判の構築には数週間から数か月かかります。

**p=reject で DMARC を設定すると正当なメールがブロックされますか？**

誤って設定された場合はブロックされる可能性があります。これが p=none（監視）から始め、2〜4 週間レポートを分析し、問題を修正してから徐々に quarantine と reject に移行すべき理由です。監視フェーズを飛ばさないでください。

**SPF アライメントと DKIM アライメントとは何ですか？**

アライメントとは、認証されたドメインが表示される From ヘッダードメインと一致することを意味します。SPF アライメントは Return-Path ドメインを比較します。DKIM アライメントは署名ドメイン（d= タグ）を比較します。DMARC は少なくとも 1 つがアライメントすることを要求します。

**1 つのドメインに複数の DKIM キーを持てますか？**

はい。各メールサービスは異なるセレクターを使用できます（例：brevo.\_domainkey、google.\_domainkey）。これにより複数のサービスが独立して DKIM で署名できます。DKIM セレクターの数に制限はありません。

**認証設定後もメールが迷惑メールに振り分けられるのはなぜですか？**

認証は受信トレイへの配置に必要ですが十分ではありません。他の要因には、送信者評判、コンテンツの品質、エンゲージメント率、リストの衛生管理が含まれます。認証は最初のフィルターを通過させます。最終的な配置は良いプラクティスによって決まります。

**DMARC 集約レポートはどう読みますか？**

DMARC 集約レポートは XML ファイルです。dmarcian、Postmark DMARC、DMARC Analyzer のようなツールを使って解析して可視化してください。これらのツールはどの IP がドメインとしてメールを送信しているか、認証のパス/フェイル率を表示します。

**SPF の 10 回ルックアップ制限を超えるとどうなりますか？**

SPF は永続的エラー（permerror）を返し、すべての SPF チェックが失敗します。修正するには、未使用の include を削除し、可能な場合は include を IP アドレスに置き換えるか、SPF フラット化サービスを使用してください。

**SPF レコードには -all と ~all のどちらを使うべきですか？**

テスト中や信頼を構築している間は \`~all\`（ソフトフェイル）を使用してください。すべての正当な送信元がパスすることを確認したら、より強い保護のために \`-all\`（ハードフェイル）に切り替えてください。ソフトフェイルは失敗をマークするが拒否しません。ハードフェイルは拒否を許可します。

**DKIM キーはどのくらいの頻度でローテーションすべきですか？**

厳格な要件はありませんが、年 1 回のローテーションは良いセキュリティプラクティスです。ローテーション時は、まず新しいキーを追加し、DNS 伝播を待ち、新しいキーで署名を有効化してから、移行期間後に古いキーを削除してください。

**サブドメインには別途認証が必要ですか？**

SPF：はい、サブドメインからメールを送信する場合は、各サブドメインに独自の SPF レコードが必要です。DKIM：キーはサブドメインごとに共有または分離できます。DMARC：サブドメインは sp= が設定されているかサブドメイン自体に DMARC レコードがない限り、親ポリシーを継承します。

## 関連記事

### [メールブラックリスト確認：検出、解除、予防の完全ガイド](https://tajo.io/jp/blog/email-blacklist-check-guide/)

2026年3月8日 · 9 分読む

6 セクション

### [メール到達率：受信トレイ到達のための完全ガイド \[2025\]](https://tajo.io/jp/blog/email-deliverability-complete-guide/)

2025年3月8日 · 13 分読む

13 セクション

### [MCP サーバーとは？ 2026年の MCP と MCP UI の仕組み](https://tajo.io/jp/blog/what-is-an-mcp-server/)

2026年10月3日 · 18 分読む

ステップ1 → ステップ6