# SPF・DKIM・DMARC とは：ネットショップ向けにやさしく解説

> SPF はドメインの代わりに送信してよいサーバーを列挙し、DKIM は DNS に公開した鍵で各メールに署名します。DMARC は、表示される From アドレスのドメインについて少なくとも一方が合格しているかを確かめ、どちらも不合格のときの扱いを受信側に伝えます。Gmail と Yahoo は大量送信者に 3 つすべてを求めているため、メルマガを配信するショップは 3 つとも公開しておくのが基本です。

Canonical: https://tellnod.com/ja/guides/spf-dkim-dmarc-explained  
Last updated: 2026-10-22  
Author: Tellnod team

## 受信側がこの 3 つのレコードを確認する理由

メールの From 欄には、誰でも好きなアドレスを書き込めます。ninefold.example から届いたと名乗るメールが本当に Ninefold から送られたものかを、受信側が見分けるための仕組みが SPF・DKIM・DMARC です。どれも自分のドメインに公開する DNS レコードで、それぞれが別の問いに答えます。

ショップにとっての実際の効果は、受信トレイに届くかどうかです。Google はすべての送信者に SPF または DKIM の設定を求め、個人の Gmail アカウントへ 1 日 5,000 通を超えて送る送信者には SPF・DKIM・DMARC のすべてを求めています [S4]。Yahoo も大量送信者に同じ基準を設けています [S5]。国内では、日本の Yahoo メールを運営する LINEヤフーも DKIM・SPF・DMARC を導入しています [S8]。この規模に届かない場合でも、認証済みのメールは自分のドメインの[送信者レピュテーション](https://tellnod.com/glossary#sender-reputation)を積み上げます。さらに DMARC レコードがあれば、第三者があなたの名前でフィッシングメールを送ることがずっと難しくなります。

## それぞれのレコードの役割

### SPF：送信を許可するサーバーの一覧

[SPF](https://tellnod.com/glossary#spf) は、そのドメインのメールを送信してよいサーバーを列挙した TXT レコードです。受信サーバーは、接続してきた IP アドレスをこの一覧と照らし合わせます。SPF が確認するのはエンベロープ送信者（配信時に使われる MAIL FROM アドレスで、バウンスの受け取り先にもなります）であり、お客様の画面に表示される From アドレスではありません [S1]。Google Workspace などのメールボックスとメール配信サービスを併用するショップの場合、典型的なレコードは次のようになります。

`v=spf1 include:spf.mailbox.example include:spf.mailservice.example ~all`

`include` のひとつひとつが、別のサービスの許可リストを取り込みます。末尾は、それ以外のサーバーの扱いを示します。`-all` は fail、`~all` は softfail で、softfail だけを理由に受信側が拒否することは想定されていません [S1]。

### DKIM：すべてのメールに付く署名

[DKIM](https://tellnod.com/glossary#dkim) は、メールのヘッダーに暗号の署名を加えます。署名には署名ドメイン（`d=`）とセレクタ（`s=`）が含まれ、受信側は `selector._domainkey.domain` の DNS レコードから公開鍵を取得します [S2]。署名されたヘッダーや本文が途中で書き換えられていれば、検証は失敗します。DKIM 単体では、署名ドメインが From アドレスと一致している必要はありません [S2]。DMARC が必要になるのはこのためです。

### DMARC：表示される差出人アドレスと結びつけるポリシー

[DMARC](https://tellnod.com/glossary#dmarc) は `_dmarc.yourdomain` に置く TXT レコードです。表示される From アドレスと一致するドメインで SPF か DKIM が合格したかを受信側に確認させ、不合格のメールの扱い（`none`、`quarantine`、`reject`）とレポートの送り先を伝えます [S3]。最初のレコードは `v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example` のように短くてかまいません。

| レコード | 公開する場所 | 確認する内容 | 合格が示すこと |
| --- | --- | --- | --- |
| SPF | ドメインの TXT | 接続してきたサーバーの IP アドレス | そのサーバーがエンベロープのドメインの送信を許可されている |
| DKIM | selector._domainkey の TXT | メールヘッダー内の署名 | メールが改ざんされておらず、そのドメインが署名した |
| DMARC | _dmarc の TXT | SPF または DKIM の結果とアラインメント | 表示される From のドメインが、合格した認証に裏付けられている |

## 3 つの連携：アラインメントとは

SPF と DKIM は、どちらも別のドメインで合格することがあります。たとえばメール配信サービスが自社のバウンス用ドメインで SPF に合格し、DKIM も自社名義で署名している一方で、From 欄には ninefold.example と表示されている場合です。どちらの結果も、Ninefold については何も証明していません。

DMARC は、アラインメント（ドメインの一致）でこの穴をふさぎます。From のドメインと一致するドメインで SPF が合格するか、一致するドメインで DKIM が合格すれば、そのメールは DMARC に合格します [S3]。アラインメントは初期設定で緩やか（relaxed）なため、mail.ninefold.example による DKIM 署名は ninefold.example の From アドレスと一致するとみなされます。厳格（strict）にすると完全一致が必要です [S3]。Gmail と Yahoo も大量送信者に同じルールを示しており、From のドメインは SPF か DKIM のドメインと一致している必要があります [S4][S5]。

> SPF よりも、アラインメントの取れた DKIM のほうが重要です。メールが転送されると、転送先のサーバーは自分の IP アドレスから接続するため、元のドメインの SPF は失敗しがちです [S1]。DKIM の署名は、メールが変更されない限り有効なまま残ります。

## ショップが公開すべきレコード

DNS に手を付ける前に、自分のドメインを From アドレスに使ってメールを送っているサービスをすべて書き出してください。Ninefold のような小さなアパレルブランドなら、業務用のメールボックス、ストアの注文・発送メール、問い合わせ管理ツール、メール配信ツールあたりが一般的です。そのすべてを対象に含める必要があります。

1. 自分のドメインで送信するすべてのサービスを含めた SPF レコードを 1 つ。
2. それぞれのサービスで、自分のドメインを署名ドメインとして DKIM を有効にする。サービスごとに専用のレコードとセレクタが発行されるため、複数の DKIM レコードを並べて公開できます。
3. DMARC レコードを 1 つ。まずはレポートの送り先を付けて `p=none` で始め、何かを強制する前に、誰があなたのドメインで送信しているかを把握します。`quarantine` と `reject` への移行は [DMARC の設定ガイド](https://tellnod.com/ja/guides/how-to-set-up-dmarc)で説明しています。

認証は、受信側が求めることの一部にすぎません。ワンクリックでの配信停止や[迷惑メール報告率](https://tellnod.com/glossary#spam-complaint-rate)も見られています。そのほかの点は[メール到達率の基本](https://tellnod.com/guides/email-deliverability-basics)をご覧ください。

## よくある設定ミス

- **SPF レコードが 2 つある。** `v=spf1` で始まるレコードは 1 つのドメインに 1 つまでです。2 つあると、すべてのメールで SPF が恒久的なエラー（permerror）になります [S1]。1 つのレコードにまとめてください。
- **DNS 参照の回数が多すぎる。** `include`、`a`、`mx`、`ptr`、`exists`、`redirect` はそれぞれ DNS 参照を 1 回使い、10 回を超えると SPF はエラーで止まります [S1]。include を積み重ねるのではなく、使っていないサービスを外してください。
- **DKIM が配信サービスのドメインで署名されている。** 署名自体は合格しますが、From アドレスとは一致しません。各ツールで、自分のドメインの DKIM を設定してください。
- **いきなり p=reject にする。** ストアの注文確認メールなど、見落としていた送信元が気づかないうちに不合格になり始めます。`p=none` で始め、先にレポートを確認してください。
- **レポートの送り先がない。** `rua` のない DMARC レコードでは、判断材料になるデータが届きません。Yahoo も設定時には有効な `rua` タグを付けることを強く推奨しています [S5]。

## レコードの確認方法

公開されている内容は DNS の照会で、受信側が実際にどう判定したかは届いたメールで確認できます。

- **ターミナルから：** `dig +short TXT ninefold.example` で SPF、`dig +short TXT _dmarc.ninefold.example` で DMARC が表示されます。セレクタがわかれば、`dig +short TXT selector._domainkey.ninefold.example` で DKIM の鍵も確認できます。
- **ブラウザから：** TXT レコードを照会できる DNS ルックアップツールなら、同じ結果が得られます。
- **実際のメールから：** Gmail のアドレスにテストを送って開き、「その他」から「メッセージのソースを表示」を選びます [S6]。そのメールの SPF・DKIM・DMARC の結果と、それぞれが合格したドメインがヘッダーに表示されます。

DMARC は現在 IETF の標準化トラックに乗っており、2026 年 5 月に公開された RFC 9989 が RFC 7489 に置き換わりました [S3][S7]。レコードは引き続き `v=DMARC1` で始まるため、従来のルールで書いたレコードもそのまま使えます [S3]。

## Claude や ChatGPT で Tellnod を使って認証を設定する

Tellnod は、Claude や ChatGPT の中でメルマガを作成、プレビュー、送信するための [MCP コネクタ](https://tellnod.com/glossary#mcp-connector)です。初日から、Tellnod の共用ドメイン上にあるショップ名のアドレス（例：hello@yourshop.tellnodmail.com）を使って、DNS を変更せずに送信できます。この場合、1 回のキャンペーンにつき 500 人まで、1 か月 1,000 通までという制限があります。独自ドメインを認証するとこの制限はなくなり、私たちもこの設定をおすすめしています。

ドメインを認証するには、チャットで「ninefold.example を送信ドメインとして設定して」のように頼みます。Tellnod が SPF・DKIM・DMARC のレコードを示し、設定されたかを確認します。DNS を別の方が管理している場合は、「Web 制作会社向けに設定用のリンクを作って」と頼んでください。管理者はアカウントを作らずに、対応している DNS プロバイダならワンクリックでレコードを追加でき、コピーして設定することもできます。ドメインの認証が完了すると、チャットとメールでお知らせします。DNS の反映には通常数分、長いと 48 時間ほどかかります。

認証を設定しても、送信の流れは変わりません。どのキャンペーンもパソコンとスマートフォンの表示をプレビューでき、[確認カード](https://tellnod.com/glossary#approval-card)で「Confirm」を押すまで何も送信されません。送信はすべて、あなたが承認します。まずは Claude や ChatGPT に [Tellnod を接続](https://tellnod.com/ja/connect)してください。無料プランと有料プランは[料金ページ](https://tellnod.com/ja/pricing)で確認できます。

## FAQ

### SPF・DKIM・DMARC は 3 つとも必要ですか。1 つでは足りませんか？

Google はすべての送信者に SPF または DKIM を求め、Gmail へ 1 日 5,000 通を超えて送る送信者には SPF・DKIM・DMARC のすべてを求めています [S4]。送信量にかかわらず、3 つとも公開しておくのが安全な基本です。

### SPF と DKIM の違いは何ですか？

SPF は IP アドレスをもとに、どのサーバーが送信したかを確認します。DKIM はメールそのものに付いた署名を確認するため、内容が変更されない限り、転送後も有効です [S1][S2]。

### SPF レコードを複数設定できますか？

できません。同じドメインに SPF レコードが複数あると恒久的なエラーになるため、送信サービスはすべて 1 つのレコードにまとめる必要があります [S1]。

### DMARC を設定すれば迷惑メールに入らなくなりますか？

DMARC は、メールが本当にあなたのものであることを証明し、ドメインのなりすましを防ぎます。受信トレイに届くかどうかは、同意の取得、苦情の割合、読者の反応にも左右されるため、DMARC の合格は必要条件ですが、それだけでは十分ではありません。

### DMARC のアラインメントとは何ですか？

SPF や DKIM で合格したドメインが、表示される From アドレスのドメインと一致していることです。初期設定では緩やかな一致のため、同じドメインのサブドメインも一致とみなされます [S3]。

## Sources

- [S1] RFC 7208: Sender Policy Framework (SPF) for authorizing use of domains in email: <https://www.rfc-editor.org/rfc/rfc7208> (checked 2026-10-22)
- [S2] RFC 6376: DomainKeys Identified Mail (DKIM) signatures: <https://www.rfc-editor.org/rfc/rfc6376> (checked 2026-10-22)
- [S3] RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC): <https://www.rfc-editor.org/rfc/rfc9989> (checked 2026-10-22)
- [S4] Google Workspace Admin Help: Email sender guidelines: <https://support.google.com/a/answer/81126> (checked 2026-10-22)
- [S5] Yahoo Sender Hub: Sender best practices: <https://senders.yahooinc.com/best-practices/> (checked 2026-10-22)
- [S6] Gmail Help: Trace an email with its full header: <https://support.google.com/mail/answer/29436> (checked 2026-10-22)
- [S7] RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC): <https://www.rfc-editor.org/rfc/rfc7489> (checked 2026-10-22)
- [S8] LINEヤフー：Yahoo メールを安心・安全にご利用いただくための取り組み: <https://www.lycorp.co.jp/ja/sustainability/csr/article/045/> (checked 2026-10-22)
