SparkPostのSPF・DKIM・DMARC設定。
SparkPost（現在はBird（旧MessageBird）の一部）は、Configuration → Sending Domainsでドメインを認証します。ここで生成されるDKIM鍵を、送信ドメインにTXTレコードとして公開します。d=yourdomain.comで行われるこのDKIM署名こそが、DMARCの成功を実際に支える仕組みです。SPFにはSparkPost特有の注意点があります。デフォルトでは、バウンス／エンベロープのドメインとしてSparkPost自身の共有ドメイン（sparkpostmail.com）を使うため、通常のSPFチェックはSparkPostのドメインで成功しても、自社ドメインとアライメントが一致することはありません。解決策はカスタムのBounce Domainです。自社のサブドメインからsparkpostmail.comを指すCNAMEレコードで、これがReturn-Pathになるので、SPFのアライメントも一致します。DMARCポリシーのレコードを追加すれば、ルートドメインのSPFレコードに何も加えずに、3つすべてがアライメントの一致した状態で揃います。
SparkPostを認証すべき理由
SparkPostドメインの認証は形式的な作業ではなく、大量のトランザクションメールやマーケティングメールが受信トレイに届くかどうかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、個人向けのOutlook/Hotmail/Liveの受信トレイに同じ要件の適用を始めました。いずれも、SparkPostが想定している規模そのものです。認証を済ませるまで、SparkPostは共有鍵でメールに署名し、sparkpostmail.comからバウンスを処理します。Fromアドレスは暗号的に自社のものではなく、DMARCには成功できず、レピュテーションはそのインフラ上の未認証の他の送信者と一緒に集約されます。SparkPost特有の事情として、DKIM署名は欠かせません。デフォルトでReturn-PathをSparkPostが所有するため、SPFは成功しても自社ドメインとアライメントが一致せず、カスタムのバウンス用ドメインも設定するまでは、DMARCの成功を支える仕組みはDKIMだけです。DKIMとバウンス用ドメインを設定すれば、両方の仕組みのアライメントが自社に一致し、受信側が抱く身元への疑念が解消され、DMARCに成功し、共有プールではなく自社の名前で送信レピュテーションを築けます。
SparkPostにおけるSPFの実情
SparkPostは名目上は「include」型のサービスです。include:sparkpostmail.comとinclude:_spf.sparkpostmail.com（同一のレコードに解決されます）はいずれも実在し、DNSで確認できます。しかし、このincludeをルートドメインのSPFレコードに追加するのは従来方式で、DMARCの成功にはつながりません。理由は次のとおりです。実際のレコードはv=spf1 exists:%{i}._spf.sparkpostmail.com ~allで、これはexists:マクロにより、固定のip4:の範囲を列挙するのではなく、SparkPostの送信IPをIPごとに許可するものです（%{i}は送信IPで、ワイルドカードゾーンと照合されます）。SPFの評価は常にエンベロープのMAIL FROM、つまりReturn-Pathのドメインに対して行われ、そのドメインはデフォルトでSparkPostが所有するsparkpostmail.comです。そのため、SPFはSparkPostのドメインで解決されて成功しますが、Fromの組織ドメインとアライメントが一致することはなく、DMARCがSPFを考慮するのはアライメントが一致した場合だけです。自社のルートドメインにinclude:sparkpostmail.comを公開してもこれは変わりません。ルートドメインがエンベロープのドメインになることはないからです。SPFの10回のルックアップのうち2回（include自体と、sparkpostmail.comのレコード内にネストされたexists）を、アライメントの効果なしに消費するだけです。アライメントが一致するSPFの方法はカスタムのBounce Domainです。自社のサブドメイン（例：bounces.yourdomain.com）からsparkpostmail.comへCNAMEを設定すると、SparkPostはそのサブドメインをReturn-Pathとして使います。これでSPFチェックは自社のサブドメインに対して行われ（組織ドメインと緩和されたアライメントで一致）、SPFはCNAMEを介してsparkpostmail.comから引き続き継承されます。SparkPost自身のフローで提示されるのが、ルートドメインに貼り付けるSPF行ではなく、DKIMのTXTレコードとバウンス用ドメインのCNAMEレコードである理由はここにあります。ルートドメインのSPFレコードは、Return-Pathに実際に自社ドメインを使う送信者（Google Workspace、Microsoft 365、自社管理のリレー）のために取っておき、SparkPost分はバウンス用のCNAMEとDKIMに任せてください。
2つの設定方法
カスタムのバウンス用ドメインとDKIM（推奨、アライメント一致）
- scphセレクターのDKIM TXTレコードがd=yourdomain.comでメールに署名します。DMARCの成功を実際に担う仕組みです
- カスタムのバウンス用ドメインのCNAMEレコード（例：bounces.yourdomain.com → sparkpostmail.com）で、SPFのアライメントも自社ドメインに一致します
- ルートドメインのSPFレコードのDNSルックアップを消費しません。バウンス用のレコードはルートドメインではなく専用のサブドメインに置きます
- SparkPostのUSとEUで同じように機能します（EUではCNAMEレコードの指す先をeu.sparkpostmail.comにするだけです）
ルートドメインのSPFのinclude（従来方式、アライメント不一致）
- ルートドメインのSPFレコードにv=spf1 include:sparkpostmail.com ~allを自分で追加します
- エンベロープをSparkPostが所有する（デフォルトのバウンスはsparkpostmail.com）ため、このSPFレコードのアライメントが自社ドメインと一致することはありません
- DMARCには何の効果もありません。実際の役割を担うのは、引き続きDKIMとバウンス用ドメインです
- SPFの10回のルックアップのうち2回（includeと、ネストされたexists）を、アライメントの効果なしに消費します。省略して問題ありません
設定手順
- 1
Sending Domainsを開いてドメインを追加
SparkPost（app.sparkpost.com、EUアカウントはapp.eu.sparkpost.com）にサインインし、Configuration → Sending Domains → Add Domainを開きます。送信に使うドメインまたはサブドメインを入力して保存します（mail.yourdomain.comのようなサブドメインがよく使われ、送信レピュテーションを分離できます）。
- 2
SparkPostが生成するDKIMレコードをコピー
ドメインの設定画面で、SparkPostが「Set up for DKIM signing」の下にDKIMレコードを表示します。これはTXTレコードで、ホストはscph0421._domainkey.yourdomain.comのような自動生成セレクター、値はv=DKIM1; k=rsa; h=sha256; p=…で始まり、公開鍵が続きます。デフォルトは2048ビットの鍵なので値は長くなります。全体を正確にコピーしてください。
- 3
DKIMのTXTレコードを公開
DNSホストでTXTレコードを作成します。ホストはscph0421._domainkey（送信ドメインまたはサブドメインの下）で、v=DKIM1…の値全体を貼り付けます。種類はTXTのままにしてください。SparkPostのDKIMはCNAMEレコードではありません。2048ビットの鍵なので、管理画面によってはTXTの文字列が255文字に制限され、複数の引用符付き文字列に分割する必要があります。文字を削らずに分割してください。管理画面がドメインを自動で付加する場合は、二重にならないようラベル（scph0421._domainkey）だけを入力します。
- 4
送信ドメインを確認
Sending Domainsの画面に戻り、レコードを追加したことを確認するチェックボックスをオンにして、Verify Domainをクリックします。解決されると、ドメインが確認済みと表示され、「DKIM Signing」がreadyになります。そうなるまで、SparkPostはその鍵で署名しません。DNSの反映は通常数分ですが、最大24～48時間かかることがあります。
- 5
カスタムのBounce Domainを追加
Configuration → Bounce Domainsを開き（またはドメイン追加時にBounce Domainオプションを選び）、Return-Pathを担うサブドメインを追加します。緩和されたアライメントならbounces.yourdomain.com、厳格なアライメントなら送信用サブドメインそのもの（mail.yourdomain.com）を再利用します。SPFのアライメントが得られるのはこの手順です。
- 6
バウンス用ドメインのCNAMEレコードを公開
CNAMEレコードを作成します。ホストはバウンス用サブドメイン（bounces）、値はsparkpostmail.comです（SparkPost EUの場合は、代わりにeu.sparkpostmail.comを指定します）。Cloudflareでは、レコードを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはSparkPostに解決されず、確認に失敗します。
- 7
バウンス用ドメインを確認
Bounce Domainsに戻り、クリックして確認します。緑になると、SparkPostはそのバウンス用サブドメインをエンベロープのMAIL FROMとして使います。これで、SPFに成功し、組織ドメインともアライメントが一致します。DKIMに加えて、アライメントが一致する2つ目の仕組みになります。
- 8
DMARCポリシーのレコードを追加
SparkPostはDMARCポリシーを作成しません。ホストを_dmarc、値をv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとしてTXTレコードを追加します。p=noneは監視のみのため、SparkPostがアライメントの一致した状態でSPFとDKIMに成功していることを確認する間、配信には何も影響しません。後で段階的に引き上げます。
- 9
テストメールを送信してヘッダーを確認
認証済みドメインのアドレスからSparkPost経由で自分宛てにメッセージを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASSがyourdomain.comによる署名（セレクターはscph…）で、SPF: PASSのmailfromがバウンス用サブドメイン（sparkpostmail.comではありません）を示し、さらにDMARC: PASSと表示されていれば成功です。その後、ドメイン診断ですべてのレコードが解決されることを確認します。
追加するレコード
正確な値はSparkPostのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | scph0421._domainkey | v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from SparkPost)DKIMは、アライメントが一致し、DMARCの成功につながる仕組みです。scphセレクターはアカウントごとに自動生成されます（例：scph0421、scph0717）。値は例です。正確なレコードはConfiguration → Sending Domainsからコピーしてください。デフォルトは2048ビットの鍵なので、管理画面でTXTレコードが255文字に制限されている場合は、複数の引用符付き文字列に分割します。送信ドメインまたはサブドメインの下に公開します（例：scph0421._domainkey.mail.yourdomain.com）。 |
| CNAME | bounces | sparkpostmail.comカスタムのBounce Domain（Return-Path）です。SPFのアライメントを自社ドメインに一致させるのはこのレコードです。ルートドメインではなくサブドメインを使います。SparkPost EUでは、指す先はeu.sparkpostmail.comです。Cloudflareでは「DNS only」（グレーのクラウド）に設定します。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。SparkPostが作成することはありません。1つのドメインにつき1つで、p=noneから始めてquarantine/rejectへ引き上げます。 |
| TXT | @ | v=spf1 include:sparkpostmail.com ~all従来方式／任意です。エンベロープをSparkPostが所有するため、DMARCのアライメントは生まれません。アライメントが一致するSPFの方法は上記のバウンス用CNAMEレコードです。これを追加するのは、SPFの生のレコードでSparkPostを参照したい場合だけで、追加する場合はルートドメインの1つのSPFレコードにまとめてください。ルックアップを2回（includeと、sparkpostmail.comのレコード内にネストされたexistsマクロ）消費します。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。SparkPostの設定がこの上限のうち何回を消費するかは、次のとおりです。
SparkPostの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
SparkPostで要となるレコードはDKIMです。デフォルトでアライメントが一致する仕組みだからです。送信ドメインを追加すると、SparkPostはRSA鍵ペア（デフォルトは2048ビット）を生成し、公開すべきTXTレコードを表示します。ホストはscphNNNN._domainkey.yourdomain.comという形式の自動生成セレクター（例：scph0421._domainkey、4桁の数字はアカウント／鍵ごとに割り当てられます）で、値はv=DKIM1; k=rsa; h=sha256; p=<公開鍵>です。これをDNSホストに公開すると、SparkPostが対応する秘密鍵を保持してすべての送信メッセージに署名します。署名にはd=yourdomain.comが入り、Fromアドレスとアライメントが一致します。CNAMEで委任するサービス（SendGrid、Mailchimp、Klaviyo）と異なる点が2つあります。1つ目は、委任用のCNAMEレコードではなく、貼り付けるTXTレコードであることです。scphのTXTを置くべき場所にCNAMEを公開すると署名が壊れるので、種類はTXTのままにしてください。2つ目は、鍵を委任せず公開した鍵を自分で持つため、鍵の自動ローテーションがないことです。ローテーションが必要になったら、SparkPostで新しい鍵を生成し、新しいscphのTXTを自分で公開し直します。デフォルトの2048ビット鍵には実務上の注意点もあります。公開鍵がTXTの1文字列あたり255文字の上限を超えるため、多くのDNS管理画面では複数の引用符付き文字列に分割する必要があります（DNSホストが複数文字列のTXTを扱えない場合、SparkPostは代わりに1024ビットの鍵を発行できます）。レコードを公開するだけでは足りません。Configuration → Sending Domainsに戻ってVerify Domainをクリックし、ドメインが確認済みと表示され、「DKIM Signing」がreadyになるようにしてください。そうなるまで、SparkPostはその鍵で署名しません。
DMARC
DMARCは自分で追加する別のポリシーレコードで、SparkPostは作成しません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを公開します。p=noneは監視のみです。受信側から集計レポート（rua）がメールで届き、SparkPostのメールがSPFとDKIMに成功して自社ドメインとアライメントが一致しているかを確認できる間、配信には何も影響しません。ここで、SparkPostの2段階の設定が効いてきます。DKIMのscphレコードが確認済みになるとDKIMのアライメントが、カスタムのバウンス用ドメインが確認済みになるとSPFのアライメントも得られます。そのため、正しく設定したSparkPostのドメインは、DKIMだけに頼らず両方の仕組みでDMARCに成功します。1～2週間レポートを確認し、すべての正規の送信者（SparkPostと他に使っているもの）が認証できていることを確かめたら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。送信者の数にかかわらず、_dmarcレコードは組織ドメイン全体で1つだけにしてください。SparkPost専用に2つ目のDMARCレコードを公開してはいけません。
正しく設定できたか確認する
ダッシュボードの緑のチェックマークだけで判断せず、実際のメールで確認してください。認証済みドメインのアドレスからSparkPost経由で自分宛てにテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASSで、scphセレクターを使ってyourdomain.comの名義で署名され（SparkPostの共有ドメインではなく）、SPF: PASSのmailfrom/Return-Pathがバウンス用サブドメイン（bounces.yourdomain.com）を示し、さらにDMARC: PASSと表示されていれば成功です。失敗の典型的な兆候は、mailfromがsparkpostmail.comのままになっていることで、これはカスタムのバウンス用ドメインが設定されていないことを意味します。SparkPost側では、Configuration → Sending Domainsでドメインが確認済みかつDKIM Signingがreadyと表示され、Bounce Domainsでバウンス用サブドメインが確認済みと表示されるはずです。その後、Qualisendのドメイン診断でドメインをチェックし、DKIMのTXTレコード、バウンス用のCNAMEレコード、DMARCレコードがすべて正しく解決されることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。SparkPostが、アライメントが一致し、認証に成功している送信元として表示されるはずです。
よくある注意点
- DNS設定
最大の注意点は、ルートドメインのSPFレコードにinclude:sparkpostmail.comを追加しても、DMARCに成功しないことです。エンベロープをSparkPostが所有する（デフォルトのバウンス用ドメインはsparkpostmail.com）ため、SparkPostのメールでルートドメインのSPFレコードが参照されることはありません。アライメントをもたらすのは、SPFのincludeではなく、scphのDKIM TXTレコードとカスタムのバウンス用ドメインのCNAMEレコードです。
- 適用範囲
デフォルトのバウンス用ドメインでは、SPFが成功するのはsparkpostmail.com上で、自社とはアライメントが一致しません。そのため、DMARCはDKIMに完全に頼ることになります。カスタムのBounce Domainを追加すれば、アライメントが一致する2つ目の仕組みが得られ、より厳しい受信側にも対応できます。
- DNS設定
SparkPostのDKIMはCNAMEレコードではなく、TXTレコード（scphセレクター）です。種類を変更しないでください。scphのTXTを置くべき場所にCNAMEを置くとDKIM署名が壊れます。また、鍵の自動ローテーションはありません。ローテーションするには、SparkPostで新しい鍵を生成してTXTを公開し直します。
- DNS設定
SparkPostのデフォルトは2048ビットのDKIM鍵で、その値はTXTレコードの255文字の上限を超えます。DNS管理画面によっては複数の引用符付き文字列に分割する必要があります。分割はしても、切り詰めたり、p=の値の中に余分なスペースを入れたりしないでください。
- DNS設定
Cloudflareのプロキシはバウンス用のCNAMEレコードを機能させなくします。バウンス用ドメインのレコードを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはsparkpostmail.comに解決されず、ドメインの確認が完了しません。
- DNS設定
ルートドメインをバウンス用ドメインとして使うことはできません。ルートドメインのCNAMEレコードは他のレコードと競合します。サブドメインを使ってください（緩和されたアライメントならbounces.yourdomain.com、厳格なアライメントなら送信用サブドメインそのものを再利用）。
- DNS設定
SparkPost EUは別のスタックです。app.eu.sparkpost.comでサインインし、smtp.eu.sparkpostmail.comまたはapi.eu.sparkpost.com経由で送信し、バウンス用のCNAMEレコードの指す先は（sparkpostmail.comではなく）eu.sparkpostmail.comにします。同じドメインでもUSとEUは独立した2つの登録で、それぞれ別のDNSレコードを持ちます。
- 認証失敗の原因
ドメインのSPFのTXTレコードと_dmarcのTXTレコードは、それぞれ1つだけにしてください。何らかの理由でSparkPostの従来のincludeを残す場合は、1行のv=spf1にまとめます。SPFレコードが2つあると、それ自体がPermErrorになります。
- DNS設定
公開後はダッシュボードで確認してください。Configuration → Sending Domainsでドメインが確認済みと表示されるまで、SparkPostはDKIM署名を行いません。DNSの反映には最大24～48時間かかることがあります。確認が進まない場合は、レコードのホストにドメインが付加または重複していないかを再確認してください。
SPFレコードを作成
SparkPostでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証SparkPostのSPFに関するよくある質問
関連記事
トランザクションメール・APIの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。