GetResponseのSPF・DKIM・DMARC設定。
GetResponseでは、Profile → Emails and domainsから送信ドメインを認証します。CNAMEによる委任を使うメール配信サービス（ESP）とは手順が異なり、GetResponse内でDKIM鍵を生成してTXTレコードとして公開し、必要に応じてGetResponseの共有SPFのinclude（include:_spf.getresponse.com）を追加し、DMARCポリシーレコードは自分で追加します。45以上のDNSホストに対応した自動（Entri）連携で、3つのレコードすべてをGetResponseに書き込んでもらうことも、手動で追加することもできます。DKIMのTXTレコードが解決されてGetResponseが確認すると、ニュースレターやオートメーションが自社ドメインとして署名され、DKIMのアライメントによってDMARCに成功します。未認証のメールで受信者に表示される「sent on behalf of」やvia-getresponseの表記も消えます。
GetResponseを認証すべき理由
GetResponseのドメイン認証は、キャンペーンが受信トレイに届くか、迷惑メールフォルダーに振り分けられるかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail/Liveの個人向け受信トレイへ同じ要件を広げました。いずれも、多くのニュースレターが読者としている層そのものです。GetResponseは現在、すべての送信者に対し、Fromアドレスには自社の独自ドメインのアドレスを使い（gmail.comやyahoo.comはブロックまたは格下げの対象です）、DKIMとDMARCの両方を設定するよう強く勧めています。認証が済むまで、GetResponseは自身の署名ドメインで送信します。受信者には、実際には自社から送られたメールではないことがわかり、Fromアドレスのアライメントは一致せず、DMARCにも成功できません。レピュテーションも、プラットフォーム上の他の未認証の送信者全員と共有されます。GetResponse特有の事情として、DKIMは省略できません。GetResponseは送信メールに自身のReturn-Path（バウンス用ドメイン）を使い続けるため、SPFはGetResponseのドメインに対して評価され、Fromドメインとアライメントが一致することはないからです。DMARCの成功を担える仕組みは、d=yourdomain.comとして署名されたDKIMだけです。DKIM鍵を省略すると、SPFチェックの見え方にかかわらず、アライメントの一致した認証がまったくない状態になります。
GetResponseにおけるSPFの実情
GetResponseは確かに「include」を使うサービスで、共有のメカニズムはinclude:_spf.getresponse.comです。ただしGetResponseでは、SPFは設定の中で任意の部分であり、要となる部分ではありません。GetResponseの公式ドキュメントでは、SPFレコードは「推奨されるが、送信に必須ではない」とされ、その理由も「送信ドメインはGetResponseであり、すでにSPF署名済みである」と明記されています。GetResponseはエンベロープ送信者/Return-Pathを自身のバウンス用ドメインのままにする（バウンスを処理するのは利用者ではなくGetResponseです）ため、SPFは常にGetResponseのドメインに対してチェックされます。その結果、チェック自体には単独で成功しますが、Fromドメインとアライメントが一致することはありません。DMARCがSPFを評価するのは、アライメントが一致する場合だけです。GetResponseの認証フローがDKIMのTXT鍵とDMARCレコードを中心に組まれているのはそのためで、d=yourdomain.comとして署名されたDKIMがアライメントを一致させ、DMARCの要件を満たします。したがって、ルートドメインのincludeは、一部の受信フィルターが歓迎するクリーンな成功を得るための、GetResponseのIPを許可する便利なメカニズムと考えてください。DMARCを機能させるものではなく、追加が必須なものでもありません。追加する場合、コストはわずかです。include:_spf.getresponse.comは、ネストしたincludeのない、ip4:の範囲だけのフラットなレコード1つに解決されるので、10回のSPF DNSルックアップのうちちょうど1回しか消費しません。2つ目のSPF TXTを公開するのではなく（SPFレコードが2つあるとPermErrorになります）、ルートドメインの1つのv=spf1レコードの中で、末尾の~allより前にまとめてください。DMARCの実質的な役割はDKIMに任せます。
2つの設定方法
自動認証（Entri）
- GetResponseがDNSホストを検出し、利用者がホストにログインすると、DKIM鍵、SPFレコード、p=noneのDMARCレコードを代わりに書き込みます
- Cloudflare、GoDaddy、Namecheap、AWS Route 53、SiteGroundを含む45以上のサービスに対応しています
- 特によくある2つの失敗を防げます：ホスト欄のドメイン重複とDKIM鍵の途中切れ
- DNSホストのログイン情報を管理していて、最も速くミスの少ない方法を選びたい場合に最適です
手動：「I'll do it myself」
- GetResponseが、コピーするDKIM identifierと鍵、SPFの値、DMARCレコードを表示します
- レジストラで自分で貼り付けます。DNSを他の人が管理している場合や、ホストがEntriに対応していない場合に必要です
- DKIMのTXTレコード（セレクターと2048ビット鍵の全体）を正確に追加する必要があります。そうしないとGetResponseは確認できません
- 最終的なレコードは自動の場合と同じで、手動で追加するだけの違いです
設定手順
- 1
Emails and domainsを開く
ログインしてProfile → Emails and domainsを開きます（新しいUIではTools → Emails and domainsです）。この1つの画面で、確認済みのFromアドレスとドメイン全体の認証の両方を管理します。まず自社ドメインのFromアドレスを追加して確認してください。未確認のドメインや、gmail.com/yahoo.comのような無料の公開ドメインからの送信は、GetResponseでは認められません。
- 2
ドメインの認証を開始
Email addressesタブの一覧で自社ドメインを探し、その横のActionsメニュー（3つの点）をクリックして、Authenticateを選びます（古いアカウントでの表示はView TXT records → Authenticate your domain with DKIM）。GetResponseが鍵を生成する認証パネルが開きます。
- 3
自動か手動かを選択
「Authenticate automatically」を選ぶと、GetResponseのEntri連携がDNSホストにログインし、DKIMレコード、SPFレコード、（既存のものがなければ）p=noneのDMARCレコードを代わりに公開します。「I'll do it myself」を選ぶと、レコードが表示されるので、レジストラで貼り付けます。どちらの方法でも作成されるDNSレコードは同じです。
- 4
DKIM鍵を生成してコピー
手動の場合、GetResponseにDKIM identifierとDKIM keyが表示されます。identifierはドメインごとに固有のセレクター（短い16進文字列）で、レコードのホストになります。keyは長い公開鍵の値です。スライダーを「Generate a 2048-bit DKIM key for stronger protection」（GetResponseの推奨）に動かし、両方のフィールドを正確にコピーしてください。identifierの1文字が欠けるだけでも失敗するケースはよくあります。
- 5
DKIMのTXTレコードを公開
DNSホストでTXTレコードを追加します。ホストは<your-identifier>._domainkey（例：1a2b3c4d._domainkey）です。値はGetResponseから提示されたDKIM keyで、k=rsa; p=… / v=DKIM1; k=rsa; p=…で始まります。タイプはTXTのままにしてください。GetResponseのDKIMは自分で公開する鍵であり、CNAMEによる委任ではありません。ホストでTXT文字列が255文字に制限されている場合は、2048ビット鍵の全体が保存されていることを確認してください（必要なら引用符で囲んだ文字列に分割します）。そうしないと一部しか公開されません。
- 6
（任意）SPFのincludeを追加（既存なら1つにまとめる）
GetResponseでは、SPFは推奨ですが必須ではありません。追加する場合は、ルートドメインの1つのv=spf1 TXTレコードの中で、末尾の~allより前にinclude:_spf.getresponse.comを入れます（例：v=spf1 include:_spf.getresponse.com ~all）。既存のSPFレコードがある場合（Google Workspace、Microsoft 365など）は、includeをその1行にまとめてください。SPF TXTを2つ公開することは絶対に避けてください。DNSルックアップの消費は1回だけです。
- 7
DMARCレコードを追加
手動の場合、GetResponseはDMARCレコードを代わりに作成しません。ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加します。p=noneは監視のみなので、アライメントを確かめている間も配信には何も影響しません。_dmarcレコードはドメイン全体で1つだけにしてください。
- 8
GetResponseによるドメインの確認を待つ
DNSの変更が反映されるまで、最大24～48時間かかることがあります。GetResponseは自動で再チェックを行い、DKIMレコードを検出するとドメインをAuthenticatedに切り替えます。何もクリックする必要はありませんが、Actionsメニューを開き直して再チェックすることもできます。反映を手早く確かめる方法として、GetResponseは自分宛てにニュースレターを送ることも勧めています。
- 9
実際のメールのヘッダーを確認
テストキャンペーンをGmailのアドレスに送って開き、⋮ → Show originalを使います。d=yourdomain.com（GetResponseのセレクター経由）でDKIM: PASSとなり、DMARC: PASSと表示されていれば成功です。SPFはGetResponseのReturn-Pathドメインに対する成功として表示されますが、これは想定どおりです。ここでDMARCを担うのはDKIMのアライメントです。
- 10
認証済みのFromアドレスから送信
メッセージとリストの設定で、Fromアドレスが認証済みドメインのものになっていることを確認してください。これにより、メールが実際に自社ドメインとしてDKIM署名されます。別のアドレスや未確認のアドレスから送信する設定のままのキャンペーンには、DNSの認証は何の効果もありません。
追加するレコード
正確な値はGetResponseのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | 1a2b3c4d._domainkey | k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from GetResponse)DKIMの値は例です。ホストのラベル（セレクター）はGetResponseがドメインごとに生成する固有の識別子です。正確なidentifierと鍵はAuthenticateパネルからコピーしてください。これは自分で公開するTXTレコードで、CNAMEではありません。GetResponseでは値がk=rsa; p=で始まって表示される場合があります（v=DKIM1; k=rsa; p=と同等です）。 |
| TXT | @ | v=spf1 include:_spf.getresponse.com ~all任意です。include:_spf.getresponse.comはルートドメインの1行のSPFレコードにまとめ、2つ目のSPFレコードは絶対に追加しないでください。ip4のみのフラットなレコードに解決されるので、DNSルックアップの消費は1回です。GetResponseのIPを許可しますが、アライメントは一致しません（Return-PathはGetResponseが持ち、そちら側ですでにSPF署名済みです）。DMARCの成功を担うのはDKIMであり、このレコードをまったく使わない送信者も多くいます。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します（自動/Entriの場合は、既存のレコードがなければp=noneのレコードが追加されます）。ドメインごとに1つだけです。p=noneから始め、GetResponseのメールがアライメントの一致した状態で成功するようになったら、quarantine/rejectへ引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。GetResponseの設定がこの上限のうち何回を消費するかは、次のとおりです。
GetResponseは10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
DKIMは、自社ドメインと実際にアライメントが一致する仕組みであり、GetResponseの認証の中核です。CNAMEによる委任を使うESP（Mailchimp、SendGrid）とは異なり、GetResponseは鍵を生成し、自分で公開するTXTレコードを提示します。提示されるのは、DKIM identifier（短い16進文字列で示される、ドメインごとに固有のセレクター）とDKIM key（公開鍵の値）です。ホストを<identifier>._domainkey.yourdomain.comとし、GetResponseから提示された値を設定したTXTレコードを公開します。この値はk=rsa; p=…で始まります（標準のv=DKIM1; k=rsa; p=…の形式と同等です）。対応する秘密鍵はGetResponseが保持して送信メールに署名するので、レコードが解決されるとキャンペーンはd=yourdomain.comとして署名され、DKIMのアライメントによってDMARCに成功できるようになります。従来の1024ビット鍵ではなく、GetResponseが用意している2048ビットのオプションを選んでください。GetResponseの公式ドキュメントが指摘している固有の注意点は2つあります。1つ目は、2048ビットの鍵は255文字のTXT文字列1つより長いため、一部のホストでは「DKIMレコードの一部だけ」が公開されることです。ホストが鍵やTXTの長さを制限していると鍵が途中で切れてDKIMが失敗するので、値全体を保存してください（管理画面で必要なら、引用符で囲んだ文字列に分割します）。2つ目は、セレクターが生成された識別子であるため、「正しいセレクターの最後の1文字が欠けた」名前（例：4e4a47ebではなく4e4a47eと公開する）ではセレクターが一致せず、検証が何の警告もなく失敗するとGetResponseが注意を促していることです。両方のフィールドをそのままコピーしてください。CNAMEも「Start signing」のトグルもありません。GetResponseは24～48時間以内にレコードを自動で検出し、ドメインをAuthenticatedとして表示します。
DMARC
DMARCは、ドメインに設定する別のTXTポリシーレコードです。手動の場合、GetResponseは代わりに作成しません（自動/Entriの場合は、既存のレコードがなければp=noneのレコードを追加します）。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるレコードを公開します。p=noneは監視のみで配信には何も影響しないので、その間に集計レポート（rua）を確認し、GetResponseのメールが自社ドメインとアライメントの一致したDKIMで成功していることを確かめます。SPFのアライメントが一致するサービスと比べて、GetResponseではこの確認がより重要です。Return-PathをGetResponseが持つので、DMARCの成功はすべてDKIMにかかっています。ポリシーを引き上げる前に、集計レポートでDKIMのアライメントが確実に一致していることを確かめてください。1～2週間レポートを確認し、GetResponseと他の正規の送信者がすべて認証に成功していることを確かめたら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。厳格なアライメント（adkim=s / aspf=s）に触れた情報を目にするかもしれませんが、特別な理由がなければ緩和されたアライメント（デフォルト）のままにしてください。緩和されたアライメントでも組織ドメインの一致は必要で、サブドメインに対してより柔軟です。送信者がいくつあっても、_dmarcレコードはドメイン全体で1つだけにし、GetResponse用に2つ目のDMARCレコードを追加しないでください。
正しく設定できたか確認する
GetResponseの「Authenticated」のバッジだけで判断せず、実際のメールで確認してください。テストキャンペーン（または自分宛ての通常のニュースレター）をGmailのアドレスに送って開き、⋮ → Show originalを選びます。GetResponseのセレクターを使ったsigned-by / d=yourdomain.comの署名でDKIM: PASSとなり、DMARC: PASSと表示されていれば成功です。SPFはGetResponse自身のReturn-Pathドメインに対する成功として表示されますが、これは想定どおりで問題ありません。ここでDMARCを成功させるのはDKIMのアライメントなので、SPFに自社ドメインが表示されなくても心配はいりません。dig TXT <identifier>._domainkey.yourdomain.com、dig TXT _dmarc.yourdomain.comで、レコードそのものを個別に確認することもできます。続いて、Qualisendのドメイン診断でドメインをチェックし、DKIMのTXT、任意のSPFのinclude、DMARCレコードがすべて正しく解決され、SPFがDNSルックアップの10回制限内に収まっていることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。GetResponseは、DKIMでアライメントが一致して成功している送信元として表示されるはずです。
よくある注意点
- 適用範囲
SPFに成功してもアライメントは一致しない：GetResponseは自身のReturn-Path/バウンス用ドメイン（GetResponse側ですでにSPF署名済み）を使います。そのためinclude:_spf.getresponse.comはGetResponseのIPを許可してSPFのチェック自体を成功させますが、Fromドメインとのアライメントは一致しません。DMARCの成功を担える仕組みはDKIMだけです。SPFで足りると考えてDKIM鍵を省略しないでください。
- DNS設定
DKIM鍵の途中切れ：2048ビットの鍵は255文字のTXT文字列1つより長く、一部のホストでは「DKIMレコードの一部だけ」が公開されるとGetResponseは警告しています。値全体を保存してください（管理画面で必要なら、引用符で囲んだ文字列に分割します）。そうしないとDKIMの検証に失敗します。
- 適用範囲
セレクターの不一致：DKIMのホスト名は生成された識別子で、GetResponseは「正しいセレクターの最後の1文字が欠けた」名前（例：4e4a47ebではなく4e4a47e）について明確に警告しています。入力ミスや途中で切れたidentifierは、何の警告もなく検証に成功しないままになるので、そのままコピーしてください。
- DNS設定
ホスト欄のドメイン重複：多くのレジストラはドメインを自動で付加するため、1a2b3c4d._domainkey.yourdomain.comと入力すると1a2b3c4d._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、ラベル（1a2b3c4d._domainkey）だけを入力してください。
- 適用範囲
無料/公開のFromアドレスはブロックされる：GetResponseは、gmail.com、yahoo.com、outlook.comなどの認証も、これらからの確実な送信もできません。自社ドメインのアドレスから送信する必要があります。それこそが認証の目的です。
- DNS設定
DKIMはTXTレコードであり、CNAMEではない：MailchimpやSendGridとは異なり、GetResponseでは固定の鍵を貼り付けます。委任するCNAMEはなく、鍵の自動ローテーションもないので、鍵を再生成した場合はTXTレコードを自分で更新する必要があります。
- 認証失敗の原因
SPFレコードは1つだけにする：Google Workspace、Microsoft 365、その他のツールからも送信している場合は、include:_spf.getresponse.comを既存のv=spf1の行にまとめてください。同じドメインにSPFのTXTレコードが2つあるとPermErrorになり、SPF全体が機能しなくなります。
- 適用範囲
自動（Entri）認証は一部だけ失敗することがある：連携先のDNSホストがAPIによる変更を拒否すると、GetResponseが一部のレコードだけを追加したり、残りを手動で完了するよう求めたりする場合があります。自動実行の後は、3つのレコードすべてがホストに実際に存在するか確認し直してください。
SPFレコードを作成
GetResponseでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証GetResponseのSPFに関するよくある質問
関連記事
マーケティング・ESPの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。