Mandrill (Mailchimp Transactional)のSPF・DKIM・DMARC設定。
Mandrill（現在はMailchimp Transactionalとして、Mailchimp Marketingアカウントの有料アドオンで提供）では、ワンクリックのウィザードではなく、Settings → Domains → Sending Domainsで送信ドメインを認証します。2024年3月15日以降、実際の設定は3点です。2つのDKIM CNAMEレコード（mte1._domainkeyとmte2._domainkeyで、それぞれdkim1.mandrillapp.comとdkim2.mandrillapp.comを指します）、DMARCポリシーレコード、そしてFromアドレスのドメインに設定する共通のSPFのinclude（include:spf.mandrillapp.com）です。任意で、mandrillapp.comへのCNAMEを持つカスタムのreturn-path／トラッキング用サブドメインを追加すると、SPFのアライメントとブランド独自の開封／クリックリンクが得られます。Test DNS Settingsをクリックしてすべてが解決されると、メールは自社ドメイン名義で署名・送信されます。未認証のドメインに対しては、現在MandrillはFromアドレスをmandrillapp.comのサブドメインに書き換えていますが、その書き換えはなくなります。
Mandrill (Mailchimp Transactional)を認証すべき理由
Mandrillの送信ドメイン認証は、パスワードリセット、領収書、発送通知などのトランザクションメールが迷惑メールフォルダーに入らないようにするものです。Mailchimpも現在、これを直接義務付けています。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けており、Microsoftも2025年に同等のルールを個人向け受信トレイ（Outlook/Hotmail/Live）に拡大しました。これを受けてMailchimpは、2024年3月15日に独自のポリシー適用を開始しました。送信ドメインに2つのDKIM CNAMEとDMARCレコードが公開されていないと、メールは自社ドメイン名義で送信されなくなり、MandrillがFromアドレスをmandrillapp.comのサブドメインに書き換えます（返信は引き続き届きますが、自社ドメインにレピュテーションは蓄積されず、受信者には実際には自社から送られていないメールとして見えます）。さらにMandrill特有の事情として、DKIMは欠かせません。デフォルトではエンベロープ送信者（Return-Path）がmandrillapp.comのバウンス用ドメインにあるため、SPFは成功しても自社ドメインとアライメントが一致することはありません。カスタムのreturn-pathも設定しない限り、DMARCの成功を支える仕組みはDKIMだけです。DKIM、SPF、DMARCを整えれば、レピュテーションも受信トレイへの到達も自社ドメインの実績として蓄積されます。
Mandrill (Mailchimp Transactional)におけるSPFの実情
Mandrillは正真正銘の「include」型のサービスで、この点が姉妹製品のMailchimp Marketing（CNAMEのみでSPFのincludeは不要）と大きく異なります。Mailchimp Transactionalは、デフォルトのmandrillapp.comのreturn-pathを使う場合も、アライメントのためにカスタムのものを設定する場合も、FromドメインのSPFレコードにinclude:spf.mandrillapp.comを含めることを明確に求めています。ドメインに1つだけのSPF TXTレコード内に、たとえばv=spf1 include:spf.mandrillapp.com ~allのように公開します。既存のv=spf1の行がある場合は2つ目のSPFレコードを追加せず、そこにまとめてください。ルックアップについては朗報があります。spf.mandrillapp.comはip4:の範囲と~allだけを含むフラットなレコードに解決され、入れ子のincludeがありません。そのため、消費するのはSPFのDNSルックアップ10回のうちちょうど1回で、一部の古いガイドが示唆するような数回ではありません。重要な注意点があります。このincludeによってMandrillのIPに対するSPFチェック自体は成功しますが、デフォルトではReturn-Pathにmandrillapp.comのバウンス用ドメインが使われます。そのためSPFはMandrillのドメインに対してチェックされ、組織ドメインとアライメントが一致しません。アライメントが一致しないSPFの成功は、単独ではDMARCに何も寄与しません。Mandrillの手順がアライメントの一致するDKIM CNAMEを重視しているのは、このためです。SPFのアライメントも一致させたい場合（一部の転送シナリオにも耐えたい場合）は、カスタムのreturn-path／トラッキング用サブドメイン（mandrillapp.comを指すサブドメインのCNAME）を設定します。Return-Pathが自社ドメインに移り、SPFのアライメントが一致します。まとめると、includeは必須でルートドメインのSPFレコードに記載するものですが、主要な仕組みはDKIMと考え、カスタムのreturn-pathはアライメントの一致したSPFが必要な場合にのみ追加してください。
2つの設定方法
DKIMのアライメントのみ（Mailchimpのデフォルト）
- 2024年3月15日以降に必須となった最低限の設定：2つのDKIM CNAME（mte1/mte2）、SPFのinclude、DMARCレコード。追加のサブドメインは不要です。
- MandrillのDKIMはmte1/mte2セレクターを通じてd=yourdomain.comで署名するので、アライメントが一致し、DKIMだけでDMARCに成功します。
- Return-Pathはmandrillapp.comのバウンス用ドメインのままなので、SPFは成功してもアライメントは一致しません。DMARCの成功はDKIMが支えるので問題ありません。
- 管理するレコードが最も少なく、Fromアドレスの書き換えを止め、Gmail、Yahoo、Microsoftの要件を満たすにはこれで十分です。
カスタムのreturn-path／トラッキング用サブドメインを追加
- サブドメインのCNAMEを1つ追加すると（例：mail.yourdomain.com → mandrillapp.com）、Return-Pathが自社ドメインに移ります。
- SPFのアライメントも一致するので、DMARCはSPFとDKIMの両方で成功できます。DKIM署名を壊すことのある転送に対して、より強くなります。
- mandrillapp.comではなく自社ドメインで、ブランド独自の開封／クリック計測リンクも使えます。
- 必ずサブドメインにし（ルートドメインは不可）、CloudflareではDNS onlyに設定します。Test DNS Settingsボタンも別にあるので、そちらも実行してください。
設定手順
- 1
Sending Domainsページを開く
Mailchimpにサインインし、Mailchimp Transactional（Mandrill）アドオン（mandrillapp.com）を開いて、Settings → Domains → Sending Domainsに進みます。Fromアドレスのドメインが一覧にない場合は、「Add a sending domain」ボックスに入力してAddをクリックします。有料アドオンなので、有効なTransactionalプラン／APIキーが必要です。
- 2
DKIMとSPFのレコードを表示
送信ドメインの横にあるDNSの手順（「View DKIM & SPF setup instructions」リンク、またはSPFとDKIMの列）を開きます。そのドメインの2つのDKIM CNAMEとSPFのincludeが表示されます。Test DNS Settingsをクリックするために後で戻るので、開いたままにしておいてください。
- 3
2つのDKIM CNAMEレコードを追加
DNSホストで2つのCNAMEレコードを作成します：ホストmte1._domainkey → 値dkim1.mandrillapp.com、ホストmte2._domainkey → 値dkim2.mandrillapp.com。タイプはCNAMEのままにしてください（TXTに変更しないでください）。この2つのレコードは2024年3月15日以降、必須のDKIM方式となっており、古い1つのmandrill._domainkey TXT鍵に代わるものです。
- 4
SPFのincludeを追加（既存なら1つにまとめる）
ルートドメイン（ホストは@または空欄）にTXTレコードv=spf1 include:spf.mandrillapp.com ~allを追加します。v=spf1レコードがすでにある場合（Google Workspace、Microsoft 365、別のリレーなど）は、その1行にinclude:spf.mandrillapp.comをまとめます。2つ目のSPF TXTレコードは絶対に公開しないでください。消費するDNSルックアップは1回だけです。
- 5
DMARCレコードを公開
MandrillはDMARCを作成しません。2024年3月15日以降、ポリシーは必須です。ホスト_dmarcに、少なくともv=DMARC1; p=noneのTXTレコードを追加します。集計レポートも受け取れるよう、実際にはv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comを使ってください。省略してよいのは、_dmarcレコードがすでにある場合だけです（1つのドメインに必ず1つだけです）。
- 6
（任意）カスタムのreturn-path／トラッキングドメインを追加
SPFのアライメントとブランド独自の開封／クリックリンクを使うには、MandrillでSettings → Domainsに進み、Tracking Domainsセクションを開きます（カスタムのreturn-path／バウンス用ドメインもここで設定します）。mail.yourdomain.comやtrack.yourdomain.comなどのサブドメインを追加し、そのサブドメインをホストとしてmandrillapp.comを指すCNAMEレコードを作成します。必ずサブドメインにしてください。ルートドメインにCNAMEを設定してはいけません。これによりReturn-Pathが自社ドメインに移り、SPFのアライメントが一致します。
- 7
ホストの重複とCloudflareのプロキシを修正
レジストラがドメインを自動で付加する場合、重複を避けるためラベルのみ（mte1._domainkey.yourdomain.comではなくmte1._domainkey）を入力します。Cloudflareでは、MandrillのCNAME（2つのDKIMレコードと、return-path／トラッキング用のCNAMEがあればそれも）をすべて「DNS only」（グレーのクラウド）に設定します。オレンジのクラウドでプロキシが有効なCNAMEはmandrillapp.comに解決されず、Test DNS Settingsが失敗します。
- 8
Test DNS Settingsをクリック
Sending Domainsに戻ってTest DNS Settingsをクリックします。レコードが解決されると、SPFとDKIMの列がvalid/verifiedに変わります（通常は数分、最大で24～48時間）。Tracking/return-path画面には別のTest DNS Settingsボタンがあります。カスタムのreturn-pathを設定した場合は、そちらも実行してください。
- 9
テストメールを送信してヘッダーを確認
認証したドメインのアドレスからMandrillのAPIまたはSMTPでメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASS（d=yourdomain.com、mte1/mte2セレクター経由）とDMARC: PASSと表示されていれば成功です。カスタムのreturn-pathを追加していない限り、SPF / mailed-byの行にはmandrillapp.comが表示され、アライメントは不一致となります。これは想定どおりで、DMARCの成功はDKIMが支えています。
追加するレコード
正確な値はMandrill (Mailchimp Transactional)のセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:spf.mandrillapp.com ~allルートドメインのSPF：Fromドメインに必須です。SPFレコードは1つだけにし、v=spf1の行がすでにある場合はこのincludeをまとめてください。DNSルックアップを1回消費します。カスタムのreturn-pathを追加しない限り、成功してもアライメントは一致しません。 |
| CNAME | mte1._domainkey | dkim1.mandrillapp.comDKIM鍵1：2024年3月15日以降は必須です。CNAMEで委任するため鍵の管理はMandrillが行い、d=yourdomain.comで署名するのでアライメントが一致します。 |
| CNAME | mte2._domainkey | dkim2.mandrillapp.comDKIM鍵2：Mandrillが鍵のローテーションに使う対のセレクターです。両方のCNAMEを追加し、従来方式のmandrill._domainkey TXTは使わないでください。 |
| CNAME | mandrillapp.com任意のカスタムreturn-path／トラッキング用サブドメインです（ホストは例）。SPFのアライメントとブランド独自のリンクが得られます。必ずサブドメインにしてください。ルートドメインにCNAMEを設定してはいけません。 | |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com2024年3月15日以降に必須となった最低限の設定です（少なくともp=none）。ドメインごとに1つだけにします。自分で追加するレコードで、Mandrillが作成することはありません。後からquarantine/rejectへ引き上げてください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Mandrill (Mailchimp Transactional)の設定がこの上限のうち何回を消費するかは、次のとおりです。
Mandrill (Mailchimp Transactional)は10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
MandrillでDMARCの成功を実際に支えるのはDKIMで、その設定は2024年に変わりました。従来方式は古いチュートリアルに今も記載されていますが、mandrill._domainkey.yourdomain.comに共通のMandrill公開鍵を格納する1つのTXTレコードでした。これは非推奨です。2024年3月15日以降、必須の設定は2つのCNAMEレコードです。mte1._domainkeyはdkim1.mandrillapp.comを指し、mte2._domainkeyはdkim2.mandrillapp.comを指します。貼り付けるTXTレコードではなくMandrillに委任するCNAMEなので、基盤となる鍵の保持とローテーションはMandrillが行います。dkim1.mandrillapp.comとdkim2.mandrillapp.comは実際のDKIM公開鍵（v=DKIM1; k=rsa; p=…）に解決され、Mandrillは送信メールにd=yourdomain.comで署名します。鍵の素材はMandrillの共有インフラのものですが、mte1/mte2セレクターが自社ドメイン上にあるので、署名は自社ドメインとアライメントが一致します。手順としては、Sending Domainsで2つのCNAMEを表示し、DNSホストで両方を公開します（Cloudflareの場合は「DNS only」（グレーのクラウド）にし、ホストの重複を避けるためラベルのみを入力します）。その後、Test DNS Settingsをクリックします。方式を混在させないでください。mte1/mte2の2つのCNAMEを追加し、以前の設定で残っている古いmandrill._domainkeyのTXTレコードがあれば削除します。
DMARC
DMARCは、自社ドメインに設定する別のポリシー用TXTレコードで、Mandrillは作成しません。2024年3月15日以降は任意ではなく必須です。_dmarc.yourdomain.comに、v=DMARC1; p=none（Mailchimpが示す最低限の設定）で始まるレコードを公開します。実際には、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのようにレポート先のアドレスも追加してください。p=noneは監視のみのため、配信には影響しません。その間に集計レポート（rua）で、MandrillのメールがDKIMに自社ドメインとアライメントの一致した状態で成功していることを確認します。MandrillのDKIMはmte1/mte2セレクターを通じてd=yourdomain.comで署名するので、デフォルトではSPFのアライメントが一致しなくても、DKIMに基づくDMARCの成功がすぐに確認できるはずです。1～2週間、レポートを確認し、正当な送信者（Mandrillと、Google Workspace／Microsoft 365／マーケティングツールなど）がすべて認証されていることを確かめてから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。_dmarcレコードは組織ドメイン全体で1つだけにしてください。Mandrill専用に2つ目を追加してはいけません。サブドメインは、独自の_dmarcレコードで上書きしない限り、親ドメインのポリシーを継承します。
正しく設定できたか確認する
ダッシュボードの緑のチェックだけで判断せず、実際のメールで認証を確認してください。Mandrillでは、Settings → Domains → Sending DomainsにあるTest DNS SettingsボタンでSPFとDKIMを確認できます。カスタムのreturn-pathを設定した場合は、Tracking/return-path画面に別のTest DNS Settingsボタンがあります。次に、認証したドメインのアドレスからMandrillのAPIまたはSMTPでメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASS（d=yourdomain.com、mte1/mte2セレクター経由）とDMARC: PASSと表示されていれば成功です。カスタムのreturn-pathを設定していない場合、SPF / mailed-byにはmandrillapp.comが表示され、アライメントは不一致となります。これは想定どおりで、DMARCの成功はDKIMが支えています。レコードそのものは、dig CNAME mte1._domainkey.yourdomain.comとdig TXT _dmarc.yourdomain.comで個別に確認できます。最後に、Qualisendのドメイン診断でドメインをチェックし、SPFのinclude、両方のDKIM CNAME、DMARCレコードがすべて解決され、SPFが10回の上限内に収まっていることを確認します。集計レポートが届いたら、DMARCレポート解析にレポートをドロップします。Mailchimp Transactional／Mandrillが、アライメントが一致して成功している送信元として表示されるはずです。
よくある注意点
- DNS設定
2024年3月15日からのフォールバック：2つのDKIM CNAMEとDMARCレコードを公開しないと、メールは自社ドメイン名義で送信されなくなり、MandrillがFromアドレスをmandrillapp.comのサブドメインに書き換えます（返信は引き続き届きますが、自社ドメインにレピュテーションは蓄積されません）。DKIMとDMARCを完了すれば、書き換えは止まります。
- DNS設定
DKIMはTXTからCNAMEに移行しました。古いガイドには、mandrill._domainkeyに共通の公開鍵を格納する1つのTXTレコードを追加するとありますが、これは従来方式です。現在の要件は、mte1._domainkey → dkim1.mandrillapp.comとmte2._domainkey → dkim2.mandrillapp.comの2つのCNAMEです。両者を混在させないでください。
- 認証失敗の原因
デフォルトではSPFは成功してもアライメントは一致しません。include:spf.mandrillapp.comによりMandrillのIPに対するSPFチェック自体は成功しますが、デフォルトのReturn-Pathはmandrillapp.comのバウンス用ドメインなので、SPFは自社ドメインとアライメントが一致せず、単独ではDMARCに寄与しません。アライメントが一致する仕組みはDKIMです。カスタムのreturn-path用サブドメインは、アライメントの一致したSPFも特に必要な場合にのみ追加してください。
- DNS設定
カスタムのreturn-path／トラッキングドメインは必ずサブドメインにしてください。mandrillapp.comへのCNAMEはmail.yourdomain.comのようなホストに設定します。ルートドメインにCNAMEを設定してはいけません。ゾーン全体（MX、Webなどすべて）が乗っ取られることになります。
- DNS設定
Cloudflareのプロキシは設定の妨げになります。2つのDKIM CNAME（と、return-path／トラッキング用のCNAMEがあればそれも）を「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはmandrillapp.comに解決されず、Test DNS Settingsが失敗します。
- 認証失敗の原因
SPFレコードは1つだけにしてください。すでにGoogle Workspace、Microsoft 365、または別のリレーで送信している場合は、その1つのv=spf1の行にinclude:spf.mandrillapp.comをまとめます。SPFのTXTレコードが2つあるとPermErrorになります。消費するDNSルックアップは1回なので、負担なく併用できます。
- DNS設定
Mandrillのドメイン認証は、Mailchimp Marketingのドメイン認証とは別のものです。別々の製品でレコードも異なります。Mailchimp Marketingはk2/k3._domainkeyのCNAME（dkim2/dkim3.mcsv.net宛て）を使い、SPFのincludeは不要です。Mandrillはmte1/mte2._domainkeyのCNAMEを使い、include:spf.mandrillapp.comが必要です。実際に送信に使うほう（または両方）を設定してください。両者は競合しません。
- DNS設定
ホスト欄の重複：多くのレジストラはドメインを自動で付加するため、mte1._domainkey.yourdomain.comと入力するとmte1._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、ラベルのみ（mte1._domainkey、mte2._domainkey）を入力してください。
SPFレコードを作成
以下ではMandrill (Mailchimp Transactional)があらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Mandrill (Mailchimp Transactional)のSPFに関するよくある質問
関連記事
トランザクションメール・APIの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。