ITシステムの非機能要件（性能・信頼性・セキュリティ）の専門企業。大手を中心に350社以上を支援。全国7都市と世界各地から現地の回線で合成監視し、障害や遅延を実ユーザー視点で検知。Web高速化、DMARC、ゼロトラスト接続、OSINT調査を踏まえたステルス型セキュリティまで提供します。
東京都千代田区
Joined March 2015
- Tweets2.6K
- Following31
- Followers476
- Likes509
株式会社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…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
メール認証における配信トラブルの一因として、SPFレコードの構文ミスは見落とされがちです。
SPFレコードは、必須のバージョンタグ(v=spf1)に加え、送信元を定義するメカニズム(ip4・mx・include等、標準8種類)、判定結果を指定する修飾子(+ - ~ ?)、そして動作を補足するモディファイア(redirect・exp)の4要素で構成されます。受信サーバはメカニズムを左から順に評価するため、記述順序も認証結果に影響します。
特に実務上つまずきやすいのが、DNSルックアップ回数の上限（10回）超過と、1ドメインに複数のSPFレコードを設定してしまうケースです。いずれも構文自体に誤りがなくても認証失敗につながり、なりすまし対策としての機能を損ないます。
外部メール配信サービスの追加・変更を行うたびにSPFレコードを見直し、公開前・変更後には検証ツールで動作確認を行うことが、到達率となりすまし対策の両立につながります。DNS設定を担当される方は、既存のSPFレコードを一度棚卸しされることをお勧めします。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
メールサーバは、企業にとって機密情報や取引先との重要な通信が集中する経路であり、サイバー攻撃者にとって格好の標的です。攻撃の多くは、高度な手法ではなく、脆弱なパスワードや未更新のソフトウェア、基本的な設定不備から始まります。
防御の基盤となるのが、強力なパスワードポリシーと多要素認証による不正アクセス対策、SPF・DKIM・DMARCによる送信者認証、TLSやMTA-STSによる通信の暗号化です。これらに加え、Secure Email Gateway・IDS/IPS・DNSBL/SURBL・DNSSECといった複数の防御層を組み合わせることで、単一対策の突破を前提とした多層防御が実現できます。
実務的な示唆として、技術的対策の導入だけでなく、ログの定期監視、定期的なバックアップと復元テスト、インシデント対応計画の策定、従業員へのフィッシング教育を継続的に運用することが、機密情報の保護と事業継続、取引先からの信頼維持に直結します。
自社のメールセキュリティ体制を一度棚卸しされる際の、確認項目としてご活用ください。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
メールマーケティングにおいて、配信率低下の原因を本文の内容だけに求めるケースは少なくありません。
しかし、Gmail・Yahoo・Outlookなどの主要メールプロバイダは、SPF/DKIM/DMARCによる送信者認証に加え、送信量の変動やキャンペーン配信時間の一貫性、バウンス率・苦情率といった送信者の挙動そのものを継続的に評価しています。実際、短時間での大量送信や、ウォームアップ期間を設けない急激な送信量の増加、不規則な送信スケジュールは、侵害されたアカウントや自動化されたスパム配信の兆候として検出対象になります。Googleの送信者ガイドラインでは、スパム苦情率0.3%未満の維持が求められており、これを超えると配信制限の対象となり得ます。
実務的な示唆として、新規ドメインでは少量から開始し週20〜30%程度ずつ段階的に送信量を増やすこと、キャンペーン期間中は送信タイミングを一定に保つこと、ハードバウンスの即時除外やソフトバウンス3回連続での対象除外といったリスト管理を継続することが、長期的な送信者レピュテーション維持につながります。
自社ドメインとお取引先向けのメール配信を行う企業にとって、配信率低下は機会損失に直結するため、送信パターンの定期的な見直しは実務上有効な打ち手といえます。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
DMARCをp=rejectへ移行する際、多くの組織が「合格率が高いから移行して良い」と判断してしまいます。
しかし合格率の分母にはなりすましメールも含まれるため、正規送信の整備状況を正しく反映しません。低頻度の送信元も合格率にはほとんど現れず、業務上重要なメールが見落とされるリスクが残ります。
RFC 9989 §8は、DMARCに完全参加するための要件として、p=rejectドメインがSPF単独でのDMARC合格に依存することをMUST NOTと規定し、SPF・DKIM双方のアライメントを求めています。同時に§5.4・§8では、受信側もp=rejectの公開だけを根拠にメッセージを拒否してはならない（MUST NOT）と定めており、片方向の対応では不十分です。
移行判断は合格率ではなく、送信元一覧の全項目に決着がついているかという網羅性で行うべきです。DMARC移行を検討する情シス・セキュリティ担当者にとって、実務上の判断軸になる内容です。
maildata.jp/tips/dmarc_p_rej…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
SPF/DKIM/DMARCのレコードを更新した直後、「反映されない」と感じたことはありませんか。
DNSの変更内容は世界中のDNSサーバへ順次反映される仕組み(DNS伝播)になっており、通常24〜48時間、場合によっては最大72時間程度かかります。反映速度は、レコードのTTL設定やISPのキャッシュ状況によって左右されます。
事前にTTLを短く設定しておくと反映が早まり、変更完了後に元の値へ戻すのが一般的な進め方です。伝播が完了していない間は、正当なメールでも認証に失敗する場合があるため、DMARCレコードなどの変更は余裕を持ったスケジュールで行うことをおすすめします。
maildata.jp/blog/blog-2025-1…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
SPF認証が失敗した際、原因を「Fail」の一言で片付けてしまうと、実は見誤ることがあります。
SPFの判定結果にはPass、Fail、Softfail、Neutralのほか、DNS側の一時的な障害による「Temperror」、SPFレコード自体に問題がある「Permerror」があります。中でもPermerrorは、DNSルックアップ回数の10回超過、同一ドメインへの複数SPFレコードの存在、構文誤りなどが主な原因です。
正しい修正には、まず結果の種類を見極めることが第一歩になります。DMARCレポートを継続的に確認することで、こうした認証失敗の傾向を把握しやすくなります。
maildata.jp/blog/blog-2025-0…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
恋愛感情や親近感を装って金銭や機密情報を狙う「ハニートラップ詐欺」は、出会い系サイトやSNSのDMだけでなく、メールを接触経路として使われることもあります。
不自然なほど褒めてくる、関係を秘密にするよう求める、急速に親密になろうとする、金銭や便宜を求めてくる――こうした兆候は、個人向けの警戒ポイントとしてだけでなく、企業を狙う標的型の接触にも共通します。
DMARC自体はハニートラップ詐欺そのものを防ぐものではありませんが、なりすましメールアドレスを使った接触経路を遮断する対策として機能します。個人の警戒心に加え、組織としてのメール認証対策も、あわせて備えておく価値があります。
maildata.jp/blog/blog-2025-0…
株式会社Spelldata | デジタルサービスの性能、信頼性、セキュリティの専門企業 retweeted
SPF・DKIM・DMARCの設定でよく登場する「TXTレコード」。
実はSPFには、かつて専用のレコードタイプが存在していました。
しかし2014年にSPF専用レコードタイプは非推奨となり、現在はTXTレコードとして公開する方式が標準になっています。
TXTレコードはテキスト情報を保存するための汎用的なDNSレコードで、1つのドメインにSPF用・DKIM用・DMARC用・サービス検証用など、複数のTXTレコードを同時に設定することも一般的です。
なお、255文字を超える値を設定する場合は、複数の文字列に分割してダブルクォーテーションで囲む必要があるなど、書式にも注意点があります。
設定変更後は、TTLに依存し反映(DNS伝播)に数分〜48時間ほどかかる場合があります。
maildata.jp/blog/blog-2025-0…
