SenderのSPF・DKIM・DMARC設定。
Sender（sender.net）はメールマーケティングとニュースレターのプラットフォームです。送信ドメインの認証は、Account settings → Domainsで進める3つのレコードの手順で行います。共有のSPFのinclude、DKIMのCNAMEレコード1つ、DMARCポリシーレコードの3つです。まずドメインを追加し、Senderがそのドメインのアドレスに送るリンクをクリックして所有権を証明します。するとSenderが、DNSホストに公開すべきSPF、DKIM、DMARCの正確なレコードを表示します。3つすべての確認が済み、SenderのAuthentication列に緑のチェックマークが3つ並ぶと、キャンペーンは自社ドメインとして送信されます。SPFで認可され、d=yourdomain.comでDKIM署名され、DMARCのアライメントも一致するため、「via sender.net」と表示されたり迷惑メールに振り分けられたりすることがなくなります。
Senderを認証すべき理由
Senderのドメイン認証は形式的な作業ではなく、大量配信のマーケティングプラットフォームでは、受信トレイに届くか迷惑メールフォルダーに入るかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功すること、少なくともp=noneの有効なDMARCポリシーを公開すること、ワンクリックの配信停止を提供することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail宛ての大量メールに同じ要件の適用を始めました。ニュースレターやプロモーションの一斉配信は、まさにこれらのルールの対象です。認証を済ませるまで、送信にはSenderの共有インフラが使われ、自社ドメインとは暗号的に結びつきません。受信者に「via」の表示が見えることがあり、Fromアドレスのアライメントは一致せず、DMARCにも成功できません。レピュテーションも、そのプラットフォーム上の未認証の送信者全員と共有されます。SPF、DKIM、DMARCの設定を完了すれば、各キャンペーンがd=yourdomain.comで署名され、DMARCに成功し、「via」の表示が消えます。積み上げた送信レピュテーションは自社ドメインのものになり、長期的に開封率を守ることにつながります。
SenderにおけるSPFの実情
Senderは正真正銘の「include」型サービスですが、メカニズムはinclude:sendersrv.comであり、include:sender.netではありません。ここは非常によく間違えられる点です。sender.netは同社のWebサイトで、SPFのincludeとしては有効に解決されないため、これを前提にしたものはhard failになります。すべてのSenderユーザーが追加する実際の共有includeはinclude:sendersrv.comで、ルートドメインの単一のSPF TXTレコード内に公開します。Sender自身のドキュメントでは、レコード全体をv=spf1 include:sendersrv.com ?allと示しています。中立の修飾子?allに注目してください。これはSenderのSPFの実際の仕組みを物語っています。重要な点は2つあります。1つ目に、このincludeはフラットではありません。sendersrv.comのSPFレコードはinclude:_spf.mx.cloudflare.netをネストしているため、include:sendersrv.comは、許容される10回のDNSルックアップ（RFC 7208）のうち1回ではなく2回を消費します。Google Workspace、Microsoft 365、その他の送信者をすでに重ねている場合は注意が必要です。2つ目はさらに重要です。多くのマーケティング系メール配信サービス（ESP）と同様に、エンベロープ/Return-PathはSenderが所有します。キャンペーンのバウンスはSender自身のドメインに戻り、SPFチェックの対象もそのドメインです。そのためルートドメインに公開したinclude:sendersrv.comでは、DMARCで求められるSPFのアライメントは一致しません。Senderのサーバーを認可し、Senderのチェックを満たすものではありますが、DMARCの成功を実際に支える仕組みはDKIMです（後述のCNAMEレコードがd=yourdomain.comとして署名します）。Senderが?allを推奨しても問題ないのはこのためです。SenderのAuthenticationチェックがこのincludeを確認し、必須の3点セットの一部でもあるので公開はしてください。ただし、要となるレコードは、あくまでDKIMです。また、ドメインのSPF TXTレコードは必ず1つだけにしてください。v=spf1のレコードがすでにある場合は、2つ目を追加せずinclude:sendersrv.comを既存のレコードにまとめます（SPFレコードが2つあるとPermErrorになります）。
設定手順
- 1
Domainsセクションを開く
app.sender.netにログインし、Account settings → Domainsを開きます。右上のAdd domainボタンをクリックして、新しい送信ドメインの認証を始めます。
- 2
送信ドメインを入力
キャンペーンの送信に使うドメイン（例：yourdomain.com）を入力し、Nextをクリックします。入力するのはFromアドレスのドメインで、サブドメインから送信する場合を除き、サブドメインではありません。
- 3
ドメインの所有権を確認
そのドメインのメールアドレスを入力してVerify ownershipをクリックすると、Senderがその受信トレイに確認リンクをメールで送ります。メールを開いてリンクをクリックすると、Ownership confirmed列に緑のチェックが表示されます。所有権が確認されるまで、SPF、DKIM、DMARCのレコードは表示されません。これはDNSとは別の、必須の最初の関門です。
- 4
DNSレコードのダイアログを開く
Domainsに戻ってドメインの行をクリックすると、「Authenticate your SPF, DKIM and DMARC records.」というタイトルのダイアログが開きます。Senderが3つのレコードをType、Name、Value付きで表示するので、これをDNSホストにコピーします。
- 5
SPFレコードを追加（既存なら1つにまとめる）
DNSホストで、ルートドメイン（Nameは@）にTXTレコードv=spf1 include:sendersrv.com ?allを追加します。v=spf1のレコードがすでにある場合（Google、Microsoft 365、他のツール）は2つ目を追加せず、include:sendersrv.comを既存の行にまとめます。その際、?allに下げず、既存の修飾子（通常は~allまたは-all）を維持してください。
- 6
DKIMのCNAMEレコードを追加
Nameがsender._domainkey、Valueがdkim.sendersrv.comのCNAMEレコードを作成します。TXTではなくCNAMEレコードなので、貼り付ける鍵はありません。Cloudflare上のDNSでは、レコードを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドのプロキシはCNAMEの解決を妨げるため、DKIMの確認に失敗します。
- 7
DMARCレコードを追加
Nameが_dmarcのTXTレコードを追加します。Senderのデフォルトはv=DMARC1; p=none;だけです。これを公開しつつ、実際に状況を把握できるようレポートの受信先を追加してください（v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com）。p=noneは監視のみのため、アライメントを確認する間も配信には影響しません。
- 8
認証チェックを実行
Domainsに戻り、再チェックボタン（Recheck DNS records / Check SPF, DKIM and DMARC recordsというラベル）をクリックします。3つすべてが解決されると、Authentication列に緑のチェックマークが3つ表示されます。DNSの反映は通常数分ですが、最大24～48時間かかることがあります。緑にならないレコードがあれば再チェックしてください。
- 9
テストメールを送信してヘッダーを確認
自分宛てにテストキャンペーンを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASS、DKIM: PASS（yourdomain.comによる署名、セレクターsender）、DMARC: PASSと表示されていれば成功です。DKIMのd=yourdomain.comは、Senderが共有ドメインではなくyourdomain.comとして署名している証拠です。
追加するレコード
正確な値はSenderのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:sendersrv.com ?allルートドメインのSPF：sendersrv.comであり、sender.netではありません。SPFレコードは1つだけにし、このincludeを既存のv=spf1の行にまとめ、より厳格な修飾子（~all/-all）を維持してください。DNSルックアップを2回消費します（Cloudflareのincludeをネストしているため）。 |
| CNAME | sender._domainkey | dkim.sendersrv.comDKIM：CNAMEレコードであり、TXT鍵ではありません。セレクターはすべてのアカウントで「sender」に固定で、鍵のホストとローテーションはSenderが行います。Cloudflareでは「DNS only」（グレーのクラウド）に設定してください。DMARCの成功を支えるのはこのレコードです。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comSenderのデフォルトは、p=noneだけの仮の値です。ruaの受信先を追加し、DMARCレコードはドメインごとに1つにしてください。p=noneから始め、quarantine、rejectへと引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Senderの設定がこの上限のうち何回を消費するかは、次のとおりです。
Senderは10回のルックアップのうち2回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
SenderのDKIMは単一のCNAMEレコードで、貼り付けるTXT鍵ではありません。追加するのはNameがsender._domainkey、Valueがdkim.sendersrv.comのレコード1つだけです。Senderのインフラに委任するCNAMEなので、Senderが秘密鍵を保持して公開鍵をSender側で提供します（dkim.sendersrv.comは現在1024ビットのRSA鍵を公開しています）。そのため、ユーザーがDNSに再び触れなくても、Senderが鍵を一元的にローテーションできます。コピーする鍵はなく、セレクターはすべてのアカウントでsenderに固定されています。このレコードが重要なのは、エンベロープ/Return-PathをSenderが所有しているため、SPFは自社ドメインとアライメントが一致しないものの、DKIMは一致するからです。Senderはキャンペーンに署名する際、d=yourdomain.comとセレクターsenderを使います。CNAMEにより受信側はyourdomain.comの配下で鍵を取得できるため、DKIMのアライメントが一致し、DMARCの成功を支えます。つまり、DKIMのCNAMEレコードは省略できません。実務上の注意点は2つあります。Cloudflare上のDNSでは、レコードを「DNS only」（グレーのクラウド）にする必要があります。プロキシが有効なCNAMEレコードはdkim.sendersrv.comに解決されず、確認に失敗します。また、セレクターが固定の共有senderなので、鍵はすべてのユーザーで共通です（アライメントには問題ありませんが、1024ビット鍵を自分でアップグレードすることはできません）。
DMARC
DMARCは自分で公開する別のポリシーレコードで、Senderのデフォルト値は意図的に最小限で、v=DMARC1; p=none;だけです。_dmarc.yourdomain.comに公開しますが、そのままにせず、レコードが実際に役立つよう、レポートの受信先を追加してください（例：v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com）。p=noneは監視のみのため、配信には影響せず、受信側から集計レポート（rua）がメールで届きます。このレポートで、Senderのキャンペーン（およびドメイン上の他のすべての送信者）が、SPFとDKIMに自社ドメインとアライメントが一致した状態で成功しているかがわかります。Senderの場合、アライメントはDKIM（d=yourdomain.com、セレクターsender）によるものなので、CNAMEレコードが有効になれば、DKIMのアライメントが一致した成功が確認できるはずです。1～2週間レポートを確認し、正規の送信者がすべて認証されていることを確かめたら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。なりすましを実際に防ぐのは、この段階です。送信に使うツールの数にかかわらず、組織ドメイン全体で_dmarcレコードは1つだけにしてください。Sender専用に2つ目のDMARCレコードを追加してはいけません。
正しく設定できたか確認する
SenderのAuthentication列の緑のチェックマーク3つだけで判断せず、実際のメールで確認してください。自分宛てにテストキャンペーンを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASS、DKIM: PASS、DMARC: PASSと表示され、DKIM署名がd=yourdomain.com、セレクターsenderとなっていれば成功です（DKIMがsendersrv.comとして署名している場合やCNAMEが解決されない場合は、レコードがまだ有効になっていません）。dig TXT yourdomain.com（SPF）、dig CNAME sender._domainkey.yourdomain.com（dkim.sendersrv.comが返るはずです）、dig TXT _dmarc.yourdomain.comで生のレコードを確認することもできます。次に、Qualisendのドメイン診断でドメインをチェックし、3つのレコードすべてが解決され、SPFがDNSルックアップの10回制限に収まっていることを確認します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップしてください。Senderが、DKIMのアライメントが一致して成功している送信元として表示されるはずです。
よくある注意点
- DNS設定
正しくはinclude:sendersrv.comで、include:sender.netではありません。sender.netは同社のWebサイトで、SPFのincludeとして解決されないため、公開するとSPFに失敗します。すべてのSenderユーザーが同じinclude:sendersrv.comを使います。
- DNS設定
DKIMのCNAMEレコードは、Cloudflareのプロキシの背後では機能しません。sender._domainkey → dkim.sendersrv.comは「DNS only」（グレーのクラウド）にする必要があります。プロキシが有効（オレンジのクラウド）なCNAMEは解決されず、DKIMの確認が失敗します。これが、レコードの確認はどこでも通るのに、実際の受信トレイでだけ失敗する場合の最も多い原因です。
- DNS設定
SPFのincludeはDNSルックアップを1回ではなく2回消費します。sendersrv.comのSPFレコードはinclude:_spf.mx.cloudflare.netをネストしておりフラットではありません。Google Workspace、Microsoft 365、その他の送信者も重ねている場合は、RFC 7208の10回制限に両方を含めて計算してください。
- 適用範囲
Senderのドキュメントには中立の修飾子?allが記載されています。include:sendersrv.comをルートドメインの既存のSPFレコードにまとめるときは、より厳格な修飾子（~allまたは-all）を維持してください。Senderの例にあわせてレコード全体を?allに下げないでください。
- DNS設定
DMARCの成功を支えるのは、SPFではなくあくまでDKIMです。Return-PathはSenderが所有するため、ルートドメインのinclude:sendersrv.comではアライメントが一致しません。DMARCを支えるのは、DKIMのCNAMEレコード（d=yourdomain.com）です。1つしか設定する時間がなければ、このCNAMEを選んでください。
- DNS設定
まずドメインの所有権を確認してください。Senderはそのドメインのアドレスに確認リンクをメールで送り、クリックするまでSPF、DKIM、DMARCのレコードは表示されません。その前にDNSレコードを公開しても先に進めません。
- 適用範囲
DMARCをp=noneだけの仮の状態で放置しないでください。Senderのデフォルトにはruaがなく、実効性もありません。レポートの受信先を追加してp=rejectへと引き上げなければ、レコードは何も保護しません。
- 適用範囲
DKIMのセレクター「sender」と鍵は共有かつ固定です。セレクターの名前変更や（1024ビットの）鍵のアップグレードを自分で行うことはできません。アライメントには問題ありませんが、ドメイン上の別のものがすでにsender._domainkeyを使っていると衝突します（まれです）。
SPFレコードを作成
以下ではSenderがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証SenderのSPFに関するよくある質問
関連記事
マーケティング・ESPの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。