PowerSPF

PowerSPF

SPFの設定を簡単に、制限を乗り越える

Plus Premium Platinum

上記3プランで、追加料金なくご利用いただけます(ZoneAPEXの場合)。

PowerSPFとは、SPFを強化した機能です。
SPFマクロ機能によってMTAの情報を隠蔽するステルス型のセキュリティにより、DNS Lookup10回の制限を超えるだけでなく、Attack Surface Management(攻撃対象領域管理)の観点からも重要な役割を果たします。

ZoneAPEX(ドメイン本体)でPowerSPFをご利用いただく分には、Plusプラン・Premiumプラン・Platinumプランで追加料金なくご利用いただけます。
サブドメインでもPowerSPFをご利用になりたい場合には、別途追加料金が発生しますので、あらかじめご了承ください。

PowerSPFの仕組み

PowerSPF機能の詳細図
PowerSPF機能の詳細図

PowerSPFは、「SPF Flattening」という革新的な機能を備えています。
この機能の理解には、まずSPFのDNS Lookupに関する10回という制限について知る必要があります。

SPFレコードのDNS Lookup制限

SPFレコードには、DNS Lookupが最大10回までという仕様上の制限があります。
自社のメール送信システム（MTA）だけでなく、サードパーティーのメールサービスを使用する場合、この制限を超えることがよくあります。
この制限を超えると、「permerror」というエラーが発生し、10回を超えたところからSPF検証が失敗します。

許可MTAのIPリストの統合

PowerSPFの「SPF Flattening」機能は、許可されたMTAのリストを20分に1回事前に問い合わせてリスト化します。
従来、この問題は、メール管理者の方が手動でincludeの中のIPアドレスを取り出して登録することが行われてきました。
PowerSPFの手法は、MTAのIPアドレスが更新された場合でも、リアルタイムで反映されるため、IPリストは常に最新の状態となります。

この仕組みによって、許可MTAのIPリストは1つだけとなり、DNS Lookupは1回だけで済みます。

SPFマクロ機能によるMTAの隠蔽化

PowerSPFは、2023年夏に仕様を変更し、SPFマクロ機能を使うように実装し直しました。
従来のPowerSPFは、SPFの問い合わせに対して、全てのIPリストを返していましたが、攻撃者にとっては、ドメインのMTAのIPリストを一括で入手できることになります。
そこでWebの隠蔽化と同様に、MTAについても、問い合わせがあったIPについてだけ存在するかどうかを返すことで、MTAのリストを入手できないようにしました。

DNS上では、以下のように登録します。 


TXT "v=spf1 include:d5bge7q7zs.powerspf.com -all"

このincludeは、御社専用になります。
この中身は、以下のように記載されています。 


"v=spf1 exists:%{i}.d5bge7q7zs.macrospf.powerspf.com -all"

例えば、GoogleのMTA(209.85.97.188)について、問い合わせがあったとしましょう。
すると、以下のように、%{i}の箇所に、当該MTAのIPアドレスが入り、このIPが存在している場合には、52.208.175.186が返されます。
52.208.175.186は、PowerDMARCが管理する実IPアドレスです。

SPFが見ているのは、返るIPの値ではなくDNSの応答結果

ここで誤解しやすい点として、SPFのexistsメカニズムは、返ってくるIPアドレスの値そのものを見ているわけではありません。
見ているのは、DNSクエリが成功して回答が得られたかどうかという、DNSの応答結果(レスポンスコード、RCODE)です。

つまり、52.208.175.186という値の中身自体には意味がなく、SPF検証エンジンもその値を一切見ていません。
「回答が返ってきたかどうか」という存在確認だけを行っている、というのが実際の仕組みです。

※以前は、DNS Lookupのたびに、問い合わせのあったMTAのIPアドレスに応じて異なるAレコードをリアルタイムで生成・返却する実装でした。
2025年4月からは、RFC5737で文書化アドレスとして予約されている192.0.2.0/24レンジの192.0.2.1を固定的に返す実装に変更しました。
これは、以下のような課題があったためです。

さらに2026年6月からは、PowerDMARCが管理する実IPアドレスである52.208.175.186(IPv6の場合は2600:1f18:dd1:7300::edeb)を返す仕様に変更されています。
この応答は、問い合わせているMTAのIPアドレスがIPv4かIPv6かに関わらず同じです。

nslookupでは、AレコードとAAAAレコードの両方が返ります。
Aレコードは52.208.175.186、AAAAレコードは2600:1f18:dd1:7300::edebで、いずれもPowerDMARCが管理する実IPアドレスです。
digの場合は、+shortを付けると、存在している場合だけIPが戻り、存在しない場合は無回答です。

nslookupを使った例

$ nslookup 209.85.97.188.d5bge7q7zs.macrospf.powerspf.com
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   209.85.97.188.d5bge7q7zs.macrospf.powerspf.com
Address: 52.208.175.186
Name:   209.85.97.188.d5bge7q7zs.macrospf.powerspf.com
Address: 2600:1f18:dd1:7300::edeb
digを使った例(Aレコード)

$ dig +short 209.85.97.188.d5bge7q7zs.macrospf.powerspf.com A
52.208.175.186
digを使った例(AAAAレコード)

$ dig +short 209.85.97.188.d5bge7q7zs.macrospf.powerspf.com AAAA
2600:1f18:dd1:7300::edeb

IPv6のMTA(例: 2607:f8b0:4864:20::431)について問い合わせた場合も、返る値は同じです。
%{i}の箇所に入るMTAのアドレスがIPv4かIPv6かに関わらず、応答するAレコードとAAAAレコードの値は変わりません。

Attack Surface Management (ASM) への貢献

PowerSPFは、メールセキュリティだけでなく、サイバーセキュリティの重要課題であるAttack Surface Management（攻撃対象領域管理）の観点からも極めて有効です。

攻撃者によるサプライチェーンの偵察を防止

従来のSPFレコード（フラット化されたIPリストやincludeの羅列）は、DNSを通じて全世界に公開されています。
攻撃者は、企業のDNSレコードを調査（偵察）することで、「この企業はGoogle Workspaceを使っている」「Salesforceを使っている」「Marketoを使っている」といった利用サービス（サプライチェーン）を特定できてしまいます。

利用しているSaaSやクラウドサービスが特定されると、攻撃者はそのサービスになりすました精巧なフィッシングメール（なりすましメール）を作成し、標的型攻撃を行うリスクが高まります。

ステルス型セキュリティによる防御

PowerSPFのSPFマクロ機能は、問い合わせがあったIPアドレスに対してのみ応答を返す、ステルス型セキュリティの仕組みを採用しています。
これにより、自社が利用している全MTA（送信元メールサーバー）のリストを、攻撃者に一括で把握されることがありません。

攻撃者から見えるのは、個別に問い合わせたIPが許可リストに含まれているかどうかという結果だけであり、全体像を外部から窺い知ることはできません。
このように情報を外部から隠すステルス型セキュリティによって、攻撃の予兆段階である「偵察」を無効化し、組織の攻撃対象領域（アタックサーフェス）を縮小させることができます。

UDPのデータ容量超過の防止

DNSは、基本的にUDPを使います。
UDPは、1パケットあたり512バイトの制限があります。
PowerSPFは、SPFマクロ機能を使うことで、問い合わせがあったMTAが許可リストに含まれているかどうかについてのみ、固定的な短い応答を返すことで、UDPのデータ容量超過を防止します。

もしも、許可リストに存在しない場合は、単純にNXDOMAINかNODATAを返します。

無制限の許可MTAのリスト

メルマガ配信や、SFA、請求書発行など各種SaaSを使っていると、DNS Lookup 10回の制限によって、SPFに登録できるincludeの数に限りがあります。
しかし、PowerSPFは、上述のような仕組みであるため、無制限に許可MTAのリストを登録可能です。

ネストされたincludeのメカニズム上書き機能

SPFレコードを設定する際に見落とされがちな点として、includeを使用して他のドメインを参照している場合があります。
この場合、参照先のドメインがSoftfail（~all）を指定していると、自分のドメインのSPFレコードがHardfail（-all）であっても、その部分はSoftfailとして扱われることになります。

自社ドメインはHardfailでも、実質的にSoftfailになる例
自社ドメインはHardfailでも、実質的にSoftfailになる例

つまり、他のドメインの設定に依存してしまうことで、自分のメールセキュリティが意図せず弱まる可能性があります。
このような状況を防ぐために、PowerSPFは、ネストされたincludeのメカニズム上書き機能を提供しています。
この機能を使用することで、include先がSoftfailであってもHardfailに上書きし、より強固なメールセキュリティを確保することが可能です。

ネストされたincludeのメカニズム上書き機能
ネストされたincludeのメカニズム上書き機能

PowerSPFを活用することで、外部ドメインに依存せず、全体のメール認証の一貫性と安全性を保つことができます。

分析

分析機能によって、どのincludeやIPアドレスから、何通のメールが送信されているかを確認できます。
これにより、SPFに記載があっても、使われていないものを検出して削除することが可能です。

PowerSPFの分析機能
PowerSPFの分析機能

診断

診断機能によって、SPFレコードに関連する問題や警告メッセージだけでなく、PowerSPFが自動修正できる場合は修正します。
それをどのように修正できるかについての推奨事項を確認できます。

PowerSPFの診断機能
PowerSPFの診断機能

includeしているサードパーティーのSPFレコードで文法エラーがあると、自社のSPFがPermErrorとなってしまいます。
それを防ぐ上で、PowerSPFの診断機能は、とても重要です。

よくある質問

PowerSPFに切り替える手順を教えてください。

  1. ポータルのPowerSPFで、「セットアップを有効にする」をOnにします。
  2. 20分ほど待ちます。
    PowerSPFの許可リストは20分に1回更新されるため、この間にPowerDMARC側でPowerSPFのセットアップが行われます。
  3. ポータルで「有効」と緑色に表示されたことを確認します。
  4. 「ステータスを設定」が「設定済」になっていることを確認します。
    「未設定」のままの場合は、左下の「SPFレコードを保存」ボタンを押してください。
  5. DNSのSPFレコードを、ポータルに表示されるPowerSPFのinclude（例：v=spf1 include:d5bge7q7zs.powerspf.com -all）に書き換えます。
  6. PowerDMARC側でDNSの確認ができると、DNSステータスが「有効化されました」と表示されます。

ポータルでの有効化は、御社のDNSのSPFレコードを変更しません。
そのため、有効化しただけでは、現在のメール送信に影響しません。

DNSを切り替える前に、送信元IPごとの許可判定を確認できますか？

確認できます。
「有効」と緑色に表示され、「ステータスを設定」が「設定済」になった時点で、PowerDMARC側のセットアップが完了し、include先が応答します。
この状態になれば、DNSを切り替える前に、次のように確認できます。

include先のレコードを確認する例

$ dig +short TXT d5bge7q7zs.powerspf.com
送信元IP(例: 209.85.97.188)が許可リストに含まれるかを確認する例

$ dig +short 209.85.97.188.d5bge7q7zs.macrospf.powerspf.com A

許可リストに含まれる場合はAレコードが返り、含まれない場合は無回答です。
d5bge7q7zsの部分は、御社専用のIDに置き換えてください。

SPF Analyticsの前提条件「PowerSPF Activated」は、ポータルでの有効化だけで満たされますか？

満たされません。
DNSのSPFレコードをPowerSPFのincludeに書き換え、PowerDMARC側でDNSの確認ができると、DNSステータスが「有効化されました」と表示されます。
この状態が「PowerSPF Activated」です。
DNSを書き換えた後は、受信側のリゾルバで従来のSPFレコードのキャッシュが切れたところから、順にPowerSPFへのクエリが始まります。
そのため、SPF Analyticsの集計も、キャッシュが切れた受信側の分から順に始まります。
すべての受信側で切り替わるまでの時間は、従来のSPFレコードのTTLが目安です。

メール配信サービスを追加するには、どうすればよいですか？

ポータルのPowerSPFに、送信元を追加してください。
追加した送信元は、20分に1回の更新で許可リストに反映されます。
DNSのSPFレコードを書き換える必要はありません。

PowerSPFを使うと、DNS Lookupは何回になりますか？

基本は、PowerSPFのinclude 1回と、include先のexists 1回の計2回です。
ただし、送信元のSPFレコード自体がSPFマクロを使っている場合は、送信元IPアドレスごとに問い合わせ先が変わるため、許可リストに事前に統合できません。
この場合、そのマクロはinclude先のレコードに残ります。
例えば、Salesforceの_spf.salesforce.comに記載されているexists:%{i}._spf.mta.salesforce.comは、include先のレコードに残ります。
SPFマクロを使ったexistsも、DNS Lookupの回数に数えられます。
（RFC 7208 Section 4.6.4） 


"v=spf1 exists:%{i}.d5bge7q7zs.macrospf.powerspf.com exists:%{i}._spf.mta.salesforce.com -all"

上の例では、PowerSPFのinclude、PowerSPFのexists、Salesforceのexistsの3回になります。

SPFレコードの末尾は、~allと-allのどちらにすべきですか？

-allを推奨します。
-allは、SPFレコードに記載した送信元以外は認可していない、という明示的な表明です。
受信側が「認可されていない」と確定的に判定できるのは、-allの場合だけです。
（RFC 7208 Section 2.1）

ただし、SPFのfailだけを理由にSMTPの段階で拒否する受信側では、SPFに登録していない正規の送信元からのメールが、DMARCの評価より前に拒否されます。
この受信側に送られたメールは、DMARCの集計レポートにも現れません。
（RFC 9989 Section 7.1）
そのため、DNSをPowerSPFに切り替える前に、自ドメインをMAIL FROM（エンベロープ送信者）に使う正規の送信元を、すべてPowerSPFに登録してください。
詳しくは、SPFは-allにすべき理由 ― ~allとの違いとDMARC運用での注意点で解説しています。

契約を終了すると、PowerSPFはどうなりますか？

契約終了時は、弊社がお客様のテナントを即座に削除します。
その時点で、PowerSPFも機能を停止し、include先は応答しなくなります。
猶予期間はありません。
契約を終了される場合は、契約終了日より前に、DNSのSPFレコードをPowerSPFを使わない形式に戻してください。
PowerSPFを使わない形式に戻すと、DNS Lookupが10回を超える場合があるため、戻す前に送信元の整理が必要です。

DNSサービスの移行（NSの切替）とPowerSPFへの切替は、どちらを先に行えばよいですか？

両者の間に、技術的な依存関係はありません。
注意が必要なのは、NSの切替の期間中は、移行前と移行後のDNSサービスの両方が応答し得ることです。
この期間にSPFレコードを変更する場合は、両方のゾーンに同じ内容を設定してください。