mailbox.orgのSPF・DKIM・DMARC設定。
mailbox.orgは、Heinlein Supportが運営する、プライバシー重視のドイツのメールサービスです。独自ドメインの認証には、DNSホストで公開する3つの要素を使います。共有のSPFのinclude（include:mailbox.org）が1つ、mailbox.orgの署名鍵をmailbox.org側に委任する4つのDKIM CNAMEレコード、そして自分で追加するDMARCポリシーレコードです。アカウントごとの鍵の生成はなく、DNSを書き込んでくれるウィザードもありません。mailbox.orgは固定の共有DKIMセレクター（MBO0001～MBO0004）を使うため、独自ドメインを使う利用者は全員が同じ4つのCNAMEを公開します。mailbox.orgは自身のスマートホストから、ユーザーのアドレスをエンベロープ送信者としてメールを送信します。そのため、これらのレコードが有効になると、SPFとDKIMの両方で自社ドメインとのアライメントが一致し、どちらのメカニズムでもDMARCに成功します。メールはmailbox.orgとしてではなく、自社として完全に認証された状態で送信されます。
mailbox.orgを認証すべき理由
mailbox.orgのドメインの認証は、メールが受信トレイに届くかどうかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail宛ての大量メールに同じ要件の適用を始めました。中小企業や個人のドメインであっても、認証されていないメールは迷惑メールフォルダーへの最短ルートです。mailbox.orgは一括送信向けのメール配信サービス（ESP）ではなく実際のメールボックスサービスですが、仕組みは同じです。mailbox.orgは、独自ドメインの送信メールにMBOセレクターを使ってd=yourdomain.comとして署名し、受信側はMBO0001._domainkey.yourdomain.comを参照してその署名を検証します。4つのCNAMEを公開していなければ、この参照は失敗し、自社ドメインのDKIMは検証されず、DMARCにはアライメントが一致した拠り所がなくなります。SPF、DKIM CNAME、DMARCを公開すれば、このギャップは解消されます。両方のメカニズムで自社ドメインとのアライメントが一致し、転送後でもDMARCに成功します。築いた送信レピュテーションも、認証されていない送信者とひとまとめにされず、自社ドメインに蓄積されます。
mailbox.orgにおけるSPFの実情
mailbox.orgは、実際に「include」で設定する方式のサービスです。共有メカニズムのinclude:mailbox.orgを1つ、ルートドメインの単一のSPF TXTレコードに追加します。レコード全体はv=spf1 include:mailbox.org ~allです。これはmailbox.orgのすべての利用者が使う本物の共有includeで、一括送信向けESPのCNAMEによる委任モデルとは異なります。このincludeの重要度が、Return-Pathをサービス側で管理するESPの場合より高いのは、mailbox.orgではエンベロープ送信者に利用者の独自ドメインが使われるからです。そのためSPFは組織ドメインと実際にアライメントが一致し、DKIMだけでなくSPF単独でもDMARCの成功に貢献します。知っておきたいサービス固有の点が1つあります。include:mailbox.orgは、10回のSPF DNSルックアップのうち、1回ではなく約2回を消費します。解決先の共有レコードはv=spf1 ip4:213.203.238.0/25 ip4:195.10.208.0/24 ip4:91.198.250.0/24 ip4:80.241.56.0/21 ip6:2001:67c:2050::/48 mx ~allで、include自体が1回、そのレコード内にネストされたmxメカニズムが2回目です。それでも消費は少ないほうですが、Google Workspace、マーケティングツール、トランザクションリレーのいずれかをすでに併用している場合は計算に入れてください。mailbox.orgは、自身のレコードでも使っている~all（softfail）で終えることを推奨しています。-allへの変更は、すべての送信者が記載されていると確信してからにしてください。また、ドメインのSPF TXTレコードは1つだけにします。他のサービスからも送信する場合は、2つ目のSPFレコードを公開せず、各メカニズムをその単一のv=spf1の行にまとめてください（SPFレコードが2つあるとPermErrorになります）。
設定手順
- 1
プランが独自ドメインに対応しているか確認
独自ドメインからの送信には有料プランが必要です。個人向けのStandardまたはPremiumアカウント、もしくはFamilyプランのサブアカウントが該当します。無料のLiteプランでは独自ドメインから送信できないため、必要に応じて先にアップグレードしてください。
- 2
ドメインを追加して確認
Webメールにログインし、歯車アイコン（右上）→ Settings / All settings → Email addressesを開いて、独自ドメインを登録します。所有権の証明の手順が案内され、必要なDNSレコードが表示されます。4つのDKIMセレクター（MBO0001～MBO0004）はmailbox.orgの固定の共有鍵で、ナレッジベース（kb.mailbox.org）に記載されています。アカウントごとに生成する鍵はありません。
- 3
MXをmailbox.orgに向ける（受信）
受信メールがメールボックスに届くよう、以前のサービスの既存MXレコードを削除し、mailbox.orgの独自ドメイン用ホストであるmxext1.mailbox.org、mxext2.mailbox.org、mxext3.mailbox.org（一部の設定ではmxext4も記載）をすべて優先度10で追加します。MXは認証ではなく受信のためのものですが、同じ設定の一部です。古いMXレコードを残すと、受信メールが分散します。
- 4
SPFレコードを公開
ルートドメイン（ホストは@または空欄）に、v=spf1 include:mailbox.org ~allのTXTレコードを1つ追加します。他の送信者のv=spf1レコードがすでにある場合は、include:mailbox.orgをその単一のレコードにまとめ、2つ目のSPF TXTは追加しないでください。mailbox.orgが推奨する~all（softfail）の修飾子はそのままにします。
- 5
4つのDKIM CNAMEを追加
mailbox.orgの署名が自社ドメインで検証されるよう、4つのCNAMEレコードを作成します。ホストMBO0001._domainkey → ターゲットMBO0001._domainkey.mailbox.orgとし、MBO0002、MBO0003、MBO0004も同じパターンです。4つすべてを公開してください。MBO0001/MBO0002にはRSA鍵、MBO0003/MBO0004にはEd25519鍵が入っており、mailbox.orgはどちらのアルゴリズムでも署名する可能性があります。タイプはCNAME（mailbox.orgの推奨方式）のままにし、AやTXTに変更しないでください。
- 6
ruaを含めてDMARCレコードを追加
mailbox.orgはDMARCを作成しません。ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加します。アライメントを確認する間は何にも影響しないよう、p=none（監視のみ）で始めます。ruaタグは必ず含めてください。mailbox.org自身のガイダンスは、RFCに準拠しない動作ではあるものの、DMARCレコードにレポートアドレスがないと一部の受信側がメールを拒否すると警告しています。
- 7
CNAMEをグレーのクラウドにし、ホストの二重付加を防ぐ
DNSがCloudflareの配下にある場合は、各DKIM CNAMEを「DNS only」（グレーのクラウド）に設定します。プロキシ有効（オレンジのクラウド）のCNAMEはmailbox.orgのホストに解決されず、DKIMの検証が失敗します。また、多くのレジストラはドメインを自動で付け足します。二重付加を防ぐため、ラベルだけを入力してください（MBO0001._domainkey.yourdomain.comではなくMBO0001._domainkey）。
- 8
テストメールを送信してヘッダーを確認
DNSの反映後（通常は数分、最大48時間）、mailbox.orgの独自ドメインのアドレスからGmailアカウントにメールを送り、開いて⋮ → Show originalを選びます。SPF: PASS、d=yourdomain.comと、MBOセレクターのうちの1つを伴うDKIM: PASS、DMARC: PASSと表示され、すべて自社ドメインとアライメントが一致していれば成功です。その後、ドメイン診断でドメインをチェックし、すべてのレコードが解決されることを確認します。
追加するレコード
正確な値はmailbox.orgのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:mailbox.org ~allルートドメインのSPF：SPFレコードは1つだけにし、他の送信者はこの行にまとめます。DNSルックアップを約2回消費します（includeと、mailbox.orgの共有レコード内にネストされたmx）。 |
| CNAME | MBO0001._domainkey | MBO0001._domainkey.mailbox.orgDKIMセレクター1（RSA）。固定の共有値で、mailbox.orgで独自ドメインを使う全利用者に共通です。 |
| CNAME | MBO0002._domainkey | MBO0002._domainkey.mailbox.orgDKIMセレクター2（RSA）。MBO0001とあわせて公開します。 |
| CNAME | MBO0003._domainkey | MBO0003._domainkey.mailbox.orgDKIMセレクター3（Ed25519）。新しいアルゴリズムの鍵です。Ed25519で署名されたメールを検証できるよう、これも公開してください。 |
| CNAME | MBO0004._domainkey | MBO0004._domainkey.mailbox.orgDKIMセレクター4（Ed25519）。4つの固定セレクターの4つ目です。CNAMEによる委任により、DNSに触れなくてもmailbox.orgが鍵をローテーションできます。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。mailbox.orgは作成しません。1ドメインにつき1つで、ruaタグは必ず含めます。p=noneで始め、その後引き上げます。 |
| MX | @ | mxext1.mailbox.org (priority 10)認証ではなく受信のためのものです。mxext2.mailbox.orgとmxext3.mailbox.org（一部の設定ではmxext4も記載）も優先度10で追加し、先に以前のサービスのMXを削除してください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。mailbox.orgの設定がこの上限のうち何回を消費するかは、次のとおりです。
mailbox.orgは10回のルックアップのうち2回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
mailbox.orgのDKIMは、固定された4つの共有セレクターへのCNAMEによる委任で機能します。生成やコピーが必要な鍵はありません。MBO0001._domainkey、MBO0002._domainkey、MBO0003._domainkey、MBO0004._domainkeyの4つのCNAMEレコードを公開し、それぞれ対応するMBO000X._domainkey.mailbox.orgのホストを指すようにします。貼り付けるTXTレコードではなくCNAMEなので、秘密鍵はmailbox.orgが保持し、これらのセレクターの先にある公開鍵をDNSの再編集なしでローテーションできます。mailbox.orgの設定には特徴が2つあります。1つ目は、mailbox.orgが2種類の鍵を公開しているため、セレクターが4つあることです。MBO0001とMBO0002にはRSA鍵、MBO0003とMBO0004には新しい方式のEd25519鍵が入っています。mailbox.orgはどちらのアルゴリズムでも署名する可能性があるため、4つすべてを公開する必要があります。Ed25519の2つ（またはいずれか1つのセレクター）を省くと、公開していないセレクターの鍵で署名されたときにDKIMが断続的に失敗します。2つ目は、mailbox.orgが従来方式のTXTよりCNAME方式を明確に推奨していることです。CNAMEなら、mailbox.orgが鍵を変更する必要が生じても委任はそのまま解決されますが、一度コピーしたTXTレコードはmailbox.orgがローテーションした時点で無効になります。4つのCNAMEをすべて表示どおりに公開してください。Cloudflareの場合は「DNS only」（グレーのクラウド）に設定します。これでDKIMはd=yourdomain.comとして署名され、アライメントが一致します。
DMARC
DMARCは、自分で公開する別のポリシーTXTレコードです。mailbox.orgは作成しません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを追加します。p=noneは監視のみのため、配信には影響せず、その間に集計レポート（rua）でmailbox.orgのメールがSPFとDKIMに自社ドメインとアライメントが一致した状態で成功しているか確認できます。mailbox.org固有の事情として、ruaタグを省いてはいけない理由があります。mailbox.org自身のナレッジベースは、DMARCレコードにruaアドレスがないと一部の受信サーバーがメールを拒否すると警告しています。DMARCのRFCには準拠していない動作ですが、実際に起きています。必ずレポート用のメールボックスを含めてください。mailbox.orgでは、SPFはエンベロープに使われる利用者の独自ドメインを通じて、DKIMはMBOセレクターを通じて、どちらもアライメントが一致します。そのため、成功はすぐに確認できるはずです。1～2週間レポートを確認し、すべての正規の送信者が認証されていることを確かめたら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。送信者の数にかかわらず、_dmarcレコードはドメイン全体で1つだけにしてください。参考までに、mailbox.org自身のドメインはp=rejectで運用されています。
正しく設定できたか確認する
mailbox.orgのドメイン設定画面だけに頼らず、実際のメールで認証を確認してください。独自ドメインのアドレスからGmailアカウントにテストメールを送り、開いて⋮ → Show originalを選びます。SPF: PASS、d=yourdomain.comと、MBO000Xセレクターのうちの1つを示すDKIM: PASS（署名ドメインがmailbox.orgではないこと）、DMARC: PASSと表示され、すべて自社ドメインとアライメントが一致していれば成功です。詳しいレポートが必要な場合は、check-auth@verifier.port25.comにテストメールを送ると、SPF/DKIM/DMARCの詳細な内訳がメールで返ってきます。レコードは、dig TXT yourdomain.com、dig CNAME MBO0001._domainkey.yourdomain.com、dig TXT _dmarc.yourdomain.comでも直接確認できます。最後に、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決され、SPFが10回の上限内に収まっていることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。mailbox.orgがアライメント一致で成功している送信元として表示されるはずです。
よくある注意点
- 適用範囲
独自ドメインには有料プランが必要です。独自ドメインから送信できるのは、個人向けのStandardとPremiumのアカウント（またはFamilyプランのサブアカウント）だけです。無料のLiteプランでは送信できないため、DNSをどれだけ正しく設定しても、アップグレードするまでメールは認証されません。
- DNS設定
DKIM CNAMEは1つではなく4つすべてを公開してください。MBO0001/MBO0002はRSA鍵、MBO0003/MBO0004はEd25519鍵で、mailbox.orgはどちらのアルゴリズムでも署名する可能性があります。セレクターを省くと、公開していない鍵で署名されたときにDKIMが断続的に失敗します。
- 認証失敗の原因
include:mailbox.orgはSPFのルックアップを1回ではなく約2回消費します。mailbox.orgの共有SPFレコードはmxメカニズムで終わる（v=spf1 ip4:… ip6:… mx ~all）ため、includeが1回、ネストされたmxが2回目です。Google Workspace、マーケティングツール、リレーのいずれかも併用する場合は、10回の上限を考慮して計算に入れてください。
- DNS設定
DKIMにはTXTではなくCNAMEを使ってください。mailbox.orgは鍵を透過的にローテーションできるCNAMEによる委任を推奨しています。従来方式のTXTは、コピーした公開鍵が古くなるため、mailbox.orgが鍵を変更した時点で壊れます。
- 適用範囲
DMARCのruaタグは決して省かないでください。mailbox.org自身のガイダンスは、DMARCレコードにレポートアドレスがないと一部の受信側がメールを拒否すると警告しています。RFCに準拠しない動作ですが、今も起きているため、監視モードでも必ずrua=mailto:…を含めてください。
- 適用範囲
先に古いMXレコードを削除してください。mxext1/mxext2/mxext3.mailbox.org（優先度10）を追加する前に、以前のサービスのMXレコードが残っていれば削除します。残っていると、受信メールが2つのシステムに分散します。
- DNS設定
CNAMEをグレーのクラウドにし、ホストを二重に付加しないでください。Cloudflareでは各DKIM CNAMEを「DNS only」に設定します（オレンジのクラウドのプロキシを使うと正しく解決されません）。レジストラがドメインを自動で付け足す場合はラベル（MBO0001._domainkey）だけを入力してください。そうしないとMBO0001._domainkey.yourdomain.com.yourdomain.comになります。
- 認証失敗の原因
SPFレコードは1つだけにし、~allを使ってください。他のサービスからも送信する場合は、2つ目のSPF TXTを公開せず（2つあるとPermErrorになります）、include:mailbox.orgを単一のv=spf1の行にまとめ、mailbox.orgが推奨するsoftfailの~allを維持します。
SPFレコードを作成
以下ではmailbox.orgがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証mailbox.orgのSPFに関するよくある質問
関連記事
ワークスペース・メールボックスの他のサービス
- Microsoft 365
- Microsoft 365 (GoDaddy / IONOS)
- Migadu
- Namecheap Private Email
- Proton Mail
- Purelymail
- Rackspace Email
- Titan
公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。