共用レンタルサーバーのSPFは「本人確認」になっていない｜DMARCをrejectにしても防げない穴

日本の中小企業のメール認証を調べていると、繰り返し出てくる設定があります。

v=spf1 include:spf.sender.xserver.jp ~all
v=spf1 a:wwwXXXX.sakura.ne.jp mx ~all

共用レンタルサーバーの送信基盤を、SPFで丸ごと許可する書き方です。

レンタルサーバー各社のマニュアルどおりに設定すればこうなるので、設定した側に落ち度はありません。しかしこの設定には、DMARCを最も強い p=reject にしても塞がらない穴があります。

今回は、その仕組みと、何をすればよいか、そして対策にともなう副作用を整理していきたいと思います。

日本企業のどれくらいが該当するのか

当社では、健康経営優良法人2026の認定法人約27,000社を対象に、公開DNS上のSPF・DMARCの設定状況を調べています。

このうち、MXレコードやSPFレコードの内容から、メールの基盤が国内の共用レンタルサーバーだと判定できた法人は 7,731社、集計対象の約4割 でした。

SPFの include に国内レンタルサーバーの送信基盤を書いている法人を事業者別に数えると、延べ約8,000社にのぼります（1社で複数の事業者を書いている場合があるため延べ数）。

この7,731社のDMARCの状況は、次のとおりです。

半数はDMARCがなく、p=reject まで到達しているのは1%未満です。この記事は「rejectにしても防げない穴」の話ですが、その手前で止まっている企業のほうがはるかに多い、というのが実態です。

母集団は健康経営優良法人の認定法人で、日本企業全体ではありません。ただ、中小企業のWebサイトとメールの多くが共用レンタルサーバーで動いている構図は、全国に共通するものと考えてよさそうです。

なぜDMARCで防げないのか

メールの送信元認証は、3つの仕組みの組み合わせです。

• SPF：このドメインのメールはこのIPアドレスから送る、と宣言する
• DKIM：送信側が秘密鍵で署名し、受信側が公開鍵で検証する
• DMARC：SPFかDKIMのどちらかが合格し、そのドメインが表示上の差出人（ヘッダーFrom）と一致すれば合格。不合格の扱いを none／quarantine／reject で指定する

ポイントは、DMARCが「SPF か DKIM」で合格することです。

共用レンタルサーバーから送られるメールは、事業者の送信用IP群から出ていきます。このIPは、ほかの契約者と共用です。SPFはIPしか見ないので、同じIPから出てきたメールであれば、誰が送ったかに関係なく合格します。

攻撃者が同じ共用基盤から、エンベロープFrom（SMTPの MAIL FROM）を被害企業のドメインにして送れた場合、次のようになります。

1. SPFは合格（IPが一致）
2. SPFのドメインとヘッダーFromが一致するので、アライメントも成立
3. DMARCは合格。p=reject でも通る

DKIMは攻撃者には署名できませんが、DMARCは「どちらか」で足りるので、SPFだけで通ってしまいます。DMARCは本人確認の結果を見る仕組みであって、SPFが本人確認として機能していなければ、DMARCも機能しません。

サイバー犯罪の温床？本当に悪用できるのか

ここは事業者の作りによります。多くのレンタルサーバーは、SMTP認証で送るときにエンベロープFromを契約者のアドレスに制限しています。この制限があれば、他人のドメインを名乗った時点で拒否されます。

問題は、もう1つの送信経路です。

想定例：隣の契約者のWordPressが踏み台になる

架空の例で説明します。

• A社は example.jp のWebサイトを共用レンタルサーバーで運用している。SPFはマニュアルどおり include:事業者の送信基盤 ~all。DMARCは p=reject
• B社は同じサーバーの別の契約者。古いプラグインを放置したWordPressが改ざんされ、攻撃者のPHPスクリプトが置かれた

攻撃者のスクリプトがすることは、PHPの mail() を呼ぶだけです。

mail(
  'target@customer.example',
  '【重要】お振込先変更のお知らせ',
  $body,
  "From: 経理部 <keiri@example.jp>",   // A社のドメインを名乗る
  "-f keiri@example.jp"               // エンベロープFrom（MAIL FROM）もA社に
);

mail() は、サーバー内の送信プログラム（sendmail互換のコマンド）にメールを渡します。この受け渡しは、同じサーバーの中で完結する「ローカルの処理」なので、SMTP認証を通りません。送信プログラムは、受け取ったメールを事業者の送信用IP群から外に出します。

受信側（たとえばGmail）から見ると、このメールは次のように見えます。

Return-Path: <keiri@example.jp>
From: 経理部 <keiri@example.jp>
Received: from mail-xx.共用基盤.example (203.0.113.10)
Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.jp;
       dkim=none;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.jp

送信IP 203.0.113.10 は、A社のSPFが許可している事業者の基盤に含まれています。SPFは合格。MAIL FROMのドメインとヘッダーFromのドメインは、どちらも example.jp で一致。DMARCは合格です。

A社が p=reject にしていても、このメールは拒否の対象になりません。A社の正規のメールと、B社の領域から出た偽装メールは、受信側から見て同じ結果になります。

A社は何も間違えていません。マニュアルどおりにSPFを書き、DMARCを最も強い設定にしています。

それでも、同じサーバーにいる誰かのWordPressが改ざんされた時点で、A社のドメインは「認証に合格するなりすまし」に使える状態になります。

改ざんされたWordPressがスパムやフィッシングの踏み台になる事件は珍しくなく、どのドメインを名乗るかは、攻撃者の都合次第です。

事業者の作りで防げる場合もある

この経路が通るかどうかは、事業者の設定次第です。

mail() や sendmail からの送信でも、エンベロープFromやヘッダーFromを「その領域の契約者が持つドメイン」に制限している事業者なら、上の例は送信の時点で止まります。逆に、送信元を自由に指定できる作りなら、そのまま通ります。

事業者ごとの仕様は公開されていない部分が多く、しかも変わります。当社でも、自社が契約するレンタルサーバーで、自社管理のテスト用ドメインを使って検証を進めているところです。結果は別の記事で報告します。

現時点で確実に言えるのは、「共用基盤をSPFに書いた企業は、SPFの上では同じ基盤のほかの利用者と区別がつかない」ということまでです。

セキュリティ対策と世界標準による対策は

この問題は、2024年のセキュリティ会議 NDSS で発表された論文「BreakSPF」が正面から扱っています。

中国の清華大学のグループが、

• クラウド
• プロキシ
• CDN

など IP を共有する基盤を使ってSPFをすり抜ける攻撃の枠組みを示し、Tranco上位100万ドメインのうち23,916ドメインが攻撃可能だと報告しました。

論文の結論は「多くのドメインが同じメール事業者のSPFを include する構造が、SPFの脆弱性を拡大している」というものです。日本の共用レンタルサーバーは、この構造そのものです。

標準の側も動いています。

2026年5月に発行されたDMARCの新しい仕様 RFC 9989 は、p=reject を公開するドメインについて「SPFだけでDMARCに合格させてはならず、有効なDKIM署名を付けなければならない」と定めました（7.4節）。

主な動機は転送でSPFが壊れることですが、「SPFを安全網にするな」という原則は、共用基盤の問題にもそのまま当てはまります。

対策：DKIMを本人確認の軸にする

共用サーバーを使い続ける限り、SPFを「自社だけ」に絞ることはできません。送信IPが共用である以上、SPFは事業者の基盤より細かくなりません。したがって対策はSPFの修正ではなく、本人確認の軸をDKIMに移すことです。

1. DKIMを有効にする。 主要なレンタルサーバーは、管理画面から設定できます。DKIMの鍵はドメインごとに発行され、同じIPから送られても他人には署名できません
2. すべての送信経路にDKIMを付ける。 メールソフト、Webフォームの通知、会計SaaS、メール配信サービス、複合機。自社ドメインを名乗る経路は全部です。1つでも漏れると、その経路の正規のメールが拒否されます
3. DMARCの集約レポートで確認する。 共用基盤のIPから自社ドメインを名乗るメールが、自社の送信量と合っているかを見ます。多ければ、誰かが使っています。なりすましのメールは「SPF合格・DKIMなし」で現れるので、DKIMが全経路でそろっていれば見分けられます
4. メールの送信を共用サーバーから切り離せるなら、SPFの include を外す。 メール送信を Google Workspace や Microsoft 365 に寄せ、共用サーバーをWebだけに使う構成にすれば、共用基盤を許可する理由がなくなり、穴そのものが閉じます

なぜ Google Workspace や Microsoft 365 に移すと安全なのか

ここで素朴な疑問が出ます。Google Workspace も Microsoft 365 も、送信IPは何百万という契約者で共用です。

SPFに書く include:_spf.google.com や include:spf.protection.outlook.com は、共用レンタルサーバーの include と、IPを共有しているという点では同じです。BreakSPFの論文も、クラウドのメール基盤を攻撃の対象に含めています。

それでも「移せば安全」と言えるのは、IPが違うからではなく、送信の手前で本人確認をしているからです。

（１）検証済みのドメインでしか送れない

Google Workspace と Microsoft 365 は、ドメインをテナントに追加するときに、DNSへの確認用レコードの設置を求めます。

「このドメインの管理者はこの契約者だ」と確かめたうえで、そのテナントの利用者は、検証済みのドメインのアドレスでしかメールを送れません。別の契約者のドメインを差出人に書いても、送信の時点で拒否されます。

共用レンタルサーバーの mail() 経由には、この確認がありません。同じサーバーにいる誰でも、好きなドメインを差出人に書いて送れる作りになっていることがあります。

（２）送信は必ず「認証を通った利用者」からになる

クラウドのメール基盤から送る経路は、ログインしたアカウント（SMTP認証やOAuth）か、テナントの管理者が許可したコネクタに限られます。「サーバー上で動いているプログラムが、認証なしで送信用のプロセスに直接メールを渡す」という経路がありません。先ほどの想定例で改ざんされたWordPressが踏み台になれたのは、この経路があるからです。

（３）DKIM署名が標準で付く

Google Workspace は、ドメインを追加すれば管理コンソールからDKIMを発行でき、送るメールすべてに署名が付きます。

Microsoft 365 も、独自ドメインのDKIMを有効にすれば同様です（有効にしないと onmicrosoft.com のドメインで署名され、Fromと一致しません。この点は見落とされがちです）。

署名の鍵はテナントごと・ドメインごとなので、同じIPを使う他の契約者には署名できません。

つまり、SPFの include:spf.protection.outlook.com は「Microsoftの基盤からのメールを許可する」という意味ですが、その基盤は「誰が、どのドメインで送っているか」を送信前に確かめています。共用レンタルサーバーの include にはその裏付けがない。これが違いです。

それでもセキュリティ対策として完全ではない

クラウドの基盤にも、過去に穴は見つかっています。2024年には、Microsoft 365 のテナントを経由して有名企業のドメインをなりすます手口（EchoSpoofing）が報告されました。

Microsoft 365 には、認証なしで自社テナント宛てに自社ドメインを名乗って送れる「Direct Send」という機能もあり、Microsoftは2025年にこれを拒否する設定を追加しています。

ただ、これらはプラットフォームの設定や機能の問題で、見つかれば塞がれます。

共用レンタルサーバーの「IPを共有している以上、SPFでは区別できない」という問題は、SPFの仕組みそのものに由来するため、設定で塞ぐことができません。

ここが本質的な違いです。移した後もDMARCの集約レポートで監視を続ける必要があることは変わりません。

Webサイトからの通知メールはどうするか

送信を移すときに残りがちなのが、問い合わせフォームやECの注文通知など、Webサーバー上のプログラムが送るメールです。

これらは、共用サーバーの mail() から送るのをやめ、SMTP認証付きで Google Workspace や Microsoft 365、あるいはDKIM署名に対応した配信サービス（SendGrid、Amazon SES など）に渡す形にします。

WordPressなら、SMTPプラグインで送信先を切り替えるだけで済むことが多いはずです。

ただし、SPFを外すと到達率が下がることがある

ここで注意が必要です。対策4を「共用サーバーからメールを送ったまま、SPFから include だけを外す」と読み違えると、自社の正規のメールがSPFに失敗するようになります。DKIMがあればDMARCには合格しますが、受信側はDMARCの結果だけを見ているわけではありません。

Microsoftの大量送信者ルールは「SPFも合格」を求めている

Microsoftは2025年5月から、Outlook.com宛てに1日5,000通を超えて送るドメインに対して、SPFの合格、DKIMの合格、DMARC（p=none以上でSPFかDKIMと一致）の3つすべてを求めています。

要件を満たさないメールは 550 5.7.515 で拒否されます（Microsoft Defender for Office 365 Blog）。GoogleとYahooも2024年2月から、同じ規模の送信者にSPFとDKIMの両方を求めています。

つまり、ある程度の量を送るドメインでは、「DKIMがあればSPFは要らない」は成り立ちません。SPFを外した瞬間に、Outlook.com宛てが拒否される可能性があります。

少量の送信者でも、SPFの失敗は評価を下げうる

1日5,000通に届かない送信者でも、SPFの失敗（fail／softfail）は受信側の判定材料の1つです。DMARCに合格していれば受信拒否にはなりにくいものの、迷惑メールフォルダに入りやすくなる方向に働くと考えておくべきです。特にMicrosoftは、SPFの結果を重く見る傾向があるとされています。

現実的な選び方

共用サーバーから送るメールが残っているなら、SPFの include は残したまま、DKIMを全経路にそろえるのが現実的です。

この状態では、同じ基盤からのなりすましを「拒否」はできませんが、DMARCレポートで「SPF合格・DKIMなし」のメールとして見分けられます。穴を閉じるのではなく、穴を監視する、という考え方です。

穴そのものを閉じたいなら、メールの送信を共用サーバーから完全に切り離してから include を外します。順番が逆になると、自社のメールが届かなくなります。

なお、SPFの末尾は ~all（softfail）のままにしておくことをおすすめします。DMARCは -all と ~all を区別しませんが、-all は一部の受信側でDMARCの評価の前に拒否されることがあるため、転送などで一時的にSPFが失敗したときの被害が大きくなります（Mailhardenerのブログがこの点を明快に説明しています）。

まとめ

• 共用レンタルサーバーの送信基盤をSPFで許可すると、SPFの上ではほかの契約者と区別がつかない
• この状態ではDMARCを p=reject にしても、SPF経由のなりすましは止まらない
• 対策は、全送信経路でのDKIMの有効化。RFC 9989 も「SPFだけに頼るな」と明記した
• Google Workspace や Microsoft 365 が安全なのは、IPが違うからではなく、検証済みのドメインでしか送れない仕組みがあるから
• ただし、共用サーバーから送ったままSPFを外すと、自社のメールの到達率が下がる。穴を閉じるには、送信を切り離してからSPFを外す

「DMARCを入れたから安心」ではなく、「DKIMが全経路で通っているか」「SPFとDKIMのどちらで合格しているか」を確認することが、中小企業のメール認証の次の一歩です。

弊社では、DMARCの集約レポートから「どの経路がSPF・DKIMのどちらで合格しているか」を可視化するPowerDMARCと、DMARC導入の支援を提供しています。共用レンタルサーバーを使いながらDKIMをそろえていく進め方や、送信基盤の切り離しの順番についてもご相談いただけます。