ITシステムの非機能要件（性能・信頼性・セキュリティ）の専門企業。大手を中心に350社以上を支援。全国7都市と世界各地から現地の回線で合成監視し、障害や遅延を実ユーザー視点で検知。Web高速化、DMARC、ゼロトラスト接続、OSINT調査を踏まえたステルス型セキュリティまで提供します。
東京都千代田区
Joined March 2015
- Tweets2.6K
- Following31
- Followers476
- Likes509
「メールヘッダ診断」は、ヘッダの解析をブラウザ内だけで行います。DNSの確認にはGoogle Public DNS（DNS over HTTPS）を使い、問い合わせるドメイン名の範囲をページに明記しています。社外のツールに受信メールを渡す前に、何がどこへ送られるかを確認できる設計です。
メールのヘッダを貼り付けるだけで、受信したメールのなりすましの兆候と、送信側の設定の安全性・到達性を確認できる無料ツール「メールヘッダ診断」を公開しました。
受信者向けには、Fromとアラインし、受信側で合格したSPF・DKIMが1つもなければ「なりすましメール」と表示します。本物の送信者のメールでも、アラインした認証が無ければDMARCはfailになるので、この判定になります。転送やメーリングリストを経たメールでも起こり得ます。
送信者向けには、DKIMの署名範囲、鍵長、SPF・DKIMのアライメント、DMARCポリシーなどを、安全性と到達性に分けてA〜Fで示します。ランクは最も悪い条件で決まります。ランクの基準はMailDataが定めたもので、RFCで定められたものではありません。各条件には、根拠となるRFCのSectionを添えています。
解析はブラウザの中だけで行い、ヘッダや本文をMailDataのサーバーに送りません。
maildata.jp/mail-header-chec…
送信ドメイン認証がpassしても、正規の送信基盤が署名した内容まで安全とは限りません。DKIMの署名対象ヘッダ、SPFの許可範囲、使わなくなった送信サービスを指すCNAMEは、送信サービスごとに定期的に棚卸しする運用項目です。
問い合わせフォームの自動返信に、お客様の入力内容をそのまま載せていませんか。
正規の送信基盤から送られ、DKIMで署名されたメールは、SPF・DKIM・DMARCをpassし、BIMIのロゴも表示されます。入力欄に攻撃者が文面を書けば、その文面が自社の正規メールとして届きます。GoogleのOAuthアプリ名、Robinhoodのアカウント登録項目は、どちらもこの経路で悪用されました。
自動返信を作っているのがWeb担当、メール認証を設定しているのが情報システム担当、という組織では、両者で一度、自動返信に何を載せているかを確認してみてください。載せるなら、通知用とは別のサブドメインから送り、BIMIを設定せず、HTMLはエスケープするのが記事の示す条件です。
maildata.jp/tips/input_echo_…
CSSの更新が反映されない問題は、個々の設定ミスよりも、キャッシュを誰が制御するかが決まっていないことから繰り返し起きます。
制御点をオリジンのCache-Controlに寄せ、変更後はレスポンスヘッダーを実測して確かめる手順を決めておくことが、運用品質の管理になります。
CSSやJavaScriptの ?ver= によるキャッシュバスティングが効くかどうかは、サイト側ではなく、CDNがクエリ文字列をキャッシュキーに含める設定かどうかで決まります。
CloudflareのStandardはクエリ文字列ごとに別のファイルとしてキャッシュしますが、CloudFrontの静的コンテンツ向け管理ポリシーCachingOptimizedはキャッシュキーに含めません。
同じサイトでも、CDNを乗り換えただけで ?ver= が効いたり効かなかったりします。
自分のCDNがどちらかは、一度も使っていない値を ?ver= に付けてcurlでリクエストすれば確かめられます。
初回からHITが返るなら、CDNはクエリ文字列を無視しています。
WordPressでは本体とプラグインの ?ver= が残るので、少なくとも ver はキャッシュキーに含める設定が必要です。
perfdata.jp/blog/blog-2026-0…
「リピーターはキャッシュが効いているから速い」という前提が、再訪問の速度を計測しない運用や、初回と再訪で分けた目標として、KPIに入り込んでいることがあります。
その前提が自社サイトで成り立つかは、再訪のページビューのヒット率と、層ごとのキャッシュの寿命を実測して確かめられます。
キャッシュの有効性は「1年キャッシュさせている」という設定値で語られがちですが、実ユーザーの端末に実際にどれだけ残っているかは、設定値からは分かりません。
RUMの標本は訪問回数に比例して集まるため、再訪のヒット率は訪問加重、キャッシュの寿命はユーザー加重と、知りたい量によって集計の重みを分ける必要があります。
寿命の推定は、再訪の時刻とキャッシュの消失が独立であることを前提にしています。
利用頻度の高いユーザーは短い経過時間に集まり、かつキャッシュも残りやすいため、全体で1本の曲線を引くと歪みます。
OS・ブラウザ・利用頻度・流入元で層別し、層の中での独立を仮定して読むのが現実的です。
必要な標本数は「層 × 時間の区間」のセル単位で見積もります。
寿命曲線には1セルあたり数百のユニークな識別子が必要で、訪問頻度の低い層ほど集まりにくくなります。
perfdata.jp/blog/blog-2026-0…
ブラウザキャッシュ、CDNのエッジキャッシュ、JVMのヒープは、いずれも「有限の領域に寿命の分からないものを置き、いっぱいになったら追い出す」同じ構造を持ち、生存関数で分析できます。 違うのは、何が生き残るかの条件だけです。
max-ageを1年にしても、ブラウザキャッシュが1年残るとは限りません。
キャッシュ領域は有限で全サイトに共有されるため、追い出しの時期はユーザーの閲覧量で決まり、事前には分かりません。
そのため、キャッシュの寿命は統計学の生存関数 S(t)＝P(T>t) で扱います。
今回の記事では、Chromium・Firefox・WebKitの追い出し方式がいずれもLRUの変種であることをソースコードで整理しました。
3つとも、大きいものと使われないものから消し、有効期限は追い出しの判断に使いません。
さらにCheの近似から、訪問頻度の低いユーザーには、訪問をまたいだキャッシュの再利用がほぼ効かないことを説明しています。
キャッシュ設計を経験則で決めている場合は、前提の確認に使ってください。
perfdata.jp/blog/blog-2026-0…
CDNは契約するだけでは速くなりません。 s-maxageの扱いはCDNごとに異なり、有効にするための前提設定もあります。 Akamai、Cloudflare、Fastly、CloudFront、Gcoreの挙動を比較した表を掲載しています。
Cache-Controlのmax-ageを「キャッシュの保存期間」だと考えていないでしょうか。
RFC 9111の定義では、max-ageは「問い合わせなしで再利用してよい期間」の宣言で、保存を保証するものではありません。
ChromiumとFirefoxのソースコードを確認すると、追い出しの基準は「最終利用からの経過時間×サイズ」や利用頻度で、max-ageは使われていません。
max-ageを短くしても、キャッシュ容量は空きません。
max-ageは「内容が変わったときにURLも変わるか」で決めるのが基本です。
ハッシュ付きURLは1年、同じURLで差し替えるHTMLや画像は、更新を反映させたい時間で決めます。
容量の制約に効くのは、サイトの総リソース量とCDNの使い方です。
perfdata.jp/blog/blog-2026-0…
静的ファイルをサイトと異なる登録可能ドメインで配信していると、Safariではサードパーティとして扱われ、HTTPキャッシュがサイトごとに分割されます。
同じ登録可能ドメインのサブドメインで配信すれば、ファーストパーティのままです。
CDN導入時のホスト名設計で確認すべき点です。
静的ファイルにmax-age=31536000を付けて「リピーターには1年キャッシュが残る」と考えていないでしょうか。
max-ageが決めるのは「いつまでfreshか」だけで、「いつまで保存するか」ではありません。
実際の保持期間は、ブラウザのキャッシュ容量、追い出しの処理、ユーザー操作、OSの状態で決まります。
Facebookの2015年の計測では、平均44.6%のユーザーが空のキャッシュでアクセスしていました。
さらに、Android WebViewの既定のキャッシュ容量は20MiBで、アプリごとに分かれています。
SNSのリンクから開かれたページは、リピーターでも実質的に初回訪問です。
再訪時もキャッシュがない前提で、初回表示の性能を確保してください。
perfdata.jp/blog/blog-2026-0…
開催は明日10/16(金) 10:00からです。
サーバー側の監視では見えない「シャドー障害」を、国内7都市・4キャリアの実回線から捉える方法を解説します。参加無料。
【10/16 ウェビナー】監視は正常、しかし利用者側では起きている「シャドー障害」に気づいていますか？
サーバーやクラウドの監視は整備されていても、それが見ているのはデータセンターの内側です。
利用者はモバイル回線、DNS、CDN、TLSを経由してサービスに到達しており、この区間で起きる遅延や接続失敗は、サーバー側の監視には現れません。
弊社の実測では、同一サイトでもキャリアによって表示完了時間に30秒以上の差が生じた例があります。
本セミナーでは、監視には現れないが利用者側では実際に起きている障害を「シャドー障害」と呼び、以下を解説します。
・データセンター側の監視でシャドー障害を捉えられない理由
・RUMやクラウド上の合成監視では捉えられない範囲
・国内7都市・4キャリアの実SIM・実回線による合成監視で、異常を利用者より先に捉える方法
・自社起因か通信事業者起因かを切り分ける進め方
・シャドー障害による売上の取りこぼしを、自社の数字で試算する考え方
対象：Webサービス・アプリのインフラ、SRE、運用監視の担当者、カスタマーサポート責任者、プロダクト責任者
日時：2026年10月16日（金）10:00〜11:00
形式：オンライン（マジセミ）
参加費：無料
申込：majisemi.com/e/c/spelldata-2…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
2026年5月公開の「Tailscaleやめたい」で指摘された7項目（resolv.conf、EDNS、100.64/10、netfilter、MTU、ACL、SSO）を、26件の主張に分解し、2026年9月時点の一次資料で再検証しました。
判定の内訳は次のとおりです。
・当時は正しかったが修正済み: 2件（EDNSのTC bit未設定など）
・事実誤認・解釈の間違い: 12件（RFC 6891の引用、iptablesの送信元／宛先、ECSの原因など）
・Tailscaleとの考え方の違い: 8件（allow-onlyのACL、SSO必須、MTU 1280など）
・現在も未解決: 4件（resolv.confのoptions非保持、CGNAT drop ruleの範囲指定不可、Calicoとのfwmark競合など）
元記事が掘り起こした不具合は実在し、修正されました。その指摘には敬意を持っています。
一方で、元記事を前提にTailscaleの導入を判断する企業が、修正済みの問題や誤った解釈で判断を誤ることは避けたいと考え、正規代理店として一次資料に基づく検証を公開します。
RFC、公式文書、GitHub Issue、現行ソースコードへのリンクをすべて記事内に示しています。
velumesh.jp/blog/blog-2026-0…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
Happy Birthday, Avi Wigderson! Wigderson received the 2023 #ACMTuringAward for foundational contributions to the theory of computation, reshaping our understanding of randomness in computing, and decades of intellectual leadership in theoretical computer science.
Born in Haifa, Israel in 1956 to Holocaust survivors, Wigderson is a pioneering mind in theoretical computer science and mathematics. His groundbreaking work includes zero‑knowledge proofs, allowing someone to mathematically convince another party with certainty that they have a solution without revealing any details about it. Today, this powers secure credit card smart chips and modern privacy-focused cryptographic protocols. He has also made landmark discoveries in pseudorandomness, the zig‑zag expander construction, and circuit and communication complexity.
🔗 buff.ly/d6V6zLH
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
ドメインやサブドメインが増えると危険、という話ではありません。危険なのは「作ったまま忘れられたDNSレコード」です。
外部サービスの利用を終了したあと、shop.example.com のようなサブドメインが参照先のないレコードを残したままになっていると、攻撃者が参照先のリソースを取得してそのサブドメインを乗っ取れる場合があります。2022年から2024年にかけて確認されたSubdoMailingキャンペーンでは、著名ブランドに関連する8,000を超えるサブドメインが乗っ取られ、フィッシングメールの送信に悪用されました。信頼されているブランド名が含まれていたことが、フィルタ回避に働いています。
SPF/DKIM/DMARCはメールの認証を担いますが、DNSレコードの消し忘れそのものは防ぎません。
まず、保有ドメインとサブドメインの一覧を最新化し、参照先が存在しないレコードを削除してください。棚卸しは認証設計の前提です。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
DomainKeysは2004年にYahooが公開したメール認証の先駆けですが、現在は廃止されています。
置き換わった理由は、暗号技術の弱さではなく運用に耐えなかった点にあります。セレクタがないためドメインに公開鍵は1つしか持てず、鍵のローテーションも送信サービスごとの使い分けも困難でした。署名条件も厳格で、転送やメーリングリストによる軽微な変更で無効になりやすいという問題がありました。
DKIMは、セレクタによる複数鍵の管理、h=タグでの署名対象ヘッダの選択、bh=タグの本文ハッシュとCanonicalizationによって、この課題を解消しています。
ただしDKIMが検証するのは署名のd=ドメインであり、受信者に表示されるFromヘッダとの一致までは確認しません。そこを担保するのがDMARCのアライメントです。DKIMは「導入した」ではなく「鍵と設定を運用し続けられているか」で評価してください。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
認証情報の窃取が厄介なのは、盗まれた後のログインが「正規のログイン」として通ってしまう点です。
2024年のChange Healthcareの事案では、攻撃者が盗んだ認証情報を使い、多要素認証が設定されていなかったリモートアクセス用のCitrixポータルへログインしました。
そこから横展開され、ランサムウェアが展開されたのは9日後です。
影響を受けた人数は、最終的に約1億9,270万人と報告されています。
読み取れるのは、対策を「入口」だけで考えると足りない、ということです。
・入口の前：なりすましメールを届かせない（SPF / DKIM / DMARC）
・入口：パスワードだけで通さない（フィッシング耐性のあるMFA）
・入口の後：普段と違うログインや設定変更に気付く（監視）
9日間、誰も気付かなかったという点が、3つ目の重みを示しています。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
FBIのIC3が公表した2024年の年次報告では、報告件数は859,532件で、前年からわずかに減少しました。
一方、報告された損失額は166億ドルで、前年比33%の増加です。
件数が減って損失額が増えたということは、1件あたりの被害が大きくなっているということです。
同報告では、平均損失額は約19,372ドルとされています。
サイバー詐欺は、システムの脆弱性を突く攻撃とは性質が異なります。
狙われるのは、人の判断そのものです。
だからこそ、対策は二層で考える必要があります。
ひとつは、人が判断する前に、なりすましメールを届かせない層（SPF / DKIM / DMARC）。
もうひとつは、人が判断した後の層（振込先変更は別経路で確認、支払いは複数人承認）。
どちらか一方だけでは、止まりません。
サイバー詐欺の手口と対策を整理しました。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
DMARCをp=rejectへ移行する際は、送信元の整理やSPF/DKIMアライメントの確認だけでなく、社内外へのコミュニケーションも必要になります。
特に社内では、未申請の送信元によるメール不達を防ぐため、適用日や影響範囲、申請方法を事前に共有しておくことが重要です。
一方、社外向けには、p=rejectの効果を過大に表現せず、受信側の判断も含めて正確に説明する必要があります。
社内通知、プレスリリース、Webサイト掲載の文章例を、実務で使いやすい形に整理しました。
maildata.jp/tips/dmarc_rejec…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
サイバー詐欺は年々深刻化しており、企業の金銭的損失やブランドの信頼低下に直結する経営課題となっています。
背景として、FBIのInternet Crime Complaint Center（IC3）が公表した2024年版報告書では、被害報告が85万9,532件、損失額は160億ドルを超え、前年比33％増となったことが示されています。
この中でも、経営幹部や取引先になりすまして不正送金を誘導するビジネスメール詐欺（BEC）は、企業にとって特に被害額が大きい手口の一つです。
洞察として、BECは技術的な脆弱性ではなく、メールが信頼できる送信者から届いたように見える点を悪用しており、従業員の判断だけに依存する対策には限界があります。
実務的示唆として、送金や機密情報に関する依頼はメール以外の手段で本人確認を行う運用ルールの整備に加え、DMARC・SPF・DKIMによるメール認証を組み合わせた多層的な対策が必要です。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
フィッシング対策として従業員研修を実施している組織は多いものの、その効果には限界があることを示すデータがあります。
ある調査では、フィッシング研修を実施しても、8か月後のフィッシングリンクのクリック率はわずか2％しか低下しなかったと報告されています。
背景には、フィッシングメールが技術的な脆弱性だけでなく、緊急性や不安を煽る心理的な手口を巧みに利用しているという事情があります。
このデータから得られる洞察は、教育だけに依存した対策には構造的な限界があるということです。
実務的示唆として、DMARC・SPF・DKIMによるメール認証、MFAの有効化、送信元確認の習慣化を組み合わせた多層防御の構築が、教育と並行して必要になります。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
政府機関を騙るフィッシングメールは、個人の情報詐取にとどまらず、行政への信頼低下や社会的混乱にまで影響が及ぶ可能性があります。
背景として、政府ドメインは高い信頼性を持つがゆえに、攻撃者にとって価値の高いなりすまし対象になりやすいという構造があります。
米国のBinding Operational Directive 18-01は、連邦政府機関に対しSPF/DKIM/DMARCの導入と集約レポートの活用を求めています。
英国やニュージーランドでも、p=rejectポリシーの適用が政策として進められてきました。
洞察として、政府機関のDMARC導入は民間企業と同じ技術的手順を踏みますが、影響範囲の大きさゆえに中央管理された段階的導入がより重要になります。
実務的示唆として、送信元の棚卸し、SPF/DKIMの整備、p=noneによる監視を経て、p=quarantine、p=rejectへ段階的に移行する運用体制の有無が、行政機関の信頼維持に直結します。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
DMARCを導入したものの、認証失敗の原因を特定できずに放置している組織は少なくありません。
背景には、DMARCが「一度DNSに設定すれば完了する仕組み」だという誤解があります。
実際には、新しいSaaSやマーケティングツールの追加、送信元の変更など、メール環境は常に変化します。
PowerDMARCのシニアアナリストの知見によれば、日々の認証失敗の多くは外部攻撃ではなく、社内で把握されていない「シャドーIT」に起因します。
IT部門の承認を経ずに導入されたサービスがSPF/DKIMを正しく設定していないケースが典型例です。
実務的な示唆として、DMARCはp=noneによる可視化から始め、正当な送信元を洗い出したうえで、p=quarantine、p=rejectへと段階的に強制適用へ移行する運用体制が必要です。
自動化されたレポート基盤に加え、継続的に分析・調整を行う専門的な運用体制の有無が、DMARC導入の成否を分けます。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
【記事更新のお知らせ】
「DNS伝播を理解する:Webサイトの読み込み時間を短縮する秘訣」の内容を一部更新しました。
翻訳元記事に技術的な誤りがあったため、PowerDMARCへ確認・修正を依頼し、日本語版にも反映しています。
maildata.jp/blog/blog-2025-1…
