SMTP.comのSPF・DKIM・DMARC設定。
SMTP.comはSMTPリレー兼メールAPIです。アプリ、CRM、またはメールサーバーをSMTP.comに向けると代わりに配信してくれるので、自社ドメインでSMTP.comを許可する必要があります。設定はDNSレコード3つと、アカウント側の切り替え1つです。ルートドメインのSPFレコードにまとめる本物のSPFのinclude（include:_spf.smtp.com）、smtpkeyセレクターに置くカスタムドメインDKIMのCNAME、そして自分で公開するDMARCポリシーレコードです。カスタムドメインDKIMは、メールが共有ドメインではなく自社ドメインとして署名されるよう、SMTP.com側でもアカウントで有効にする必要があります。3つが揃うと、メールは自社ドメインとして完全に認証された状態でSMTP.comからリレーされます。DKIMのアライメントがFromドメインと一致するので、SMTP.comの共有署名ドメインに頼ることなくDMARCに成功します。
SMTP.comを認証すべき理由
SMTP.com経由でリレーするドメインの認証は、メールが受信トレイに届くかどうかを左右します。大量のメールを扱うリレーでは、メールボックスサービスよりも影響が大きくなります。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail/Live宛ての大量メールに同じ要件の適用を始めました。まさにSMTP.comが使われる規模です。リレー特有の注意点として、SMTP.comは初期状態では、送信メールにSMTP.com自身の共有ドメインの1つ（d=smtpsend.com）でDKIM署名し、バウンスもSMTP.com独自のReturn-Pathで処理します。そのため、SPFもDKIMもFromドメインとアライメントが一致しません。つまり、未設定のSMTP.comドメインにはアライメントが一致する仕組みが1つもなく、DMARCに成功できません。受信側が「via smtpsend.com」と表示することもあり、費用をかけて築く送信者レピュテーションは、共有インフラ上の未認証の送信者全体と共有されます。SPFのincludeと、とりわけカスタムドメインDKIMを有効にすることで、メールは暗号学的に自社のものとなり、DMARCに成功し、レピュテーションが自社ドメインに蓄積されます。
SMTP.comにおけるSPFの実情
SMTP.comは本物の「include」型サービスです。ルートドメインの1つのSPF TXTレコードに共有メカニズムinclude:_spf.smtp.comを1つ追加し、v=spf1 include:_spf.smtp.com ~allとします。すべてのSMTP.comの顧客が同じものを使う、本物の共有includeです。内容も軽量で、IPv4範囲2つと独自のsoftfailだけからなるフラットなレコード（v=spf1 ip4:192.40.160.0/19 ip4:74.91.80.0/20 ~all）に解決されます。そのため、10回のSPF DNSルックアップのうち消費するのは1回だけで、キャッシュを参照する一部のチェックツールが報告する2～3回ではありません。ただし、多くの人がつまずく点があります。このincludeはSMTP.comの送信IPを許可しますが、それだけではDMARCに成功しません。SMTP.comは初期状態で独自のエンベロープ送信者（Return-Path用ドメイン）を使ってリレーし（バウンスを処理するためです）、SPFは常にそのエンベロープのドメインに対して評価されます。そのためチェックはSMTP.comのインフラに対して成功するだけで、Fromドメインとのアライメントは一致しません。それでもincludeは、ドキュメントにも記載された正しい推奨のSPF手順です（SPFチェック自体の失敗を防ぎ、SMTP.comの設定もこれを前提としています）。したがって公開すべきですが、実際にDMARCの成功を担うのは、d=yourdomain.comで署名するカスタムドメインDKIMのCNAMEです。includeは必要条件であって十分条件ではないと考え、公開したうえでアライメントはDKIMに任せてください（SPFでアライメントを一致させる唯一の方法は、SMTP.comと調整して自社ドメインにカスタムのReturn-Path、バウンス用ドメインを用意することですが、ほとんどのアカウントはこれを省いてDKIMを選びます）。また、ドメインのSPFレコードは1つだけにしてください。Google Workspace、Microsoft 365などのツールからも送信している場合は、2つ目のSPF TXTを公開せず、その1つのv=spf1の行にinclude:_spf.smtp.comを追加して1つにまとめます（SPFレコードが2つあるとPermErrorになります）。
設定手順
- 1
リレーに使うドメインを確認
SMTP.comのControl Panelにログインし、アプリやAPIが送信に使うFromドメイン（From:ヘッダーのドメイン、例：yourdomain.com）を確認します。SMTP.comは設定されたFromアドレスのメールをリレーするので、認証を行う対象はSMTP.com所有のホストではなく、その組織ドメインです。Sender/リレーの認証情報とReputation Defenderの設定もここにあります。
- 2
SPFのincludeを追加（既存なら1つにまとめる）
DNSホストで、ルートドメイン（ホストは@または空欄）にTXTレコードを1つ作成し、値をv=spf1 include:_spf.smtp.com ~allとします。v=spf1のレコードがすでにある場合（Google Workspace、Microsoft 365、他のリレーなど）は2つ目を追加せず、その1つのレコードに他のメカニズムと並べてinclude:_spf.smtp.comを追加して1つにまとめます。すべての送信者が記載されていると確信できない限り、SMTP.comが使うsoftfailの~allのままにしてください。
- 3
カスタムドメインDKIM署名を有効化
初期状態のSMTP.comは共有ドメイン（d=smtpsend.com）で署名するため、アライメントが一致しません。smtpkeyセレクターでd=yourdomain.comとして署名するには、アカウントでカスタムドメインDKIM署名を有効にする必要があります。これはアカウント側の切り替えなので、SMTP.comサポートまたはアカウントマネージャーに依頼し、割り当てられる正確なセレクターとターゲットを確認してください（広く公開されている組み合わせは下記のとおりです）。
- 4
DKIMのCNAMEを追加
CNAMEレコードを作成します。ホストはsmtpkey._domainkey（つまりsmtpkey._domainkey.yourdomain.com）で、smtpcustomer._domainkey.smtpsend.comを指します。これは委任であり、SMTP.comがその共有ターゲットの背後で秘密鍵を保持し、代わりに署名します。タイプはCNAMEのままにし、TXTやAに変更しないでください。
- 5
DMARCレコードを公開
SMTP.comはDMARCを作成しません。ホストを_dmarc、値をv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとしてTXTレコードを追加します。p=noneは監視のみのため、SMTP.comのメールの署名とアライメントを確認している間、配信には何も影響しません。ポリシーは後で引き上げます。
- 6
ホスト欄の二重付加とCloudflareのプロキシを修正
レジストラがドメインを自動で付加する場合は、ラベル（smtpkey._domainkey、SPFは@）だけを入力し、smtpkey._domainkey.yourdomain.com.yourdomain.comにならないようにします。Cloudflareでは、DKIMのCNAMEを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはsmtpsend.comに解決されず、DKIMの検証に失敗します。
- 7
テストメールを送信してヘッダーを確認
カスタムDKIMが有効になりレコードが反映されたら（通常は数分、最大24～72時間）、SMTP.com経由でGmailアドレスへテストメールをリレーし、開いて⋮ → Show originalを選びます。DKIM: PASS（d=yourdomain.com、セレクターはsmtpkey）、SPF: PASS、DMARC: PASSと表示されていれば成功です。失敗の典型的な兆候はd=smtpsend.comで、カスタム署名がまだ有効でないことを示します。
- 8
すべてのレコードが解決されることを確認
Qualisendのドメイン診断でドメインをチェックし、SPFレコードが1つで10回の上限内に収まっていること、smtpkey._domainkeyのCNAMEがsmtpsend.comに解決されること、DMARCレコードがあることを確認します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップし、SMTP.comがアライメントが一致し認証に成功している送信元として表示されることを確かめます。
追加するレコード
正確な値はSMTP.comのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.smtp.com ~allルートドメインのSPF：SPFレコードは1つだけにします。v=spf1の行がすでにある場合は、このincludeを追加して1つにまとめてください。include:_spf.smtp.comはフラットに解決される（ip4の範囲2つと~all）ため、消費するDNSルックアップは1回です。SMTP.comのIPを許可しますが、初期状態ではアライメントは一致しません。 |
| CNAME | smtpkey._domainkey | smtpcustomer._domainkey.smtpsend.comカスタムドメインDKIM（アライメントが一致する仕組み）です。例です。多くの資料に記載されている共有ターゲットですが、SMTP.comがアカウントに割り当てる正確なセレクターとターゲットを確認してください。SMTP.comがアカウント側でカスタム署名も有効にしない限り、このCNAMEは何の効果もありません。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。SMTP.comが作成することはありません。DMARCレコードは1つのドメインにつき1つだけにし、p=noneから始めて、DKIMのアライメントが問題なく一致したらquarantine、rejectへと引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。SMTP.comの設定がこの上限のうち何回を消費するかは、次のとおりです。
SMTP.comは10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
SMTP.comでDMARCの成功を実際に担うのはDKIMです。こちらが何も設定しなくてもSMTP.comは「すでに署名している」ため、見落とされやすい手順でもあります。ただし、署名に使われるのは誤ったドメインです。リレーは初期状態で、送信メールにSMTP.com自身の共有ドメインの1つ（d=smtpsend.com）でDKIM署名します。この署名は暗号学的には有効ですが、自社ドメインではないためアライメントが一致せず、yourdomain.comのDMARCには役立ちません。解決するにはカスタムドメインDKIMを有効にします。必要な作業は連動する2つです。（1）smtpkey._domainkey.yourdomain.comに、smtpcustomer._domainkey.smtpsend.comを指すCNAMEを公開します。（2）SMTP.com側で、アカウントがsmtpkeyセレクターで自社ドメインとして署名するよう切り替えてもらいます。これはアカウント側の設定で、通常はSMTP.comサポートまたはアカウントマネージャーを通じて手配します。チケットを作成し、割り当てられる正確なセレクターとターゲットを確認してください（一部のアカウントには別の組み合わせが割り当てられることがあります）。貼り付けるTXT鍵ではなくCNAMEなので、SMTP.comがその共有ターゲットの背後で秘密鍵を保持し、自社側でDNSを再度変更しなくても鍵をローテーションできます。共有ターゲット方式のトレードオフは鍵が自社固有ではないことですが、アライメントは鍵の固有性に左右されません。重要なのは署名のd=の値が組織ドメインであることで、カスタム署名を有効にすればそうなります。自社側で公開するレコードは小さく静的で、実際の署名という重い処理はSMTP.comのサーバーで行われます。CNAMEが解決され、かつカスタム署名が有効になるまでは、Show originalにd=smtpsend.comと表示され続け、DMARCにはアライメントが一致する仕組みがない状態が続きます。
DMARC
DMARCはドメインに置く別のポリシーTXTレコードで、SMTP.comは作成しません。DNSホストで自分で公開します。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを追加します。p=noneは監視のみのため配信には何も影響せず、受信側に集計レポート（rua）をメールで送るよう伝えます。これにより、ポリシーを適用する前に、SMTP.comのメールがDKIMに成功し、自社ドメインとアライメントが一致していることを確認できます。SMTP.comのSPFは初期状態でアライメントが一致しないので、この監視の手順は通常より重要です。カスタムDKIMのCNAMEが実際にアライメントを担っているかどうかは、レポートで確認します。1～2週間確認し、正規の送信元（SMTP.comとその他の送信者）がすべて認証できていることを確かめたら、ポリシーをp=quarantine、最終的にp=rejectへと引き上げます。DKIMがd=yourdomain.comで署名することを確認する前に、いきなり厳しいポリシーにしないでください。カスタム署名がまだ有効でない状態でp=rejectのレコードを置くと、自社でリレーしたメールがバウンスします。送信者の数にかかわらず、_dmarcレコードはドメイン全体で1つだけにしてください。SMTP.com専用に2つ目のDMARCレコードを追加してはいけません。
正しく設定できたか確認する
Control Panelや反映までの時間だけで判断せず、実際のメールで認証を確認してください。SMTP.com経由でGmail（またはOutlook）のメールボックスへテストメールをリレーし、開いて⋮ → Show originalを選びます。確認するのはDKIM: PASS（d=yourdomain.com、セレクターはsmtpkey）です。d=smtpsend.comと表示される場合、カスタム署名はまだ有効ではありません。CNAMEは公開済みでも、SMTP.comがアカウントを切り替えていない状態です。あわせてSPF: PASS（成功はしますが、カスタムのReturn-Pathを手配していない限り、一致するのは自社ドメインではなくSMTP.comのエンベロープです）とDMARC: PASS（ここではDKIMのアライメントによって成功するはずです）も確認します。詳細なレポートが必要な場合は、check-auth@verifier.port25.comにテストメールを送ると、項目ごとの内訳がメールで返ってきます。次に、Qualisendのドメイン診断でドメインをチェックし、SPFレコードが1つで10回の上限内に収まっていること、smtpkey._domainkeyのCNAMEがsmtpsend.comに正しく解決されること、DMARCレコードがあることを確認します。集計レポートが届いたら、DMARCレポート解析にレポートをドロップします。SMTP.comが、アライメントが一致し認証に成功している送信元として表示されるはずです。
よくある注意点
- DNS設定
SPFのincludeは成功しますが、初期状態ではアライメントが一致しません。SMTP.comは初期状態で独自のReturn-Path（エンベロープ用ドメイン）を使ってリレーするので、include:_spf.smtp.comはIPを許可し、SPFチェック自体をFromドメインではなくSMTP.comに対して成功させるだけです。includeを追加するだけではDMARCに成功しません。成功をもたらすのはカスタムDKIMのCNAMEです。
- 認証失敗の原因
初期状態のDKIMはd=smtpsend.com（SMTP.comの共有ドメイン）で署名され、検証には成功しますがアライメントは一致しません。smtpkeyセレクターでd=yourdomain.comとして署名されるようカスタムドメインDKIMを有効にしてください。そうしないと、DMARCにはアライメントが一致する仕組みが1つもありません。
- 認証失敗の原因
カスタムDKIMはDNSレコードだけでなく、アカウント側の切り替えも必要です。SMTP.comがアカウントのカスタム署名を有効にするまで、smtpkey._domainkeyのCNAMEを公開しても何の効果もありません。サポートチケットを作成するかアカウントマネージャーに依頼し、割り当てられる正確なセレクターとターゲットを確認してください。
- DNS設定
DKIMのCNAMEのターゲットは共有ホスト（smtpcustomer._domainkey.smtpsend.com）で、コピーミスではなく設計どおりです。SMTP.comがその背後で秘密鍵を保持してローテーションします。署名のd=は自社ドメインなので、アライメントは問題なく一致します。TXTにせず、CNAMEのままにしてください。
- DNS設定
Cloudflareのプロキシを有効にすると、DKIMのCNAMEが機能しなくなります。smtpkey._domainkeyを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはsmtpsend.comに解決されず、DKIMの有効化に失敗します。
- 認証失敗の原因
ルートドメインのSPF TXTレコードは1つだけにしてください。Google Workspace、Microsoft 365、または他のリレーからすでに送信している場合は、その1つのv=spf1の行にinclude:_spf.smtp.comを追加して1つにまとめます。SPFレコードが2つあると、それ自体がPermErrorになります。
- DNS設定
ホスト欄の二重付加：多くのレジストラはドメインを自動で付加するため、smtpkey._domainkey.yourdomain.comと入力するとsmtpkey._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、ラベル（smtpkey._domainkey、SPFレコードは@）だけを入力してください。
- 適用範囲
すべての送信者を洗い出すまでは、SMTP.comのincludeに合わせた~allを使ってください。早まって-allにすると、同じSPFの行に追加し忘れたツールからの正規のメールがhard failになることがあります。
SPFレコードを作成
以下ではSMTP.comがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証SMTP.comのSPFに関するよくある質問
関連記事
トランザクションメール・APIの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。