Constant ContactのSPF・DKIM・DMARC設定。
Constant Contactは、同社が「self-authentication」と呼ぶ方法でドメインを認証します。これは貼り付ける共通のSPFレコードではなく、DKIMベースのフローです。プロフィール名（右上）-> My Account / Account settingsをクリックし、Advanced settingsタブを開いてAdd self-authenticationをクリックします。そこで「Self-authenticate using DKIM CNAME records」（推奨）を選ぶと、DKIM署名をConstant Contactのccsend.comインフラに委任する2つのCNAMEレコードと、初期設定用のDMARCレコードが提供されます。各CNAMEは自社ドメイン上のctct1._domainkey / ctct2._domainkeyセレクターとして設定され、dkim1.ccsend.com / dkim2.ccsend.comにあるConstant Contactのローテーションされる署名鍵を指します。これらが解決されるようになってActivateをクリックすると、キャンペーンは自社ドメインとして署名されるようになり、DKIMのアライメントによってDMARCに成功します。未認証のConstant ContactのメールにGmailが付ける「via ccsend.com / on behalf of」の表示も消えます。ルートドメインに追加して意味のあるSPFのincludeはなく、重要な点として、追加してもDMARCに成功するようにはなりません。
Constant Contactを認証すべき理由
Constant Contactのself-authenticationは形式的な作業ではなく、キャンペーンが受信トレイに届くかどうかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、大量送信者を対象として、同じルールを同社の個人向け受信トレイ（Outlook、Hotmail、Live）に拡大しました。self-authenticationを完了するまで、Constant Contactは自身の共有ドメインで送信します。受信者には、そのメールが暗号学的に自社ドメインから送られたものであることが示されず、Fromアドレスのアライメントは一致せず、DMARCに成功できず、送信者レピュテーションは未認証のConstant Contact送信者全員と共有されます。ここにはDKIMを欠かせないものにするConstant Contact特有の事情もあります。Constant ContactはReturn-Pathを自身のバウンス用ドメイン（有料アカウントはshared1.ccsend.com、トライアルはshared2.ccsend.com）に置いたままにするため、SPFは常にccsend.comに対して評価され、Fromドメインとアライメントが一致することはありません。DMARCの成功を支えられるメカニズムは、自社ドメインとして署名されたDKIMだけです。self-authenticationを省略すると、アライメントが一致した認証は1つもなくなります。2024年2月以降、Constant Contactはself-authentication済みのドメインにデフォルトでDKIM署名を行うため、このフローを完了することで、そのドメインの署名が有効になります。
Constant ContactにおけるSPFの実情
Constant ContactはDKIM CNAMEで認証するサービスです。ここは古いチュートリアルのほとんどが誤解している点です。共通のincludeであるspf.constantcontact.comは実在します（実際に解決され、v=spf1 ip4:208.75.120.0/22 ip4:205.207.104.0/22 ~allを返します。ネストしたincludeのない、DNSルックアップ1回のレコードです）。しかし、これをルートドメインのSPFレコードに追加してもDMARCには効果がありません。バウンスを処理するのは自社ではなくConstant Contactであるため、すべてのキャンペーンはエンベロープ送信者/Return-PathをConstant Contact自身のバウンス用ドメイン（有料アカウントはshared1.ccsend.com、トライアルはshared2.ccsend.comで、どちらもccsend.comの下で許可されています）にして送信されます。SPFは常にこのエンベロープのドメインに対してチェックされるので、Constant Contactのサーバーに対して解決され、成功もしますが、組織のFromドメインとアライメントが一致することはありません。DMARCがSPFを評価するのはアライメントが一致している場合だけです。だからこそ、Constant Contactのself-authenticationフローはDKIM CNAMEとDMARCレコードを求め、SPFの変更は一切求めません。アライメントが一致してDMARCの成功を支えるメカニズムは、d=yourdomain.comとして署名されたDKIMです。spf.constantcontact.comはルートドメインのSPFレコードに追加しなくても問題ありません。Constant ContactのIPに対してチェック自体には成功しますが、DMARCのアライメントにはまったく役立たず、10回のルックアップのうち1回を消費します。ルートドメインのSPFレコードは、Return-Pathに実際に自社ドメインが入る送信元（Google Workspace、Microsoft 365、トランザクションメールのリレー）のために確保し、Constant ContactについてはDKIMに任せてください。
2つの設定方法
DKIM CNAMEによるself-authentication（推奨）
- 2つのCNAMEレコード（ctct1._domainkey / ctct2._domainkey）で、DKIMをConstant Contactのccsend.comの署名鍵に委任します
- 秘密鍵の保持と、これらのセレクターの背後にある鍵のローテーションはConstant Contactが行います。DNSを再度編集する必要はありません
- 最もシンプルで安全な方法であり、Constant Contactが推奨するオプションです
- ルートドメインのSPFレコードのDNSルックアップを消費しません。CNAMEはカウントされず、まとめるものもありません
DKIM TXTレコード（鍵を手動で管理）
- Constant Contactが公開鍵と秘密鍵のペアを生成し、アカウント固有の数字のセレクター（10008432._domainkeyなど）を持つTXTレコードを1つ表示します
- v=DKIM1; k=rsa; p=...の公開鍵全体を自分で貼り付けます
- 鍵の自動ローテーションはありません。鍵が変わった場合は公開し直す必要があり、古い鍵のままだとDKIMが気づかないうちに機能しなくなります
- DNSホストがどうしてもCNAMEの委任を追加できない場合にのみ検討する価値があります
設定手順
- 1
self-authenticationを開く
サインインし、プロフィール名（右上）-> My Account / Account settingsをクリックして、Advanced settingsタブを開き、Add self-authenticationをクリックします。画面を見失った場合は、Account settings -> Advanced settings -> self-authenticateから戻れます。
- 2
CNAME方式を選択
「Self-authenticate using DKIM CNAME records」を選択し、Continueをクリックします。Constant Contactが鍵のローテーションを管理するため、こちらが推奨です。「Self-authenticate using a DKIM TXT record」を選ぶのは、DNSホストがCNAMEを追加できない場合だけにしてください。
- 3
送信ドメインを選択
キャンペーンのFromアドレスと一致するドメイン（例：yourdomain.com）を選びます。self-authenticationはドメインごとに行うので、送信に使うドメインを正確に選び、Continueをクリックしてレコードを表示します。
- 4
2つのCNAMEレコードをコピー
Constant ContactにCNAME 1とCNAME 2が表示されます。それぞれ自社ドメイン上のName/Host（ctct1._domainkey / ctct2._domainkeyセレクター）と、Constant Contactの署名インフラを指すValue（100._domainkey.dkim1.ccsend.com / 200._domainkey.dkim2.ccsend.com）があります。手入力せず、両方を画面から正確にコピーしてください。
- 5
DKIM CNAMEを2つ追加
DNSホストで、それぞれをCNAMEレコードとして作成します。ホストはConstant Contactが表示するctct1/ctct2の_domainkeyラベル、値は対応する*.dkim*.ccsend.comのターゲットです。タイプはCNAMEのままにしてください（AやTXTにはしません）。レジストラがドメインを自動で追加する場合は、二重にならないようセレクターのラベルだけ（例：ctct1._domainkey）を入力します。
- 6
DMARCレコードを公開
Constant Contactのフローでは、初期設定用のDMARC TXTレコード（多くの場合v=DMARC1; p=none;のみ）も提供されます。ホスト_dmarcに追加します。rua=mailto:dmarc@yourdomain.comを追加すると、集計レポートを受け取れます。この手順を省略するのは、すでに_dmarcレコードがある場合だけです。1つのドメインに置けるのは1つだけです。
- 7
Cloudflareのプロキシをオフにする
DNSがCloudflare配下にある場合は、各DKIM CNAMEを「DNS only」（グレーのクラウド）に設定します。オレンジのクラウドでプロキシが有効なCNAMEはccsend.comに解決されず、Constant ContactのCheck status / Activateの手順が失敗します。これはConstant ContactとCloudflareの組み合わせでよく報告される問題です。
- 8
Check statusの後でActivateをクリック
self-authenticationの画面に戻ってOkをクリックします。DNSの反映を約24～48時間待ってから、Check statusをクリックします。CNAMEが解決されたら、ActivateをクリックしてドメインのDKIM署名を有効にします。早すぎるクリックは避けてください。フローをやり直すのではなく、反映後に再度確認します。
- 9
認証済みドメインから送信してヘッダーを確認
認証済みドメインのアドレスから実際のキャンペーンまたはテストを送り、Gmailで開いて三点メニュー -> Show originalを使います。DKIM: PASSかつd=yourdomain.com（ccsend.comではなく）とDMARC: PASSを確認してください。SPFにはccsend.com/共有のドメインが表示され、アライメントは一致しません。これは想定どおりで、成功を支えるのはDKIMです。
追加するレコード
正確な値はConstant Contactのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| CNAME | ctct1._domainkey | 100._domainkey.dkim1.ccsend.comDKIM鍵1。自社ドメインのctct1セレクターは、dkim1.ccsend.comにあるConstant Contactの自動ローテーションされる共有署名鍵に委任するCNAMEです。値は例です。正確なName/Valueはself-authenticationの画面からコピーしてください。 |
| CNAME | ctct2._domainkey | 200._domainkey.dkim2.ccsend.comDKIM鍵2。2つ目の委任CNAME（ctct2）でConstant Contactのdkim2.ccsend.comの鍵を指すことで、DNSを編集しなくてもConstant Contactが鍵をローテーションできます。例です。正確な値はアカウントに表示されたものをコピーしてください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCポリシー。Constant Contactのフローでは初期設定用のレコード（多くの場合v=DMARC1; p=none;のみ）が提供されます。rua=を追加すると集計レポートを受け取れます。_dmarcレコードは1つのドメインにつき1つだけにし、p=noneから始めて後で引き上げます。 |
| TXT | 10008432._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(public key from Constant Contact)代替のDKIM TXT方式専用です。この場合のセレクターはアカウント固有の数字です（Constant ContactはTXTに10008432のような数字のセレクターを使います）。鍵の自動ローテーションはありません。CNAMEを追加できない場合にのみ使用してください。これとCNAMEの両方を追加しないでください。 |
| TXT | @ | v=spf1 include:spf.constantcontact.com ~all従来方式で任意です。推奨せず、必要もありません。Return-Path（shared1/shared2.ccsend.com）はConstant Contactが所有しているため、成功してもアライメントは一致せず、DMARCには効果がないうえ、SPFのルックアップを1回消費します。追加せず、DKIMに任せてください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Constant Contactの設定がこの上限のうち何回を消費するかは、次のとおりです。
Constant Contactの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
Constant ContactではDKIMがすべてです。自社ドメインとのアライメントを一致させられる唯一のメカニズムであり、設定方法は2つあります。推奨はDKIM CNAMEによるself-authenticationです。Constant Contactから2つのCNAMEレコードが提供され、ホストは自社ドメイン上のctct1._domainkey / ctct2._domainkeyセレクター、値は署名インフラの100._domainkey.dkim1.ccsend.com / 200._domainkey.dkim2.ccsend.comを指します。これらのホストは貼り付けるTXTレコードではなくCNAMEなので、Constant Contactが秘密鍵を保持し、共有セレクターの背後で公開鍵をローテーションします。DNSを再び変更する必要はありません。Constant Contactがこれを最もシンプルで安全な方法とし、「manages key rotation for you」と説明しているのはこのためです。もう1つはDKIM TXT方式です。Constant Contactが公開鍵と秘密鍵のペアを生成し、1つのTXTレコードを表示します。ホストは10008432._domainkeyのようなアカウント固有の数字のセレクターで、値はv=DKIM1; k=rsa; p=<public key>です。これを貼り付けますが、Constant Contactがローテーションすることはできません。鍵が変わった場合はTXTを公開し直す必要があり、古い鍵のままだとDKIMが気づかないうちに機能しなくなります。そのため、DNSホストが委任に対応していない場合を除き、CNAME方式を選んでください。どちらの場合も、レコードを公開して約24～48時間待ち、Check statusをクリックしてからActivateをクリックします。署名はドメインをActivateして初めて始まります。その後、Constant Contactはd=yourdomain.comでメールに署名し（署名にはs=ctct1が含まれます）、DKIMのアライメントが一致してDMARCの成功を支えます。正確なホストラベルと値はself-authenticationの画面に表示されるので、チュートリアルの例を流用せず、必ずコピーしてください。
DMARC
DMARCはドメインに設定する別のポリシーレコードですが、Constant Contactはこの点で珍しく親切です。多くのメール配信サービス（ESP）とは異なり、self-authenticationのフローで公開できる初期設定用のDMARCレコードが提供されます。_dmarc.yourdomain.comに、v=DMARC1; p=none;で始まるレコードを追加します（集計レポートを受け取るにはrua=mailto:dmarc@yourdomain.comを追加します）。p=noneは監視のみのため、配信には影響しません。その間に集計レポート（rua）を確認し、メールが認証されていることを確かめます。Constant Contact特有の理解すべき点は、Constant ContactのアライメントはDKIMでしか一致しないことです。SPFはccsend.comのバウンス用ドメインに対して評価され、アライメントが一致することはないので、DMARCの成功は完全にDKIMに依存します（デフォルトの緩和されたアライメントではDKIMのd=yourdomain.comが組織ドメインと照合され、署名ドメインが自社ドメインそのものであるため厳格なアライメントでも機能します）。1～2週間レポートを確認し、Constant Contactと他のすべての正当な送信者がアライメントの一致したDKIMに成功していることを確かめてから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。送信者がいくつあっても、_dmarcレコードはドメイン全体で1つだけにしてください。すでに_dmarcレコードがある場合は、Constant Contactのレコードを2つ目として追加せず、既存のレコードが設定され、このメールを対象にしていることを確認します。
正しく設定できたか確認する
Constant Contactの「Activated」のバッジだけで判断せず、実際のメールで確認してください。self-authentication済みのドメインのアドレスからキャンペーンまたはテストを送り、Gmailで開いて三点メニュー -> Show originalを選びます。DKIM: PASSかつsigned-by / d=yourdomain.com（ccsend.comではなく）で、DMARC: PASSと表示されていれば成功です。SPFにはccsend.com/共有のバウンス用ドメインが表示され、アライメントは一致しません。Constant Contactで成功を支えるのはDKIMなので、これは想定どおりで問題ありません。実際のレコードも確認しましょう。dig CNAME ctct1._domainkey.yourdomain.comで100._domainkey.dkim1.ccsend.comのターゲットが返り、dig TXT _dmarc.yourdomain.comでポリシーが返るはずです。次に、Qualisendのドメイン診断でドメインをチェックし、両方のDKIMセレクターのCNAMEとDMARCレコードが正しく解決されることを確認します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Constant Contactが、DKIMのアライメントが一致した、成功している送信元として表示されるはずです（SPFのアライメントが一致しないのは、このサービスでは正常です）。
よくある注意点
- DNS設定
include:spf.constantcontact.comを追加してもDMARCには成功しません。Return-Path（有料はshared1.ccsend.com、トライアルはshared2.ccsend.com）はConstant Contactが所有しているため、SPFはccsend.comに対してチェックされ、自社ドメインとアライメントが一致することはありません。includeはチェック自体には成功しますが、DMARCには何も寄与せず、10回のルックアップのうち1回を無駄に消費します。アライメントが一致するメカニズムはDKIMだけなので、SPFは変更しないでください。
- DNS設定
Constant ContactはDKIMでしかアライメントが一致せず、SPFでは一致しません。そのためDMARCが失敗し続ける場合、修正すべきは常にDKIM（self-authenticationの公開とActivate）です。Constant Contactではエンベロープのドメインを自社で所有できないので、SPFのincludeやReturn-Pathの変更で解決しようとしないでください。
- DNS設定
Cloudflareのプロキシがあると機能しません。すべてのDKIM CNAMEを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはccsend.comに解決されず、Check statusとActivateが失敗します。これはConstant ContactとCloudflareの組み合わせで広く報告されている問題です。
- DNS設定
ホスト欄の二重化：多くのレジストラはドメインを自動で追加するため、ctct1._domainkey.yourdomain.comと入力するとctct1._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを追加する場合は、セレクターのラベルだけ（例：ctct1._domainkey）を入力してください。
- 適用範囲
Check statusをクリックする前に、DNSの反映を24～48時間待ってください。早すぎるとステータスチェックが失敗します。self-authenticationのフロー全体をやり直さず、反映後にCheck statusをもう一度実行してください。
- DNS設定
NameとValueはself-authenticationの画面から正確にコピーしてください。手入力したり、他のアカウントのものを流用したりしないでください。CNAME方式では、ホストはctct1._domainkey / ctct2._domainkeyセレクターで、Constant Contactの共有署名セレクター（100._domainkey.dkim1.ccsend.com / 200._domainkey.dkim2.ccsend.com）を指します。TXT方式では、セレクターはアカウント固有の数字（10008432._domainkeyなど）です。いずれの場合も値はアカウント固有であり、入力ミスや流用したレコードではDKIMが気づかないうちに失敗します。
- DNS設定
DKIM CNAME方式では鍵が自動的にローテーションされますが、DKIM TXT方式ではされません。TXTを選ぶと、今後鍵が変わった際に自分でレコードを公開し直す必要があり、古い鍵のままだとDKIMが気づかないうちに機能しなくなります。CNAME方式を選んでください。
- 認証失敗の原因
Fromアドレスのドメインそのものをself-authenticationの対象にし、ドメインごとに繰り返してください。yourdomain.comのレコードでは、サブドメインや別ブランドのドメインのFromは認証されません。送信ドメインごとに、独自のCNAMEとDMARCの適用範囲が必要です。
SPFレコードを作成
Constant Contactでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Constant ContactのSPFに関するよくある質問
関連記事
マーケティング・ESPの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。