Rackspace Emailの​SPF・DKIM・DMARC設定。

Rackspace Emailを認証すべき理由

Rackspace Emailのドメイン認証は、メールが受信トレイに届くかどうかを左右します。また、Rackspaceには構造上の癖が1つあり、SPFで止めてしまうと気づかないうちにDMARCが機能しなくなります。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook/Hotmail/Live宛ての大量メールに同じ要件の適用を始めました。少量の送信者でも、有効な認証の有無で評価されることが増えています。Rackspace特有の問題はこうです。Rackspaceは、エンベロープ送信者（Return-Path、バウンスアドレス）をRackspace自身のドメインのいずれかにしてメールを送信し、カスタムReturn-Pathやバウンス用ドメインを設定する手段を提供していません。つまり、include:emailsrvr.comでSPFのチェック自体には成功しても、SPFのアライメントがFromドメインと一致することはなく、DMARCはSPFから何も得られません。残るアライメントの一致した仕組みは、自社ドメインとして署名するDKIMだけです。DKIMを有効にすれば、DKIMのアライメントでDMARCに成功し、築いた送信レピュテーションは、認証していない他のRackspace送信者とひとまとめにされず、自社ドメインに蓄積されます。省略すると、アライメントの一致した認証はまったくない状態になります。

Rackspace EmailにおけるSPFの実情

Rackspaceは、実際にincludeで認証するサービスです。ルートドメインにある1つのSPFのTXTレコードに、共有メカニズムのinclude:emailsrvr.comを1つ追加します。レコード全体はv=spf1 include:emailsrvr.com ~allで、Rackspaceは修飾子として~all（softfail）を推奨しています。これは実際に機能する、素直なincludeです。emailsrvr.comの実際のSPFレコードは、ip4:の範囲を並べて~allで終わる1つのフラットなリストで、入れ子のincludeはありません。そのため、消費するのは10回のDNSルックアップのうちちょうど1回です。ただし、ほとんどのRackspaceのチュートリアルが触れていない点があります。このincludeを公開しても、DMARCに成功するようにはなりません。Rackspaceは、すべてのメールを、エンベロープ送信者（Return-Path）をお客様のドメインではなくRackspaceのドメインのいずれかにして送信し、カスタムReturn-Pathやバウンス用ドメインのオプションを提供していません。SPFは常にそのエンベロープのドメインに対して評価されるため、include:emailsrvr.comでチェック自体に成功しても、組織のFromドメインとアライメントが一致することはありません。DMARCがSPFを評価するのは、アライメントが一致した場合だけです。それでもinclude:emailsrvr.comは公開してください。Rackspaceの送信IPを許可し、SPFのチェック自体の成功を確認する受信側の要件を満たします。ただし、必要ではあるものの十分ではないと考えてください。ここでDMARCの成功を支える唯一の仕組みは、d=yourdomain.comとして署名するDKIMです。また、SPFレコードは1つだけにしてください。Google Workspace、Microsoft 365、またはメール配信サービス（ESP）からも送信する場合は、2つ目のSPFレコードを公開せず、すべてのメカニズムを1つのv=spf1の行にまとめてください（SPFレコードが2つあるとPermErrorになります）。

設定手順

追加するレコード

正確な値はRackspace Emailのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Rackspace Emailの設定がこの上限のうち何回を消費するかは、次のとおりです。

正しく設定できたか確認する

Control PanelのDKIMの「verified」バッジだけで判断せず、実際のメールで確認してください。そのドメインのRackspaceメールボックスから自分宛てにテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASS（d=yourdomain.com）、DMARC: PASSと表示されていれば成功です。エンベロープ/Return-PathがRackspaceのドメインにあるため、SPFは成功と表示されてもアライメントは一致しないはずです。これはRackspaceでは正常で、DKIMがDMARCの成功を支えなければならない理由そのものです。成功の典型的な兆候は、DKIMによるDMARC: PASSです。Control PanelのSender Authentication (DKIM)では、ドメインが有効、TXTレコードが確認済みと表示されるはずです。その後、Qualisendのドメイン診断でドメインをチェックし、SPF、DKIMセレクターのTXTレコード、DMARCレコードがすべて問題なく解決され、SPFがDNSルックアップの10回制限内に収まっていることを確認します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップしてください。Rackspace / emailsrvr.comが、DKIMのアライメントで成功する送信元として表示されるはずです。

よくある注意点

• 適用範囲

  Rackspaceで最大の注意点：SPFのアライメントは決して一致しません。RackspaceはReturn-Path（エンベロープ）をRackspace自身のドメインに置き、カスタムのバウンス用ドメインを提供していないため、include:emailsrvr.comでチェック自体には成功しても、DMARCには何も寄与しません。アライメントの一致した唯一の仕組みは、d=yourdomain.comとして署名するDKIMです。有効化は任意ではなく必須です。

• DNS設定

  DKIMの有効化に必要な操作は1つではなく2つです。Enable DKIMをクリックして鍵を生成し、TXTレコードを公開し、その後でVerify TXT Recordをクリックします。Rackspaceが署名を始めるのは確認の後だけです。生成しただけで確認していない（または公開していない）鍵では、すべてのチェックに失敗します。

• DNS設定

  RackspaceがDNSをホストしている場合（ネームサーバーがRackspaceを指している場合）、パネルがDKIMレコードを自動で公開します。手動でも追加すると、重複や競合が発生します。DNSが別の場所にある場合は、TXT Record KeyとValueを自分でゾーンにコピーする必要があります。

• 適用範囲

  DKIMが確認されるまで、DMARCポリシーをp=noneより先に引き上げないでください。RackspaceではSPFのアライメントが一致しないため、DKIMがオフのままp=quarantineやp=rejectにすると、自社の正規のメールが隔離または拒否されます。

• DNS設定

  RackspaceのDKIMは、公開鍵を直接記載した静的なTXTレコードです。Microsoft 365や多くのESP（SendGrid、Mailchimpなど）のように、Rackspaceへ委任するCNAMEではありません。Rackspaceは裏側で鍵をローテーションできないため、パネルで鍵を再生成した場合は、新しいTXTの値を公開し直す必要があります。

• 認証失敗の原因

  ドメインのSPFのTXTレコードは1つだけにします。Google Workspace、Microsoft 365、またはESPからも送信する場合は、include:emailsrvr.comを1つのv=spf1の行にまとめてください。SPFレコードが2つあると、それ自体がPermErrorになります。

• 適用範囲

  -allではなく~allを使ってください。これはRackspace自身の推奨で、他のツールからも正規に送信している可能性があるためです。-allにするのは、すべての送信元が1つのSPFレコードに記載された後だけにしてください。

• DNS設定

  メールボックスの設定では、Rackspaceの汎用的なCloud DNSの記事「create a DKIM TXT record」（自分でセレクターを考える手順）に従わないでください。Cloud OfficeやRackspace Emailのユーザーは、Control PanelのSender Authentication (DKIM) → Enable DKIMの手順を使います。この手順ではセレクターと鍵が生成されます。

SPFレコードを作成

以下ではRackspace Emailがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。

Rackspace EmailのSPFに関するよくある質問

関連記事

ワークスペース・メールボックスの他のサービス

• Titan
• Yandex 360
• Zoho Mail
• Apple iCloud+ Custom Email Domain
• Fastmail
• Google Workspace
• mailbox.org
• Microsoft 365

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。