Q&A
基本的に SPFレコードは、消去法で作成するのではないです。
自ドメインを利用したメール送信を使用しているサービスに対して、必要な情報を追加していくものです。
メール送信を利用しているサービスを調べて、必要な SPF 情報を記載するのがよいのではないでしょうか。
お世話になります。
初投稿となり失礼な部分が御座いましたら申し訳ございません。
どなたか知見のある方いらっしゃいましたら、ご意見いただけますと有難く存じます。
よろしくお願いいたします。
実現したいこと
- SPFレコードに登録されている不要な設定の削除
前提
・ルックアップ回数が上限を超えておりSPFレコードの不要な設定を削除したい。
・過去に対応した人間は残っておらず、該当の設定が現在必要なものかどうかすら分からない。
該当のレコード
include:spf.bserver.jp
試したこと
・SPFレコードのチェック（https://powerdmarc.com/ja/spf-record-lookup/）
⇒ルックアップ回数が4回と多く、どこで使われているのかが分からない。
・「bserver.jp」で検索して、過去に利用したことがあるサービスが無いか確認
⇒様々なサービスのガイドページに掲載されているものの、いずれのサービスも利用したことがない。
①アイ・メール（https://imail-system.com/operation/archives/492）
②ナウゲッタメール（https://nowgettamail.com/doc/SPF_nowgetta.pdf）
③ECマスターズフォーラム（https://forum.ec-masters.net/post_view.php?id=5508）
④CAFE24（URL省略）
補足
過去に「飛猿」というメルマガ配信サービスを利用していたが、該当サービスは終了しWebページ等も既に残っていない。
以上になります。
2024年2月のGmailガイドライン改定に伴い、DKIM/DMARCの対応を行った際に判明しました。
現在のDNSサーバーの管理者も把握が出来ていない状況で、非常に困っております。
不要なレコードかどうかの判別方法や、該当レコードがどういったものなのか（各会社で利用されているので汎用的なものなのか）
など、何か「bserver.jp」についてご存じな方がいらっしゃいましたらご意見いただけますと幸いです。
どうぞよろしくお願いいたします。
お早いご回答ありがとうございます。ご指摘頂いた内容おっしゃる通りで耳が痛く思います…。
現在自ドメインでメール送信を利用しているサービスについて再度確認し、
「bserver.jp」を利用しているサービスがないかを改めて確認したいと思います。
質問ポイントが分かりません。
今の設定が内容不明なら、そんなものなど気にせず捨てて、必要な設定をすれば良いと思いますが。
必要な設定をする際に、
「私は、自分がどこからメールを送っているのか分かりません。それを調べる方法を教えてください」
ということなのでしょうか？
「ルックアップ回数」とはどういうものでしょうか。ご提示のリンク先を見ても何かのサービスの紹介ページらしきものが表示されるだけでわかりませんでした。
>> otn様
質問内容が分かりづらく申し訳ありません。
自ドメインのSPFレコードには現行使用しているメールサービスの設定が複数登録されており、その中に現在使用されているかが把握できていない設定（spf.bserver.jp）があるという状況になります。
また現在運用中のDNSサーバーになりますので、該当設定を削除した際に思わぬ影響が起きないかを懸念しており質問させて頂きました。
そのため、質問の内容としては「spf.bserver.jp」というものがどういったものかをお伺いしたく投稿させて頂きました。
>> ikedas様
私も勉強中ですので誤認しているかもしれませんが、
メール配信を行う際に自ドメインのSPFレコードに紐づけられたIPアドレスから送信されたメールは正当なメールとして承認するホワイトリストのようなものだと理解しております。
ルックアップ（認証されている送信元かどうかの確認）を行うのですが、こちらの上限が10件までと制限がありますが現在の設定では10件を超過してしまっているため、SPF設定が正常に動作しない可能性がある状態となっております。
> そのため、質問の内容としては「spf.bserver.jp」というものがどういったものかをお伺いしたく投稿させて頂きました。
それは最初から質問文に書いてあるので、分かってますが、なぜ spf.bserver.jp とかを気にするのか分からないと言うことです。
おそらく「自社がどこからメールを送っているのか分かりません。」ということなのですね。
セキュリティーの話なので、抜本策を採った方が良いと思います。
とここまで書いて、投稿前に快投へのコメントを見ると、
> 改めて自ドメインからメール送信しているものを洗い出して、利用していない設定は削除する方針で対応を進めていきたいと思います。
とお書きなので、そのようにされるのが良いかと思います。
>> otn様
ご回答いただきありがとうございます。
ご指摘の意図を上手くくみ取れず大変申し訳ございませんでした。「spf.bserver.jp」に捉われて、抜本的な解決策が見えておりませんでした。
「現状利用しているサービスの設定だけを残し、それ以外は削除する」方針で対応してみたいと思います。ご助言誠にありがとうございます。
回答3件
0
SPFレコードはメール送信元(エンベロープFROM)、ここでは*@bserver.jpから送信するサーバーのIPアドレスをDNSのTXTレコードでインターネット上に公開するものです。
まず、あなたはbserver.jpドメインの管理者である必要があります。
そうでないなら、もはやあなたに出来ることはありません。
ドメイン管理者であるなら、DNSレコードを変更する事ができるはずです。
現在のDNSサーバーの管理者も把握が出来ていない状況で、非常に困っております。
この状態ではSPFレコード以前の問題です。
まず、DNSの管理の状態を洗い出してまずはあなたが自由に管理できる状態にすることが最優先です。
もしどうしようもないのであれば、bserver.jpからのメール送信を諦めて新しいドメインを取得して、SPF、DKIM、DMARCの設定を行った上で新しいドメインからメールを送信する事を検討するのが現実的でしょう。
メール送信はどうしても＠bserver.jpからメールを送りたいといった自分たちの都合でどうにかできるものではありません。
ドメインの管理すらまともにできない人間には扱えないものです。
投稿2024/02/07 16:03
総合スコア4190
>> mingos様
ご回答ありがとうございます。
管理状態が煩雑という点については返す言葉もございません…。
自ドメイン（仮にexample.com）のDNSサーバーの管理権限はありますが、こちらに紐づいているSPFレコードの中身の精査を行っていたところ「spf.bserver.jp」が現在も使用しているものかの確認が取れず、削除しようにもできない状況となっております。
改めて、自ドメインからメール送信を行っているものを洗い出し、「bserver.jp」から送信されるサービスが現在利用されていない確認が取れ次第、該当設定を削除してみたいと思います。
私の回答に説明を追記しました。
回答見ましたけど、結局質問者さんが自分たちのサービスがどのIPからメールを送信しているのかを把握できていないのが一番の問題であることに変わりありません。
OEMだから問題ないでしょってそんなわけないでしょう。現在利用していないサービスのSPFレコードであるなら削除するべきです。
もっといえば、私はSMTPレリーサービスを提供する事業者側なので何も知らないということもありません。
bserver.jpがどういうものかいちいち調べるのが面倒だったので、回答の仕方が雑だった事は認めます。
いや、そんなこと言ってないです。OEMだということと、問題かどうかとは関係ないですよ。
「組織のどこかの部署で過去に何らかのメール送信サービスを契約したが、それの技術的な仕様を理解している人がいなかった」というのは十分ありうる話です。契約時に組織の情シス (とかそういう部署) にリソースレコード設定の依頼が来て、言われたからやったけどその当時は影響範囲把握する必要を感じなかったとかも、ありそうな話です。
そのようないきさつを、現在たまさかDNSリソースレコードの精査をしなければならなくなった担当者さんの責に帰することはできませんよね、と、私が言いたいのはただそれだけです。
回答を訂正なさらないのでしょうか。
> まず、あなたはbserver.jpドメインの管理者である必要があります。
> そうでないなら、もはやあなたに出来ることはありません。
> ドメイン管理者であるなら、DNSレコードを変更する事ができるはずです。
こういった発言は、「bserver.jpに関係する設定は自組織では使われていないことが自明のことである」とミスリードするものです。実際は私の回答で述べたように、当該ドメインの管理権限がなくても自組織のリソースレコードにこの設定が必要である可能性はあります。
事業者側のかたであれば、特にDNSなどの設定の廃止可否には慎重になられるものではないでしょうか。
0
皆様
ご報告が遅れ大変申し訳ございません。
たくさんのご回答、ご助言誠にありがとうございます。
DNSサーバの管理担当者との最終確認を行いまして、
「bserver.jp」の設定は除外し経過観察を行うこととなりました。
現在社内で把握出来ているメールサービスのSPF設定は全て網羅されておりましたため、
該当設定を除外する判断となりました。
数々の皆様のご意見を頂けたことで、こちらの判断に踏み切れた部分も多分に御座います。
今後は定期的なメンテナンスや管理が煩雑とならぬように管理体制をを見直していきたいと思います。
この度は数々のご意見頂きまして誠にありがとうございました。
また何か皆様にお伺いさせて頂く機会が御座いましたら、ご助言頂けますと幸いでございます。
ご回答いただきました皆様、誠にありがとうございました。
※ベストアンサーに関しては、様々な情報を調べて頂いたikedas様を選ばせて頂きました。
皆様のご意見、大変力強くおひとりを選ぶのは難しかったため、上記の理由で選ばせて頂いております。
ご了承ください。
投稿2024/02/14 02:55
編集2024/02/14 02:59総合スコア1
0
ベストアンサー
【訂正・追記あり】
ご質問にあるincludeメカニズム記述は株式会社ラクスが提供するメール送信サービスで、利用者が自組織のメールアドレスからメールを発信する場合に必要とされているようです。
ただし、同社はこのサービスを他社にOEM供給もしているようで、いくつかのサービスでこの設定を行うよう指示している例が見受けられます。
- アイ・メール操作サポートページ「SPFレコードについて」
- Cafe24 Help Center よくある質問
このほかにもあるとおもわれます。
質問者さんの組織のどこかの部署で、現在も上記のようなサービスのどれかを使ってメールを発信しているのなら、この記述は必要でしょう。そういうことがないのなら不要です。
使っているかどうかを知る方法ですが、部外者である当サイトユーザにはわかりません。
上記のいずれかのサービスに心当たりがないのなら、だめ元でOEM元のラクス社に聞いてみることも考えられます。
どうしようもなければ、問題の記述をSPFレコードから削除してみるといいです。そのうち「なんか最近、メールが送れなくなったんだけど」とどこかの部署から問い合わせがあったら、まだ使っているということです。——冗談で言っているわけではなく、何も手がかりがなければそうするしかないです。その際は、事前に組織内で十ぅ分にアナウンスをして、自分が責任取らされないようにしてからやったほうがいいですね。
【追記】
このSPFレコード設定は、自組織のドメインのメールアドレスを発信元として、bserver.jpドメインを管理する組織が運用するメールサーバを送信元サーバとして、メールを発信したい場合に、自組織のドメインのリソースレコードに追加するものです。この種のSPFレコードの設定は、メールサーバが自組織の管理下にない場合に、メールサーバの管理組織側から要求されることがよくあります (例えば、Microsoft 365のメールサーバを使って自組織のメールアドレスからメールを発信したい場合などに、このような設定を自組織のドメインのSPFレコードに追加するなど)。
「質問のようなリソースレコードの設定を行うことは、bserver.jpドメインの管理権限がなければ意味がない」といった説明をしておられるかたがおられますが、SPFのincludeメカニズムの上記のような用法についてあまりご存知ないのかと思います。
投稿2024/02/08 04:23
編集2024/02/09 14:50総合スコア4443
>> ikedas様
ご回答いただきありがとうございます。
ご指摘頂いた「アイ・メール」に関しましても認識しておりますが、質問の中に記載いたしました別サービスでも同様の設定が用いられているため、混乱している状態になります。
※記載しておりますサービスは何れも利用していないことは確認済みになります。
改めて自ドメインからメール送信しているものを洗い出して、利用していない設定は削除する方針で対応を進めていきたいと思います。
あなたの回答
tips
プレビュー
