Elastic EmailのSPF・DKIM・DMARC設定。
Elastic Emailでのドメイン確認に必要なのは、4つのDNSレコードとダッシュボードでのクリックだけです。4つのレコードは、Elastic Emailの共有includeを追加するSPFのTXTレコード、apiセレクターのDKIMのTXTレコード、クリックと開封のリンクを自社ブランドにするトラッキング用CNAME、DMARCポリシーレコードです。特徴的なのはDKIM鍵で、Elastic Emailはドメインごとに鍵を生成せず、全顧客に同じ共有公開鍵を渡します。SPFのincludeも、静的なIPリストではなく動的なマクロによるルックアップです。レコードを追加してVerifyをクリックすれば、Elastic Emailから完全に認証された状態で自社ドメインとして送信できるようになり、未確認ドメインに課される1日500通の上限も解除されます。
Elastic Emailを認証すべき理由
Elastic Emailでドメインを認証すれば、1日500通という制限と共有プールから抜け出せます。ドメインを確認するまで、Elastic Emailの送信上限は1日500通で、メールと送信者の結び付きも弱いままです。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook/Hotmail/Live宛てのメールに同じ要件の適用を始めました。Elastic Emailは大量のマーケティングメールやトランザクションメールの送信によく使われているため、この基準はまさにElastic Email経由で送るメールに当てはまります。SPFとDKIM（およびトラッキング用CNAMEとDMARCポリシー）を公開すると、メールは自社ドメインとアライメントが一致し、トラッキングリンクからElastic Emailの汎用ブランドが消え、1日の上限も解除されます。築いた送信レピュテーションは、プラットフォーム上の全アカウントが共有するインフラではなく、自社ドメインに蓄積されます。
Elastic EmailにおけるSPFの実情
Elastic Emailは正真正銘の「include」型サービスです。ドメインに1つだけ置くSPFのTXTレコードに、共有メカニズムinclude:_spf.elasticemail.comを1つ追加します。Elastic Emailが推奨する行はv=spf1 a mx include:_spf.elasticemail.com ~allですが、Elastic Emailのサーバーを許可するのはincludeの部分だけです。aとmxは自社のWeb/メールホストを許可する汎用の定型部分で、任意です。このincludeが珍しいのは解決先です。_spf.elasticemail.comは静的なip4:範囲のリストではなく、v=spf1 exists:%{i}._spf.elasticemail.info ~allを公開しています。これは検証時に送信元のIPそのもの（%{i}）を照会する、マクロベースのexists:チェックです。ここから実務上の影響が2つ生じます。1つ目に、このincludeはSPFのDNSルックアップの10回制限のうち、1回ではなく2回を消費します。include自体で1回、ネストされたexistsメカニズムで1回です（aとmxも残すと、他の送信元を追加する前の時点で、Elastic Emailの推奨行はすでに4回に達します）。2つ目に、許可がIPごとに動的に計算されるため、Elastic Emailが送信IPを追加・廃止しても、DNSを編集し直す必要はありません。SPFレコードはドメインに1つだけにしてください。すでにGoogle Workspace、Microsoft 365、CRMなどから送信している場合は、2つ目を公開せず、include:_spf.elasticemail.comをその1つのv=spf1の行にまとめます（SPFレコードが2つあるとPermErrorになります）。Elastic Emailが~all（softfail）付きの行を提供しているのは、ほとんどの送信者が他のサービスからも送信しているためです。-allに引き上げるのは、正当な送信元をすべて記載してからにしてください。
設定手順
- 1
Manage Domainsを開く
app.elasticemail.comにログインし、Settings → Domains → Manage Domainsを開きます。Start Verificationをクリックし、送信に使うドメインを入力してContinueをクリックします。すると、Elastic Emailがそのドメイン用の正確なDNSレコードを生成します。
- 2
生成されたレコードを確認
確認画面に、公開すべきレコードが一覧表示されます。SPFのTXT行、ホストapi._domainkeyのDKIMのTXTレコード、トラッキング用CNAME（ホストtracking → api.elasticemail.com）、推奨のDMARCレコードです。DNSが有効になったらここでVerifyをクリックするので、このタブは開いたままにしてください。
- 3
SPFレコードを追加（既存なら1つにまとめる）
DNSホストで、ルートドメイン（ホストは@または空欄）にTXTレコードを追加し、値をv=spf1 a mx include:_spf.elasticemail.com ~allとします。SPFレコードがすでにある場合は2つ目を作らず、include:_spf.elasticemail.comを既存のv=spf1の行にまとめてください。ドメイン自体のWeb/メールサーバーから送信しないなら、aとmxは削除してかまいません。
- 4
DKIMのTXTレコードを公開
ホストapi._domainkey、値はダッシュボードに表示されたもの（k=rsa; t=s; p=MIGf…で始まる）で、TXTレコードを追加します。これはElastic Emailの共有DKIM鍵です。Manage Domainsから値をそのままコピーし、ホスト名は変更しないでください。
- 5
トラッキング用CNAMEを追加
ホストがtrackingで、api.elasticemail.comを指すCNAMEレコードを追加します。開封・クリックのトラッキングリンクに自社のサブドメインが使われるようになり、完全なドメイン確認の一部にもなります。Cloudflareでは、解決されるよう「DNS only」（グレーのクラウド）に設定してください。
- 6
DMARCレコードを公開
ホスト_dmarcに、値がv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加します。アライメントを確認している間は何も影響しないよう、p=none（監視のみ）で始め、後でポリシーを引き上げます。
- 7
Verify recordをクリック
確認画面に戻り、Verify recordをクリックします。Elastic EmailがDNS上で確認したレコードごとに、緑のチェックマークが付きます。反映には最大24～48時間かかることがあるため、すぐに認識されないレコードは後で再確認してください。
- 8
デフォルトの送信者に設定
確認が済んだら、必要に応じてドメインをデフォルトの送信者に設定します。新しいキャンペーンやAPI送信で自動的に使われるようになります。確認が完了すると、未確認ドメインに適用される1日500通の上限も解除されます。
- 9
テストを送信してヘッダーを確認
確認済みドメインのアドレスからメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASS signed-by yourdomain.com（セレクターapi）、SPF: PASS、DMARC: PASSを確認してください。
追加するレコード
正確な値はElastic Emailのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 a mx include:_spf.elasticemail.com ~allルートドメインのSPF：SPFレコードは1つだけにし、includeをそこにまとめます。Elastic Emailを許可するのはinclude:_spf.elasticemail.comだけで、aとmxは任意です。このincludeはDNSルックアップを2回消費します（includeとネストされたexistsマクロ）。 |
| TXT | api._domainkey | k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbmGbQMzYeMvxw…Elastic Emailの共有DKIM鍵（セレクターapi）：全アカウントが同じ値を公開します。Manage Domainsから値全体をそのままコピーしてください。鍵は共有でも、自社ドメインとアライメントが一致します。 |
| CNAME | tracking | api.elasticemail.com開封・クリックのトラッキングを自社ブランドにするレコードです。完全な確認の一部です。Cloudflareでは「DNS only」（グレーのクラウド）に設定します。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCレコードはドメインごとに1つです。p=noneで始め、quarantine/rejectへと引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Elastic Emailの設定がこの上限のうち何回を消費するかは、次のとおりです。
Elastic Emailは10回のルックアップのうち2回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Elastic EmailのDKIMは、セレクターがapiの共有公開鍵1つで、ドメインごとに生成する鍵ではありません。全顧客がまったく同じTXTレコードを公開します。ホストはapi._domainkey.yourdomain.com、値はk=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…（1024ビットの鍵）です。api._domainkey.elasticemail.comが同じ値に解決されるので、ご自身でも確かめられます。対応する秘密鍵はElastic Emailが1つだけ保持し、送信メールにd=yourdomain.comで署名します。そのため鍵は共有でも、署名は自社ドメインとアライメントが一致します。これは、DKIMがDMARCの成功に貢献するために必要な条件そのものです。共有であることから、いくつかの点に注意が必要です。鍵を自分でローテーションできず、現在の標準である2048ビットではなく1024ビットの鍵です。また、値は第三者の記事から貼り付けず、アカウントのManage Domains画面から正確にコピーしてください。Elastic Emailが共有鍵をローテーションした場合、正しい情報源はダッシュボードです。公開は表示どおりに行ってください。api._domainkeyのホスト名を変更せず、CNAMEに切り替えず、文字の追加や削除もしないでください（値に含まれるt=sフラグはElastic Emailの仕様で、誤記ではありません）。実際のところ、ここでDMARCを支えているのはDKIMです。DKIMは転送の有無にかかわらず、すべてのメールで自社ドメインとアライメントが一致します。一方、SPFが役立つのは、自社ドメインがエンベロープ送信者の場合だけです。
DMARC
DMARCは、自分で公開する別のTXTレコードです。Elastic Emailは作成しませんが、確認の流れの中でレコードの公開を促されます。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるレコードを追加します。p=noneは監視のみで、配信には何も影響しませんが、受信側に集計レポートをメールで送るよう求めます。これにより、ポリシーを適用する前に、Elastic Emailのメールが、DKIM（および自社ドメインがエンベロープ送信者の場合は、SPF）に自社ドメインとアライメントが一致した状態で成功していることを確認できます。Elastic Emailの確認画面はp=quarantineかp=rejectへ直接進むよう促しています。p=noneでは保護がほとんど得られないという点は正しいものの、移行は計画的に進めてください。1～2週間、集計レポート（rua）を確認し、正当な送信者（Elastic Emailおよびドメイン上の他のツール）すべてのアライメントが一致していることを確かめてから、quarantine、最終的にrejectへと引き上げます。送信者がいくつあっても、_dmarcレコードはドメイン全体で1つだけにしてください。Elastic Email専用に2つ目のDMARCレコードを公開してはいけません。
正しく設定できたか確認する
Manage Domainsの緑のチェックマークだけで判断せず、実際のメールで確認してください。確認済みドメインのアドレスからテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASS signed-by yourdomain.com（セレクターapi）、SPF: PASS、DMARC: PASSと表示されていれば成功です。SPFに自社ドメインではなくElastic Emailのエンベロープドメインが表示されても、慌てる必要はありません。DMARCの成功を支えているのはDKIMであり、それで問題ありません。レコードそのものは次のコマンドでも確認できます：dig TXT api._domainkey.yourdomain.com、dig TXT yourdomain.com（SPFの行）、dig TXT _dmarc.yourdomain.com、dig CNAME tracking.yourdomain.com。続いて、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決され、SPFがルックアップの10回制限に収まっていることを確認します（Elastic Emailのincludeがそのうち2回を占める点に注意してください）。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップし、Elastic Emailがアライメントの一致した、成功している送信元として表示されることを確認します。
よくある注意点
- DNS設定
Elastic EmailのDKIM鍵はドメインごとではなく共有で、全アカウントが同じapi._domainkeyの値を公開します。これは想定どおりで、自社ドメインとのアライメントも一致します。ただし、鍵を自分でローテーションできず、1024ビットの鍵です。また、Elastic Emailがローテーションする場合に備え、第三者の記事ではなくManage Domainsから値を正確にコピーしてください。
- 認証失敗の原因
このincludeは、SPFのルックアップを1回ではなく2回消費します。include:_spf.elasticemail.comと、その中にネストされたexists:%{i}._spf.elasticemail.infoマクロの分です。Elastic Emailが提案するaとmxを残すと、他の送信元を追加する前の時点で、推奨行はすでに約4回に達します。10回の上限に注意してください。
- 認証失敗の原因
SPFレコードはドメインに1つだけにしてください。すでにGoogle、Microsoft 365、CRMなどから送信している場合は、include:_spf.elasticemail.comを既存のv=spf1の行にまとめます。SPFレコードを2つに分けるとPermErrorになり、SPF全体が機能しなくなります。
- DNS設定
Elastic Emailが推奨するSPFのaとmxは、Elastic Emailではなく自社のWeb/メールホスト向けの汎用の定型部分です。ドメインのAレコードやMXサーバーから実際にメールを送信していないなら、削除してv=spf1 include:_spf.elasticemail.com ~allを使えば、ルックアップを2回分節約できます。
- DNS設定
Cloudflareでは、トラッキング用CNAMEを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはapi.elasticemail.comに解決されないため、トラッキングと完全な確認に失敗します。
- DNS設定
未確認ドメインの上限は1日500通です。送信が知らないうちに抑制されている場合、ドメインの確認が完了していない可能性が非常に高いでしょう。上限が解除されるのは、SPF、DKIM、トラッキング用CNAMEを揃えてVerifyをクリックしたときです。
- DNS設定
DKIMレコードは、ホストを正確にapi._domainkeyとし、TXTレコードとして、値もそのまま公開してください。ホスト名の変更、CNAMEの使用、長いp=文字列の破損はいずれも、ダッシュボードが一部緑に見えていても、気づかないうちにDKIMが失敗する原因になります。
- 適用範囲
サブドメイン（例：mail.yourdomain.com）から送信する場合は、すべてのレコードをそのサブドメインに置きます：サブドメイン上のSPF、api._domainkey.mail、tracking.mail、_dmarc.mail。ルートドメインのレコードは送信用サブドメインをカバーしません。
SPFレコードを作成
以下ではElastic Emailがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Elastic EmailのSPFに関するよくある質問
関連記事
トランザクションメール・APIの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。