Customer.ioのSPF・DKIM・DMARC設定。
Customer.ioのドメイン認証は、昔ながらの透明性の高い方式です。ワンクリックのウィザードも、すべてをCNAMEで委任する仕組みもありません。専用の送信用サブドメインに公開する少数のDNSレコードが提示され、公開後にCustomer.ioがそれらを確認します。追加するのは、2つのホスト名を持つ1つのMXレコード（バウンスと迷惑メール報告のフィードバック用に、自社ドメイン上のカスタムReturn-PathをCustomer.ioに与えます）、共有のinclude:customeriomail.comメカニズムを使うSPFのTXTレコード、Customer.ioが鍵を生成するDKIMのTXTレコードです。DMARCは4つ目のレコードで、自分でルートドメインに追加します。これらはすべて、Workspace SettingsのEmailにあるSending Domainsページで管理します。SPFとDKIMの両方が緑色になると、メールはcustomeriomail.comに頼らず、完全に自社ドメインとして送信されます。
Customer.ioを認証すべき理由
Customer.ioは、ニュースレター、ライフサイクルキャンペーン、トランザクションのジャーニーなどを扱う、大量配信向けの行動ベースのメッセージングプラットフォームです。そのため、ほぼすべてのアカウントが、今や受信トレイへの到達を左右する大量送信者の基準を超えます。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail/Live宛ての大量メールに同じ要件の適用を始めました。Customer.ioは、この点で多くのメール配信サービス（ESP）より厳格です。SPFとDKIMの両方が確認されるまで、そのドメインからは送信できません。未認証のドメインでは送信そのものができず、後からどちらかのレコードが壊れると配信に失敗します。さらに、アライメントの面でも設定する価値のある利点があります。自社の送信用サブドメイン上にCustomer.ioがカスタムReturn-Pathを用意するため（MXレコードはそのためのものです）、SPFのチェックはcustomeriomail.comだけでなく自社ドメインに対して行われます。つまり、DKIMしかDMARCを支えられないMailchimpやKlaviyoのデフォルト設定とは異なり、正しく設定したCustomer.ioのドメインは両方の仕組みでDMARCに成功できます。これは転送にも耐える堅牢な構成であり、築いた送信者レピュテーションも自社ドメインに蓄積されます。
Customer.ioにおけるSPFの実情
Customer.ioは正真正銘の「include」型のサービスです。共有のinclude:customeriomail.comメカニズムを含むSPFのTXTレコードを1つ公開します（完全なレコードはv=spf1 include:customeriomail.com ~allで、Customer.ioのダッシュボードの表示どおり~allで終わります）。ただし、Customer.io固有の2つの事実により、追加する場所と方法が変わります。第1に、このレコードはルートドメインに置きません。Customer.ioはmail.yourbrand.comやemail.yourbrand.comのような専用の送信用サブドメインを推奨しており（事実上の前提でもあります）、SPF、DKIM、MXのレコードはすべてそこに置きます。これは意図的な設計です。MXレコードによってCustomer.ioのReturn-Pathが自社サブドメインに置かれ、エンベロープ送信者が自社ドメイン上になるため、SPFのアライメントが実際に一致し、DMARCの成功に寄与できます。Return-Pathを自ら保持するESPにはできないことです。第2に、このincludeはフラットではありません。customeriomail.comをライブで調べるとv=spf1 ip4:50.31.36.179 include:sendgrid.net ~allが返り、さらにsendgrid.netはinclude:ab.sendgrid.netをネストしています。つまりinclude:customeriomail.comが消費するDNSルックアップは、多くのガイドが主張する1回ではなく、RFC 7208の上限である10回のうち約3回です。専用の送信用サブドメインに置けば、このコストをルートドメインのSPFレコードの10回制限から完全に切り離せます。これこそがサブドメイン方式の要点です。送信用サブドメインのSPFレコードは1つだけにし、他の送信元をまとめないでください。このサブドメインはCustomer.io専用です。
2つの設定方法
専用の送信用サブドメイン（推奨）
- Customer.ioのMX、SPF、DKIMのレコードはすべて、mail.yourbrand.comのような1つのサブドメインに置きます
- MXベースのカスタムReturn-Pathはサブドメインにとどまるため、メインの受信メールに干渉することはありません
- ネストしてルックアップを約3回消費するinclude:customeriomail.comを、ルートドメインのSPFレコードの10回制限から切り離せます
- マーケティング/ライフサイクルの送信量は分離されたサブドメイン上でレピュテーションを築くため、ルートドメインを保護できます
ルートドメインの認証（避ける）
- Customer.ioはルートドメインを必須としておらず、推奨もしていません
- 2つのホスト名を持つMXレコードがルートドメインに置かれ、実際の受信用MXと競合します
- ネストしたincludeが、Google Workspace、M365、他のすべての送信者と並んで、ルートドメインのSPFレコードの10回のルックアップのうち約3回を消費します
- 1回の質の低いマーケティング送信が、ドメイン全体の送信者レピュテーションを引き下げかねません
設定手順
- 1
Sending Domainsページを開く
サインインしてSettingsアイコンをクリックし、Workspace Settings → Email → Sending Domainsを開きます。ドメインの追加、DNSレコードの表示、確認はすべてこのページで行います。SPF、DKIM、MX、リンクトラッキング用のCNAMEはすべてここに表示されますが、DMARCは表示されません。DMARCはDNSホストで別途追加してください。
- 2
送信用サブドメインを追加
Add Sending Domainをクリックし、ルートドメインではなく専用のサブドメインを入力します。mail.yourbrand.comやemail.yourbrand.comが一般的です。サブドメインから送信することで、Customer.ioがそこにカスタムReturn-Pathを置けるようになり、MXレコードもルートドメインから切り離せます。
- 3
DNSレコードを表示
ドメインのAuthenticationタブに、公開すべき正確なレコードが表示されます。2つのホスト名を持つMXレコードが1つ、SPFのTXTレコードが1つ、DKIMのTXTレコードが1つ（鍵はアカウント用に生成されます）です。Link Trackingタブには、ブランド化されたリンクトラッキング用の任意のCNAMEレコードも表示されます。各Host/NameとValueを表示どおりに正確にコピーしてください。DKIMセレクターと2つのMXホスト名はアカウント固有です。
- 4
2つのホスト名を持つMXレコードを追加
DNSホストの送信用サブドメイン（ホストはmail）に、Customer.ioが示す両方のホスト名を含む1つのMXレコードを、指定された優先度で作成します。このMXは、カスタムReturn-Path/バウンス用アドレスを自社ドメイン上でCustomer.ioに与えるためだけのものです。通常のメールを受信することはなく、サブドメイン上にあるためルートドメインへの受信配信にも影響しません。
- 5
SPFのTXTレコードを追加
同じサブドメイン（ホストはmail）に、次のTXTレコードを追加します：v=spf1 include:customeriomail.com ~all。このサブドメインのSPFレコードはこれ1つだけにし、他の送信者のメカニズムを追加しないでください。このサブドメインはCustomer.io専用です。ダッシュボードの表示どおり~allで終わらせます。
- 6
DKIMのTXTレコードを追加
Customer.ioが生成したとおりに、DKIMのTXTレコードを追加します。ホストはサブドメイン配下のセレクター（selector._domainkey.mailなど）、値はv=DKIM1; k=rsa; p=<public key>です。これは貼り付けるTXTであり、CNAMEレコードではありません。そのため静的で、Customer.ioが黙ってローテーションすることはありません。
- 7
（任意）リンクトラッキング用のCNAMEレコードを追加
クリック計測付きリンクをcustomeriomail.comではなく自社ドメインでブランド化したい場合は、Link Trackingタブに表示されたCNAMEレコードを追加します（トラッキング用サブドメインがCustomer.ioを指します）。認証には必須ではありませんが、省略するとトラッキングリンクはcustomeriomail.comのままになり、ブランドの一貫性が弱まります。
- 8
ルートドメインにDMARCレコードを公開
Customer.ioがDMARCレコードを作成することはありません。ルートドメイン（送信用サブドメインではありません）の_dmarcに、次のTXTレコードを追加します：v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com。p=noneは監視のみのため、アライメントの確認中も何も変わりません。送信用サブドメインはこのポリシーを自動で継承します。
- 9
Verify domainをクリック
Authenticationタブに戻り、Verifyをクリックします（レコードが解決されると灰色のチェックが緑に変わります）。DNSの反映は通常数分ですが、最大24～48時間かかることがあります。特に必要なのは、SPFとDKIMの緑のチェックマークです。Customer.ioは、ドメインから送信する前にこの両方を必須としています。MXレコードとリンクトラッキング用のレコードはReturn-Pathとブランディングを支えるものですが、送信の条件となるのはSPF+DKIMです。
- 10
テストメールを送信してヘッダーを確認
認証済みサブドメインのFromアドレスからキャンペーンまたはブロードキャストを送信し、Gmailで開いて⋮ → Show originalを選びます。SPF: PASS（エンベロープが自社サブドメイン上）、DKIM: PASSでd=yourbrand.com（customeriomail.comではない）、DMARC: PASSを確認します。続いて、ドメイン診断でサブドメインをチェックし、すべてのレコードが解決されることを確かめます。
追加するレコード
正確な値はCustomer.ioのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| MX | mxa.customeriomail.com1つのMXレコードに含まれる2つのホスト名のうち1つ目です。バウンス/迷惑メール報告のフィードバック用に、送信用サブドメイン上に置くCustomer.ioのカスタムReturn-Pathです。例です。正確な2つのホスト名と優先度はAuthenticationタブからコピーしてください。 | |
| MX | mxb.customeriomail.com同じMXレコードの2つ目のホスト名です。例です。Customer.ioに表示された正確な値と優先度を使ってください。 | |
| TXT | v=spf1 include:customeriomail.com ~all送信用サブドメインのSPFレコードです。SPFレコードはホストごとに1つです。include:customeriomail.comはネストして約3回のルックアップを消費します（sendgrid.net → ab.sendgrid.netを経由）。ダッシュボードの表示どおり~allで終わります。 | |
| TXT | selector._domainkey.mail | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(public key from Customer.io)DKIMのTXTレコードです。Customer.ioが鍵ペアを生成し、貼り付ける完全な値を表示します。例です。実際のセレクターと鍵はアカウントごとに異なり、Authenticationタブで確認できます。委任されたCNAMEレコードではなく、静的なTXTです。 |
| CNAME | customeriomail.com（任意）ブランド化されたリンクトラッキング用で、トラッキング用サブドメインに置きます。正確なホスト/ターゲットはLink Trackingタブからコピーしてください。SPF/DKIMの確認には不要です。 | |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.comルートドメインに自分で追加します。Customer.ioが作成することはありません。ドメインごとに1つで、送信用サブドメインはこれを継承します。p=noneから始めてください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Customer.ioの設定がこの上限のうち何回を消費するかは、次のとおりです。
Customer.ioは10回のルックアップのうち3回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Customer.ioのDKIMは、自分で公開するTXTレコードであり、委任されたCNAMEレコードではありません。送信ドメインを追加すると、Customer.ioがDKIM鍵ペアを生成し、DKIMのTXTレコードを1つ表示します。ホストは送信用サブドメイン配下のセレクター（selector._domainkey.mail.yourbrand.comなど）、値はv=DKIM1; k=rsa; p=<public key>です。表示されたとおりにTXTを貼り付けてください。対応する秘密鍵はCustomer.ioが保持し、送信メールにd=yourbrand.comで署名します。そのため署名は自社ドメインとアライメントが一致し、DMARCの成功を担えます。SendGridやMicrosoft 365が使うCNAMEによる委任型のDKIMとは、次の2点が異なります。第1に、サービス側を指すCNAMEではなく静的なTXTレコードのため、Customer.ioが裏側で鍵を黙ってローテーションすることはありません。ダッシュボードで鍵を再生成またはローテーションした場合は、新しいTXTの値を自分で公開し直さないと署名が機能しなくなります。第2に、ここでのDKIMは任意でもベストエフォートでもありません。Customer.ioがドメインから送信するには、SPFとDKIMの両方の確認が必須です。DKIMのTXTが欠落していたり、途中で切れていたり、DNS管理画面で崩れていたりすると、ドメインは未確認に戻り、配信が止まります。Customer.ioの形式どおりに送信用サブドメインへレコードを公開し、反映を待ってからVerifyをクリックしてください。
DMARC
DMARCは別のポリシーレコードで、Customer.ioは作成しないため、自分で公開します。置く場所は送信用サブドメインではなくルートドメインです。_dmarc.yourbrand.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.comで始まるTXTレコードを追加します。p=noneは監視のみのため配信には何も影響せず、その間に受信側から集計レポート（rua）がメールで届くので、Customer.ioのメールがSPFとDKIMの両方に、自社ドメインとアライメントが一致した状態で成功していることを確認できます。ここでCustomer.ioのサブドメイン設計が生きてきます。DMARCのデフォルトは緩和されたアライメント（aspf=r、adkim=r）のため、mail.yourbrand.comのDKIM署名も、そのサブドメイン上のSPF/Return-Pathも、組織ドメインyourbrand.comとアライメントが一致し、Customer.ioのメールは両方の仕組みでDMARCに成功します。ルートドメインの_dmarcレコードは1つだけにしてください。送信用サブドメインは親のポリシーを自動で継承するため、サブドメインに2つ目の_dmarcレコードを追加しないでください（よくある間違いで、継承を壊すおそれがあります）。1～2週間、ruaレポートを確認し、正規の送信元すべて（Customer.ioと他の送信者）が認証されるようになったら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。
正しく設定できたか確認する
ダッシュボードのチェックマークだけで判断せず、実際のメールで確認してください。Customer.ioのAuthenticationタブでは、SPFとDKIM（Customer.ioが送信の条件にしている2つのレコード）に緑のチェックマークが付いていることを確認します。MXレコードはReturn-Pathを、CNAMEレコードはブランド化されたリンクを支えるものです。続いて、認証済みサブドメインのFromアドレスからブロードキャストまたはキャンペーンを送信し、Gmailで開いて⋮ → Show originalを選びます。確認する項目は次のとおりです。SPF: PASSでエンベロープ/Return-Pathが自社サブドメイン上にあること、DKIM: PASSでd=yourbrand.comの署名があること（失敗の典型的な兆候はd=customeriomail.comで、カスタムDKIMが反映されていないことを意味します）、DMARC: PASSであることです。レコード自体はdig TXT mail.yourbrand.com、dig TXT selector._domainkey.mail.yourbrand.com、dig TXT _dmarc.yourbrand.comで確認できます。最後に、Qualisendのドメイン診断で送信用サブドメインをチェックし、SPF（ネストしたルックアップを含む）、DKIMのTXT、MX、ルートドメインのDMARCがすべて正しく解決されることを確かめます。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Customer.ioが、アライメントが一致し、認証に成功している送信元として表示されるはずです。
よくある注意点
- 認証失敗の原因
Customer.ioは、ドメインから送信する前にSPFとDKIMの両方の確認を必須としています。多くのESPは一部の認証だけでも送信しますが、Customer.ioは違います。どちらかのレコードが欠落したり崩れたりすると、ドメインは未確認と表示され、ブランド表示の問題にとどまらず配信に失敗します。
- DNS設定
すべて専用の送信用サブドメイン（mail.yourbrand.com）に公開し、ルートドメインには決して置かないでください。特に、2つのホスト名を持つMXレコードは必ずサブドメインに置きます。ルートドメインに置くと、ドメイン全体のバウンス処理が切り替わり、実際の受信メールも危険にさらされます。
- 適用範囲
このMXレコードは通常のメールを受信するためのものではありません。バウンスと迷惑メール報告のフィードバック用に、自社ドメイン上のカスタムReturn-PathをCustomer.ioに与えるためだけのものです。「MXを変更してしまう」と慌てる必要はありません。人が使うメールボックスのないサブドメイン上のレコードです。
- DNS設定
include:customeriomail.comのDNSルックアップは1回ではありません。ライブで調べるとinclude:sendgrid.netをネストし、それがさらにinclude:ab.sendgrid.netをネストしているため、約3回になります。専用のサブドメインなら影響は切り離されますが、共有のルートドメインのSPFレコードにまとめると、10回制限を他のすべての送信者と奪い合うことになります。
- DNS設定
ここでのDKIMは静的なTXTレコードであり、自動でローテーションされるCNAMEレコードではありません。Customer.ioは代わりにローテーションしないため、ダッシュボードで鍵を再生成した場合は、新しいTXTの値を公開し直さないと署名が機能しなくなります。
- DNS設定
サブドメインでのホスト欄の二重化：多くのレジストラはゾーンを自動で付加するため、mail.yourbrand.comと入力するとmail.yourbrand.com.yourbrand.comになります。ドメインが自動で付加される場合は、管理画面が求めるラベル（mail、selector._domainkey.mail）だけを入力してください。
- 適用範囲
DMARCはルートドメイン（_dmarc.yourbrand.com）に置き、送信用サブドメインには置かないでください。サブドメインは緩和されたアライメントによりルートドメインのポリシーを継承します。サブドメインに2つ目の_dmarcを追加するのはよくある間違いで、継承を壊すおそれがあります。
- DNS設定
リンクトラッキング用のCNAMEレコードを省略しても認証には問題ありませんが、クリック計測付きリンクは自社ドメインではなくcustomeriomail.comのままになります。ブランドの一貫性が弱まり、受信者やフィルターからの信頼性が下がって見えることがあります。
SPFレコードを作成
Customer.ioでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Customer.ioのSPFに関するよくある質問
関連記事
マーケティング・ESPの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。