SocketLabsのSPF・DKIM・DMARC設定。
SocketLabsはOn-Demand Portal内でドメインを認証します。その設定は、「このSPF行を貼り付ける」タイプのサービスとは明確に異なります。送信するメッセージはすべて、プラットフォームを出た時点ですでにSPFで認証され、DKIM署名も付いています。ただし、デフォルトではその認証はSocketLabs自身のドメインemail-od.comのものです。そのため、未設定のメールには「via email-od.com」の表示が付き、DMARCに必要な自社ドメインとのアライメントも一致しません。SocketLabsのメールを自社ドメインとして送信するには、Configuration → Domain Managementで2つのレコードを追加します。Return-Pathを自社のサブドメインに移してSPFのアライメントを一致させるCustom Bounce DomainのCNAMEレコードと、DKIMが自社ドメインとして署名するためのDKIMレコード（1つのCNAME、または生成したTXTのセレクター）です。これに別途DMARCポリシーを加えれば完了です。重要なのは、SocketLabsが推奨するSPFの方法がバウンス用ドメインのCNAMEであり、ルートドメインのSPFレコードにinclude:email-od.comを追加することではない点です。
SocketLabsを認証すべき理由
SocketLabsの認証は形式的な作業ではなく、メールが受信トレイに届くかどうかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail宛ての大量メールに同じ要件の適用を始めました。SocketLabs特有の注意点は、初期状態ではバウンス用ドメインのemail-od.comに対してSPFで認証し、d=email-od.comでDKIM署名することです。どちらのチェックもemail-od.comでは成功しますが、Fromドメインとはアライメントが一致しません。そのためDMARCはアライメントで失敗し、受信者には「via email-od.com」のタグが見え、積み上げた送信レピュテーションは自社ドメインに蓄積されず、未認証の他のSocketLabs送信者と一緒に集約されます。カスタムのバウンス用ドメイン（SPFのアライメントが一致）とカスタムDKIM（DKIMのアライメントが一致）を設定すれば、2つのレコードでこの問題を解消できます。DMARCは両方の仕組みで成功し、「via」タグは消え、レピュテーションは自社ドメインのものになります。
SocketLabsにおけるSPFの実情
SocketLabsは技術的には「include」型のサービスです。include:email-od.comは実在してDNSで確認できます（1つのフラットなレコードv=spf1 ip4:142.0.176.0/20 ip4:… ~allに解決され、ip4の範囲のみでネストしたincludeはないため、SPFの10回のルックアップのうちちょうど1回を消費します）。ただし、SocketLabsが推奨するSPFの方法ではなく、単独ではDMARCのアライメントも得られません。理由は次のとおりです。SPFの評価対象は、表示されるFromアドレスではなく、Return-Path（バウンス／エンベロープ）のドメインです。SocketLabsのReturn-Pathはデフォルトでemail-od.comなので、SPFチェックはemail-od.comのレコードを参照し、SocketLabsのメールについてルートドメインのSPFレコードが参照されることはありません。SocketLabsは代わりにCustom Bounce DomainでSPFを実装します。利用者が自社ドメインのサブドメインにCNAMEレコードを公開します（例：email.yourdomain.com CNAME tracking.socketlabs.com）。tracking.socketlabs.com自体がv=spf1 include:email-od.com ~allを公開しているため、Return-Pathを自社のサブドメインに移すと、SPFは成功し（このCNAMEを通じてSocketLabsのホワイトリスト登録済みIPを継承）、組織ドメインとのアライメントも一致します。既存のルートドメインのSPFレコードを編集する必要は一切ありません。推奨構成でルートドメインのSPFレコードのルックアップを消費しないのはこのためです。include:email-od.comは念のための保険です。ルートドメインのSPFレコードに追加することはできますが（送信IPをそこでも許可し、ルックアップを1回消費します）、それだけではアライメントは得られず、カスタムのバウンス用ドメインを設定済みなら不要です。いつもどおり、SPFのTXTレコードは1つのドメインにつき1つだけにしてください。includeを追加する場合は、2つ目のレコードを公開せず、1行のv=spf1にまとめます。
2つの設定方法
Custom Bounce DomainのCNAME（推奨）
- Return-Pathを自社ドメインのサブドメインに移すので、SPFに成功し、DMARCのアライメントも一致します
- ルートドメインのSPFレコードのDNSルックアップを消費しません。まとめたりフラット化したりする必要もありません
- tracking.socketlabs.comへのCNAMEレコードがSocketLabsのホワイトリスト登録済みIPを自動で継承するので、IPが変わっても編集し直す必要はありません
- 同じサブドメインのCNAMEレコードを、開封とクリックのトラッキングリンクのホワイトラベル化にも再利用できます
ルートドメインのSPFレコードにinclude:email-od.com（任意）
- ルートドメインのSPFレコードにv=spf1 include:email-od.com ~allを自分で追加します
- SPFのDNSルックアップ10回のうち1回を消費します（email-od.comはip4のみのフラットなレコードなので、ちょうど1回です）
- 自社ドメインで送信IPを許可しますが、これだけではSPFのアライメントは一致しません。バウンス用のCNAMEレコードも設定しない限り、Return-Pathはemail-od.comのままです
- せいぜい補足であり、カスタムのバウンス用ドメインの代わりにはなりません
設定手順
- 1
Domain Managementを開く
On-Demand Portalにログインし、左メニューのConfigurationをクリックしてDomain Managementを選び、認証する送信ドメインを選択します（またはクリックして追加します）。以下の操作はすべて、このドメインのカード上で行います。
- 2
Custom Bounce Domain & SPFを開始
ドメインの「Custom Bounce Domain and SPF Authentication」を開きます。自社ドメインのサブドメイン（email.yourdomain.comやbounce.yourdomain.comなど）に置くCNAMEレコードが、SocketLabsによって生成されます。ターゲットはtracking.socketlabs.comです。これがSocketLabsのSPFの実装方法です。このレコードでReturn-Pathが自社ドメインに移り、SPFのアライメントが一致します。
- 3
バウンス用ドメインのCNAMEレコードを公開
DNSホストでCNAMEレコードを作成します。ホストはSocketLabsに表示されるサブドメイン（例：email）、値はtracking.socketlabs.comです。TXTレコードやAレコードに変更しないでください。既存のルートドメインのSPFレコードにも触れないでください。SPFを担うのはこのCNAMEです。
- 4
DKIMの方式を選択
ドメインに戻り、DKIMセクションを開きます。選択肢は2つです。CNAME DKIM Signing機能（最も簡単で、SocketLabsが鍵を所有してローテーションします）と、DKIM Key Generatorを使うAdvanced/TXT方式（セレクターを選び、公開鍵のTXTレコードを公開します）です。どちらか1つを選びます。両方は必要ありません。
- 5
DKIMレコードを公開
CNAME方式の場合は、CNAMEレコードを追加します。ホストはdkim._domainkey、値はdkim._domainkey.email-od.comです。TXT方式の場合は、ホストを<selector>._domainkey（ジェネレーターで選んだ英数字10文字未満のセレクター）とし、SocketLabsに表示されるv=DKIM1; k=rsa; p=…を値としてTXTレコードを追加します。どちらの場合も、以後はDKIMが自社ドメインとして署名します。
- 6
DMARCレコードを追加
SocketLabsはDMARCレコードを作成しません。ホストを_dmarc、値をv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとしてTXTレコードを追加します。p=noneは監視のみのため、アライメントを確認している間、配信には何も影響しません。後で段階的に引き上げます。
- 7
ポータルで確認
Domain Managementに戻り、カスタムのバウンス用ドメインは「Verify Bounce」を、DKIMは「Verify」をクリックします。バウンス用ドメインのステータスがauthenticated、DKIMがactiveになるはずです。DNSの反映は通常数分ですが、SocketLabsがレコードを確認するまでに最大24～48時間かかることがあります。
- 8
テストメールを送信してヘッダーを確認
設定済みドメインのアドレスからGmailアカウントへメッセージを送り、開いて⋮ → Show originalを選びます。SPF: PASSがバウンス用サブドメイン（email-od.comではありません）を示し、DKIM: PASSがd=yourdomain.comを示し、DMARC: PASSと表示されていれば成功です。「via email-od.com」の表示も消えているはずです。
追加するレコード
正確な値はSocketLabsのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| CNAME | tracking.socketlabs.comCustom Bounce Domainです。SPFを担い、アライメントを一致させるのはこのレコードです。サブドメインのラベル（email/bounce/…）はSocketLabsの割り当てに従います。トラッキングのホワイトラベル化にも再利用できます。 | |
| CNAME | dkim._domainkey | dkim._domainkey.email-od.comCNAME DKIM（推奨、最も簡単）：SocketLabsが鍵を所有してローテーションします。セレクターはdkimで、d=が自社ドメインになるのでDKIMのアライメントが一致します。 |
| TXT | sl2026._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…(public key from the DKIM Key Generator)CNAME方式の代替です。鍵を自分で管理したい場合にのみ、Advanced/TXTのDKIM方式を使います。セレクター（ここではsl2026）は自由に選べます（英数字で10文字未満）。値は例です。ジェネレーターのデフォルトは2048ビットの鍵で、アカウントごとに生成されます。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。SocketLabsが作成することはありません。1つのドメインにつき1つで、p=noneから始めてquarantine/rejectへ引き上げます。 |
| TXT | @ | v=spf1 include:email-od.com ~all任意の、念のための保険にすぎません。カスタムのバウンス用ドメインを設定すれば不要で、単独ではSPFのアライメントは一致しません。ルックアップを1回消費します。使う場合は、ルートドメインの1行のSPFレコードにまとめてください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。SocketLabsの設定がこの上限のうち何回を消費するかは、次のとおりです。
SocketLabsの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
SocketLabsはデフォルトですべてのメッセージに署名します。ただし署名はd=email-od.comで行われるため、自社ドメインとはアライメントが一致しません。つまり、DKIMを本当に機能させるのはカスタムDKIMで、設定方法は2つあります。最も簡単なのは、CNAME DKIM Signing機能です。CNAMEを1つ公開します。ホストはdkim._domainkey.yourdomain.comで、dkim._domainkey.email-od.comを指します。貼り付ける鍵ではなくCNAMEなので、秘密鍵と公開鍵の両方をSocketLabsが管理してローテーションし、DNSを編集し直す必要はありません。セレクターは単にdkimで、確認が完了するとSocketLabsはd=yourdomain.comでメールに署名し、DKIMのアライメントが一致します。Advanced/TXT方式ではより細かく制御できます。Domain ManagementでDKIM Key Generatorを実行し、セレクター（英数字で10文字未満、例：sl2026）を選ぶと、SocketLabsが鍵ペアを生成します。秘密鍵はアカウントに保存され、公開鍵が渡されるので、<selector>._domainkey.yourdomain.comにv=DKIM1; k=rsa; p=…の形式でTXTレコードとして公開します。ジェネレーターのデフォルトは2048ビットの鍵です（1024ビットの選択肢もありますが、2048のままにしてください。より強い鍵が現在の標準で、SocketLabsも下げないよう推奨しています）。外部で生成した秘密鍵を使う「bring your own TXT record」という方式もあります。TXT方式の必須条件として、公開した公開鍵をDNSから解決できるまでポータルでは保存できず、保存後は公開鍵がポータルに表示されなくなるので、先に公開してください。両方の方式に共通する注意点が1つあります。カスタムDKIM署名が適用されるのは、Fromアドレス（Purported Responsible Address）が設定済みのドメインと完全に一致するメッセージだけです。他のFromドメインから送ったメールはデフォルトのemail-od.comの署名に戻り、アライメントが一致しないため、送信に使うすべてのドメインでDKIMを設定してください。
DMARC
DMARCは別のポリシー用TXTレコードで、SocketLabsは作成しません。自分でDNSホストに公開します。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを追加します。p=noneは監視のみのため、集計レポート（rua）でSocketLabsのメールがSPFとDKIMに成功し、自社ドメインとアライメントが一致していることを確認する間、配信には何も影響しません。カスタムのバウンス用ドメインでSPFのアライメントが、カスタムDKIMでDKIMのアライメントが得られるので、正しく設定したSocketLabsのドメインは両方の仕組みでDMARCに成功します。転送でSPFが壊れてもアライメントの一致したDKIM署名が残るため、転送にも耐える堅牢な構成です。1～2週間レポートを確認し、すべての正規の送信者（SocketLabsとドメイン上の他のツール）が認証できていることを確かめたら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。送信者の数にかかわらず、_dmarcレコードは組織ドメイン全体で1つだけにしてください。SocketLabsのためだけに2つ目のDMARCレコードを追加してはいけません。
正しく設定できたか確認する
ポータルの「authenticated」「active」のバッジだけで判断せず、実際のメールで確認してください。設定済みドメインのアドレスからGmailの受信トレイへテストメールを送り、開いて⋮ → Show originalを選びます。SPF: PASSがバウンス用サブドメイン（例：email.yourdomain.com、email-od.comではありません）を示し、DKIM: PASSがd=yourdomain.comを示し、DMARC: PASSと表示されていれば成功です。失敗の典型的な兆候は、SPF/DKIMがemail-od.comのままになっていることです。これは、バウンス用ドメインやカスタムDKIMがまだ有効になっていないか、未設定のFromドメインから送信したことを意味します。生のレコードは、dig CNAME email.yourdomain.com（tracking.socketlabs.comに解決されるはず）、dig CNAME dkim._domainkey.yourdomain.com（TXT方式ならdig TXT <selector>._domainkey.yourdomain.com）、dig TXT _dmarc.yourdomain.comで個別に確認できます。その後、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが正しく解決されることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。SocketLabsが、アライメントが一致し完全に成功している送信元として表示されるはずです。
よくある注意点
- 適用範囲
デフォルトの「via email-od.com」タグは、アライメントがまだ一致していないことを示します。カスタムのバウンス用ドメインとカスタムDKIMの両方を設定するまで、SocketLabsはemail-od.comとして認証するため、SPFとDKIMには成功しますが、DMARCはアライメントで失敗します。タグが消えるのは、両方が自社ドメインを指すようになってからです。
- DNS設定
ルートドメインのSPFレコードにinclude:email-od.comを追加するだけでは解決しません。送信IPは許可されますが、バウンス用ドメインのCNAMEレコードを公開しない限りReturn-Pathはemail-od.comのままで、SPFのアライメントを実際に一致させるのはincludeではなくバウンス用のCNAMEです。includeがあれば十分と考えてCNAMEを省略しないでください。
- 適用範囲
カスタムDKIMが署名するのは、Fromアドレス（Purported Responsible Address）が設定済みのドメインと完全に一致するメールだけです。別のFromドメインから送ると、SocketLabsは通知なくデフォルトのemail-od.comの署名に戻り、DKIMのアライメントは一致しません。送信に使うすべてのドメインを設定してください。
- DNS設定
DNSプロバイダーによっては、ホストにアンダースコアを含むCNAMEレコードを受け付けないため、dkim._domainkeyのCNAME方式が使えません。拒否される場合は、代わりにAdvanced/TXTのDKIM方式（DKIM Key Generator）を使ってください。公開鍵のTXTレコードなら、アンダースコアを含むCNAMEの制限を回避できます。
- DNS設定
Cloudflareのプロキシは両方のCNAMEを機能させなくします。バウンス用ドメインとDKIMのCNAMEレコードを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはtracking.socketlabs.comやemail-od.comに解決されず、確認に失敗します。
- 適用範囲
サブアカウントは個別に認証します。SocketLabsのサブアカウントモデルでは、サブアカウントごとにカスタムのバウンス用ドメインとDKIM認証が必要で、マスターアカウントの認証ではカバーされません。
- DNS設定
確認には24～48時間の遅れが出ることがあります。DNSの反映は通常数分ですが、SocketLabsはCNAME/TXTレコードを遅れて再チェックするため、DNSが正しくても「authenticated」「active」にすぐ変わらない場合があります。バッジを待つより、Show originalで確認してください。
- DNS設定
ホストの二重付加に注意してください。ドメインを自動で付加するレジストラでは、dkim._domainkey.yourdomain.comがdkim._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、ラベル（email、dkim._domainkey、<selector>._domainkey）だけを入力します。
- 認証失敗の原因
SPFレコードとDMARCレコードは1つのドメインにつきそれぞれ1つだけにしてください。任意のinclude:email-od.comを追加する場合は、1行のv=spf1にまとめます。SPFレコードが2つあるとPermErrorになり、_dmarcレコードが2つある場合も同様です。
SPFレコードを作成
SocketLabsでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。
送信元
メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。
上の検索欄で利用中のメールサービスを検索するか、してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証SocketLabsのSPFに関するよくある質問
関連記事
トランザクションメール・APIの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。