メールスタートアップの墓場：多くのメール企業が失敗する理由

多くのメールスタートアップが認識された問題の解決に数百万ドルを投資している一方で、私たちは 前方のメール 2017 年以降、信頼性の高い電子メール インフラストラクチャをゼロから構築することに注力してきました。この分析では、電子メール スタートアップの成果の背後にあるパターンと、電子メール インフラストラクチャの基本的な課題を探ります。

[!NOTE] 重要な洞察メールサービスのスタートアップ企業の多くは、メールインフラをゼロから構築していません。Amazon SESのような既存のソリューションやPostfixのようなオープンソースシステムをベースに構築している企業も多く、コアプロトコルは問題なく動作していますが、課題は実装にあります。

[!TIP] 技術的な詳細: 当社のアプローチ、アーキテクチャ、セキュリティ実装に関する包括的な詳細については、 メール転送に関するテクニカルホワイトペーパー と 概要ページ 2017 年以降の当社の開発タイムライン全体を文書化しています。

メール起動失敗マトリックス

[!CAUTION] 故障率アラート: テックスターズだけでも28社のメール関連企業がある 出口はわずか 5 つで、失敗率は非常に高くなります (80% 以上と計算されることもあります)。

以下は、私たちが見つけることができたすべての主要な電子メールスタートアップの失敗例です。アクセラレーター、資金調達、結果ごとにまとめられています。

インフラの現実チェック

[!WARNING] 隠された真実: あらゆる「メールスタートアップ」は、既存のインフラ上にUIを構築しているだけです。彼らは実際のメールサーバーを構築しているのではなく、実際のメールインフラに接続するアプリを開発しているのです。

メールを実際に実行するもの

graph TD
    A[Email Infrastructure] --> B[Amazon SES]
    A --> C[Postfix SMTP]
    A --> D[Cyrus IMAP]
    A --> E[SpamAssassin]
    A --> F[DKIM/SPF/DMARC]
B --> G[Powers most email APIs]
C --> H[Actual SMTP server everywhere]
D --> I[Handles email storage]
E --> J[Filters spam]
F --> K[Authentication that works]


「メールスタートアップ」が実際に構築するもの
graph LR
    A[Email Startup Stack] --> B[React Native Apps]
    A --> C[Web Interfaces]
    A --> D[AI Features]
    A --> E[Security Layers]
    A --> F[API Wrappers]
B --> G[Memory leaks]
C --> H[Break email threading]
D --> I[Gmail already has]
E --> J[Break existing workflows]
F --> K[Amazon SES with 10x markup]



[!TIP]
メール成功の鍵となるパターン: 電子メールで実際に成功している企業は、車輪の再発明を試みません。その代わりに、 強化するインフラストラクチャとツール 既存の電子メールワークフロー。 センドグリッド, メールガン、 と 消印 信頼性の高いSMTP APIと配信サービスを提供することで、数十億ドル規模の企業になりました。 と メールプロトコルに反対するのではなく、それに従う。これはForward Emailでも同じアプローチを取っています。

多くのメールスタートアップが失敗する理由

[!IMPORTANT]
基本パターン: メール クライアント スタートアップは、通常、機能しているプロトコルを置き換えようとするため失敗しますが、電子メールは インフラストラクチャー 企業は既存のワークフローを強化することで成功を収めることができます。重要なのは、ユーザーが実際に何を求めているのか、そして起業家が何を求めていると考えているのかを理解することです。

1. メールプロトコルは機能するが、実装がうまくいかないことが多い

[!NOTE]
メール統計: 毎日送信されるメールの数は3,473億通 大きな問題もなく、 世界中で43億7千万人のメールユーザー 2023年現在。

コアとなる電子メール プロトコルは堅牢ですが、実装の品質は大きく異なります。

ユニバーサルな互換性: すべてのデバイス、すべてのプラットフォームがサポート SMTP, IMAP、 と POP3
分散型: 単一障害点なし 世界中の数十億のメールサーバー
標準化されたSMTP、IMAP、POP3は1980年代から1990年代にかけて実戦でテストされたプロトコルです。
信頼性のある: 毎日送信されるメールの数は3,473億通 大きな問題もなく

本当のチャンス: プロトコルの置き換えではなく、既存のプロトコルのより優れた実装。
2. ネットワーク効果は破壊不可能
電子メールのネットワーク効果は絶対的です。

誰もがメールを持っている: 世界中で43億7千万人のメールユーザー 2023年現在
クロスプラットフォーム: すべてのプロバイダー間でシームレスに動作します
ビジネスクリティカル: 企業の99%が毎日メールを使用しています 運用用
切り替えコスト: メールアドレスを変更すると、それに関連するすべてのものが壊れます

3. 間違った問題に焦点を合わせてしまうことが多い
多くの電子メールスタートアップは、実際の問題点ではなく、認識されている問題に焦点を当てています。

「メールは複雑すぎる」基本的なワークフローはシンプルです - 1971年以来、送信、受信、整理
「メールにはAIが必要」: Gmailにはすでに効果的なスマート機能が搭載されている スマート返信や優先受信トレイなど
「電子メールのセキュリティ強化が必要」: DKIM, SPF、 と DMARC 確実な認証を提供する
「メールには新しいインターフェースが必要」: 見通し と Gメール インターフェースは数十年にわたるユーザー調査を通じて改良されている

解決する価値のある真の問題: インフラストラクチャの信頼性、配信性、スパム フィルタリング、開発者ツール。
4. 技術的負債は膨大である
実際の電子メール インフラストラクチャを構築するには、次のものが必要です。

SMTPサーバー: 複雑な配送と 評判管理
スパムフィルタリング: 常に進化 脅威の状況
ストレージシステム： 信頼性のある IMAP/POP3 実装
認証: DKIM, SPF, DMARC, ARC コンプライアンス
配信性: ISP関係と 評判管理

5. インフラはすでに存在している
以下を使用できる場合、なぜ再発明する必要があるのでしょうか。

アマゾンSES: 実績のある配信インフラストラクチャ
ポストフィックス: 実戦テスト済みのSMTPサーバー
鳩小屋: 信頼性の高いIMAP/POP3サーバー
スパムアサシン: 効果的なスパムフィルタリング
既存のプロバイダー: Gメール, 見通し, ファストメール 問題なく動作する

ケーススタディ：メールスタートアップが失敗する時
ケーススタディ：スキフ事故
Skiff は、電子メール スタートアップのあらゆる問題点を完璧に例示しています。
セットアップ

ポジショニング: 「プライバシー重視のメールと生産性向上プラットフォーム」
資金調達: 重要なベンチャーキャピタル
約束: プライバシーと暗号化によるメールの改善

買収
ノーションは2024年2月にスキフを買収した。 統合と継続的な開発に関する典型的な買収の約束を伴います。
現実

即時シャットダウン: スキフは数ヶ月以内に閉鎖された
創業者の流出: Skiffの創設者はNotionを離れ、Cursorに加わった
ユーザーの放棄: 数千人のユーザーが移行を余儀なくされる

アクセラレータ分析
Yコンビネータ：メールアプリファクトリー
Yコンビネーター 数十社のメール関連スタートアップに資金を提供してきました。そのパターンは以下のとおりです。

メール （2014年）：モバイルメールクライアント→「ウェルネス」に方向転換
メールタイム （2016年）：チャット形式のメール→分析に転換
再メール （2009年）：iPhoneのメール検索→ Googleに買収された → シャットダウン
友好的な (2012): Gmail ソーシャル プロフィール → LinkedInに買収された → シャットダウン

成功率結果はまちまちでしたが、注目すべきエグジットもありました。いくつかの企業は買収に成功しました（reMailはGoogle、RapportiveはLinkedIn）。一方で、メール事業からの転換や、人材獲得のために買収された企業もありました。
Techstars: メールの墓場
テックスターズ さらに悪い実績がある。

メールコパイロット （2012年）：買収→閉鎖
返信送信 （2012年）：完全に失敗
作成 （2012年）：「簡単。安全。メール」→失敗
ジャンブル （2015年）：電子メールの暗号化 → 失敗
受信箱フィーバー （2011年）：メールAPI → 失敗

パターン: 漠然とした価値提案、真の技術革新なし、すぐに失敗。
ベンチャーキャピタルの罠

[!CAUTION]
VC資金調達のパラドックスVCはメールを使ったスタートアップを好みます。なぜなら、シンプルに聞こえるのに実際には不可能だからです。投資を引き付ける根本的な前提こそが、失敗を保証するものなのです。

VC が電子メール スタートアップを好むのは、単純に聞こえるが実際には不可能だからです。
graph TD
    A[VC Email Startup Pitch] --> B[Sounds Simple]
    A --> C[Seems Obvious]
    A --> D[Technical Moat Claims]
    A --> E[Network Effect Dreams]
B --> F[Everyone uses email!]
C --> G[Email is old and broken!]
D --> H[We'll build better infrastructure!]
E --> I[Once we get users, we'll dominate!]

F --> J[Reality: Email works fine]
G --> K[Reality: Protocols are proven]
H --> L[Reality: Infrastructure is hard]
I --> M[Reality: Network effects unbreakable]


現実: これらの仮定は電子メールには当てはまりません。
技術的な現実：現代のメールスタック
「メールスタートアップ」の本当の原動力
これらの企業が実際に何を運営しているかを見てみましょう。
graph LR
    A[Most Email Startups] --> B[React Native App]
    B --> C[Node.js API]
    C --> D[Amazon SES]
    D --> E[Existing Email Infrastructure]
F[Forward Email] --> G[100% Custom Node.js JavaScript Stack]
G --> H[Built From Scratch]


パフォーマンスの問題
メモリ膨張: ほとんどのメール アプリは、大量の RAM を消費する Electron ベースの Web アプリです。

メールスプリング: 基本メールで500MB以上
ニラス・メール: 1GB以上のメモリ使用量 シャットダウン前
郵便ポスト: 300MB以上のアイドルメモリ
カナリアメール: メモリの問題による頻繁なクラッシュ
サンダーバード: RAM使用率が最大90%まで上昇 システムメモリ


[!WARNING]
電子性能危機ElectronやReact Nativeで構築された最新のメールクライアントは、深刻なメモリ肥大化とパフォーマンスの問題を抱えています。これらのクロスプラットフォームフレームワークは開発者にとって便利である一方で、基本的なメール機能を実行するだけで数百MBから数GBのRAMを消費する、リソースを大量に消費するアプリケーションを生み出します。

バッテリーの消耗: 継続的な同期と非効率的なコード:

決して休まないバックグラウンドプロセス
数秒ごとに不要なAPI呼び出し
接続管理が不十分
コア機能に絶対に必要なものを除き、サードパーティの依存関係はありません

買収パターン：成功 vs. 撤退
2つのパターン
クライアント アプリ パターン (通常は失敗):
flowchart TD
    A[Email Client Launch] --> B[VC Funding]
    B --> C[User Growth]
    C --> D[Talent Acquisition]
    D --> E[Service Shutdown]
A -.-> A1["Revolutionary interface"]
B -.-> B1["$5-50M raised"]
C -.-> C1["Acquire users, burn cash"]
D -.-> D1["Acqui-hire for talent"]
E -.-> E1["Service discontinued"]


インフラストラクチャパターン（多くの場合成功）:
flowchart TD
    F[Infrastructure Launch] --> G[Revenue Growth]
    G --> H[Market Position]
    H --> I[Strategic Acquisition]
    I --> J[Continued Operation]
F -.-> F1["SMTP/API services"]
G -.-> G1["Profitable operations"]
H -.-> H1["Market leadership"]
I -.-> I1["Strategic integration"]
J -.-> J1["Enhanced service"]


最近の例
クライアントアプリの障害:

メールボックス → Dropbox → シャットダウン (2013-2015)
スパロウ → Google → シャットダウン (2012-2013)
reMail → Google → シャットダウン (2010-2011)
スキフ → ノーション → シャットダウン (2024)

注目すべき例外:

スーパーヒューマン → グラマーリー （2025年）：生産性プラットフォームへの戦略的統合による買収成功

インフラの成功:

SendGrid → Twilio （2019年）：30億ドルの買収、継続的な成長
メールガン → シンク （2021年）：戦略的統合
ポストマーク → ActiveCampaign （2022年）：強化されたプラットフォーム

業界の進化と統合
自然な産業の進歩
メール業界は必然的に統合へと進んできました。大企業が中小企業を買収し、機能を統合したり競争相手を排除したりしてきました。これは必ずしも悪いことではありません。成熟した業界のほとんどがそうやって発展していくのです。
買収後の移行
メール会社が買収されると、ユーザーは次のような問題に直面することがよくあります。

サービス移行: 新しいプラットフォームへの移行
機能の変更: 特殊な機能の喪失
価格調整: さまざまなサブスクリプションモデル
統合期間: 一時的なサービス中断

遷移中のユーザーの考慮事項
業界統合の過程で、ユーザーは次のようなメリットを得られます。

代替案の評価: 複数のプロバイダーが同様のサービスを提供している
移行パスを理解する: ほとんどのサービスはエクスポートツールを提供しています
長期的な安定性を考慮する: 確立されたプロバイダーは、より継続性を提供することが多い

ハッカーニュースのリアリティチェック
どのメールスタートアップも同じコメントをもらっている ハッカーニュース:

「電子メールは問題なく機能し、これにより問題は解決されました」
「他の人と同じように Gmail/Outlook を使用してください」
「2年後に廃止されるメールクライアント」
「本当の問題はスパムであり、これでは解決しない」

コミュニティは正しいこうしたコメントは、電子メール スタートアップの立ち上げごとに表示されます。根本的な問題は常に同じだからです。
現代のAIメール詐欺
最新の波
2024 年には「AI 搭載メール」スタートアップの新たな波が到来し、最初の大規模なエグジットがすでに起こっています。

超人: 3,300万ドルを調達, Grammarlyによる買収に成功 （2025） - 稀に見るクライアントアプリの成功例
短波: AIによる要約機能を備えたGmailラッパー
セインボックス: AI メール フィルタリング (実際には機能しますが、革命的ではありません)

いつもと同じ問題
「AI」を追加しても根本的な課題は解決されません。

AI概要: ほとんどのメールはすでに簡潔です
スマートな返信: Gmailには何年も前からこれがある そしてそれらはうまく機能します
メールスケジュール: Outlookはこれをネイティブに実行します
優先検出既存のメールクライアントには効果的なフィルタリングシステムがある

本当の挑戦AI 機能には、比較的軽微な問題点に対処しながらも、多大なインフラストラクチャ投資が必要です。
実際に効果のあったメール活用術：成功事例
インフラ企業（勝者）

センドグリッド: Twilioによる30億ドルの買収
メールガン: 5000万ドル以上の収益、Sinchに買収
消印: 収益性が高い、 ActiveCampaignに買収された
アマゾンSES: 数十億ドルの収益

パターン彼らはアプリではなくインフラストラクチャを構築します。
メールプロバイダー（生存者）

ファストメール: 25年以上、収益性、独立性
プロトンメールプライバシー重視の持続可能な成長
Zohoメール: より広いビジネススイートの一部
私たちは: 7年以上、収益性あり、成長中


[!WARNING]
JMAP投資問題: ファストメールはリソースを投資しているが JMAP、プロトコルは 10歳以上、限定的な採用、彼らは同時に PGP暗号化の実装を拒否する 多くのユーザーが求めている機能です。これは、ユーザーからの要望よりもプロトコルの革新を優先するという戦略的な選択です。JMAPがより広く普及するかどうかはまだ分かりませんが、現在のメールクライアントのエコシステムは依然として主にIMAP/SMTPに依存しています。


[!TIP]
企業の成功: メール転送権限 一流大学向けの卒業生向けメールソリューションケンブリッジ大学を含む30,000人の卒業生の住所を保有する企業に導入され、従来のソリューションと比較して年間87,000ドルのコスト削減を実現しました。

パターン: これらは電子メールを強化するものであり、電子メールに代わるものではありません。
例外：Xobniの成功物語
ホブニー 適切なアプローチを取ることで実際に成功した数少ない電子メール関連のスタートアップ企業のひとつとして際立っています。
Xobniがうまくやったこと:

既存の電子メールの強化Outlookを置き換えるのではなく、Outlookの上に構築されています
実際の問題を解決: 連絡先管理とメール検索
統合に重点を置く: 既存のワークフローを操作した
エンタープライズフォーカス: 実際に問題を抱えているビジネスユーザーをターゲットに

成功: Xobniは2013年にYahooに6000万ドルで買収された。投資家には確実な利益を、創業者には成功裏の出口を提供します。
他社が失敗したところでXobniが成功した理由

実績のあるインフラストラクチャ上に構築: Outlookの既存の電子メール処理を使用
実際の問題を解決: 連絡先管理は本当に壊れていた
エンタープライズ市場: 企業は生産性向上ツールにお金をかける
統合アプローチ: 既存のワークフローを置き換えるのではなく、強化する

創業者の継続的な成功
マット・ブレジナ と アダム・スミス Xobniの後も止まらなかった:

マット・ブレジナ：活動的になった エンジェル投資家 Dropbox、Mailboxなどへの投資
アダム・スミス生産性分野で成功する企業の構築を継続
両創設者: メールの成功は置き換えではなく強化によってもたらされることを実証

パターン
企業が電子メールで成功するのは次のような場合です。

インフラを構築する (センドグリッド, メールガン)
既存のワークフローを強化する (ホブニー, ファストメール)
信頼性に焦点を当てる (アマゾンSES, 消印)
開発者にサービスを提供する （APIとツールであり、エンドユーザーアプリではありません）

電子メールの再発明に成功した人はいますか?
これは、Eメールイノベーションの核心に迫る重要な質問です。簡潔に答えると、次のようになります。 電子メールの置き換えに成功した人はいないが、電子メールを強化することに成功した人もいる.
実際に残ったもの
過去 20 年間の電子メールの革新を振り返ると、

Gmailのスレッド: 強化されたメール整理
Outlookのカレンダー統合: 強化されたスケジュール
モバイルメールアプリ: アクセシビリティの強化
DKIM/SPF/DMARC: セキュリティ強化

パターン: すべての成功したイノベーション 強化された 既存の電子メール プロトコルを置き換えるのではなく、既存の電子メール プロトコルを維持します。
新しいツールは電子メールを補完する（ただし電子メールに取って代わるものではない）

スラック: チームチャットに最適ですが、メール通知も送信されます
不和: コミュニティには最適ですが、アカウント管理にはメールを使用します
ワッツアップメッセージングには最適ですが、ビジネスでは依然としてメールが使用されています
ズーム: ビデオ通話には必須ですが、会議の招待はメールで届きます

HEY実験

[!IMPORTANT]
実世界検証HEYの創設者 DHH 実際にForward Emailのサービスを個人ドメインで利用しています dhh.dk そして、それは数年にわたって続いており、電子メールのイノベーターたちでさえも、実績のあるインフラストラクチャに依存していることを示しています。

HEY による ベースキャンプ これは、電子メールを「再発明」しようとする最近の最も真剣な試みを表しています。

発売: 盛大なファンファーレで迎えた2020年
アプローチ: スクリーニング、バンドル、ワークフローを備えたまったく新しい電子メールパラダイム
受付: 賛否両論 - 気に入っている人もいるが、大半は既存のメールを使い続けている
現実: インターフェースが異なるメール（SMTP/IMAP）です

実際に効果があるもの
最も成功した電子メールのイノベーションは次のとおりです。

より良いインフラ: より高速なサーバー、より優れたスパムフィルタリング、配信性の向上
強化されたインターフェース: Gmailの会話ビュー, Outlookのカレンダー統合
開発者ツール: メール送信用のAPI、追跡用のWebhook
特殊なワークフロー: CRM統合、マーケティングオートメーション、トランザクションメール

これらは電子メールに代わるものではなく、電子メールをより良くするものでした。
既存の電子メールプロトコル向けの最新インフラストラクチャの構築：私たちのアプローチ
失敗例を掘り下げる前に、メールにおいて実際に何が機能しているのかを理解することが重要です。問題はメールが壊れていることではなく、多くの企業が既に完璧に機能しているものを「修正」しようとしていることです。
メールイノベーションスペクトラム
電子メールのイノベーションは、次の 3 つのカテゴリに分類されます。
graph TD
    A[Email Innovation Spectrum] --> B[Infrastructure Enhancement]
    A --> C[Workflow Integration]
    A --> D[Protocol Replacement]
B --> E[What works: Better servers, delivery systems, developer tools]
C --> F[Sometimes works: Adding email to existing business processes]
D --> G[Always fails: Trying to replace SMTP, IMAP, or POP3]


インフラに重点を置く理由
当社が最新の電子メール インフラストラクチャの構築を選択したのは、次の理由からです。

電子メールプロトコルは実証済み: SMTPは1982年から安定して動作している
問題は実装だ: ほとんどのメールサービスは時代遅れのソフトウェアスタックを使用している
ユーザーは信頼性を求めている: 既存のワークフローを壊すような新機能ではない
開発者にはツールが必要: より優れたAPIと管理インターフェース

メールで実際に機能するもの
成功パターンはシンプルです。 既存の電子メールワークフローを置き換えるのではなく強化する。 これはつまり：

より高速で信頼性の高いSMTPサーバーの構築
正規のメールを壊さずに、より優れたスパムフィルタリングを実現する
既存のプロトコルに開発者フレンドリーなAPIを提供する
適切なインフラストラクチャによる配信性の向上

私たちのアプローチ：私たちが他と違う理由
私たちの活動

実際のインフラを構築する: ゼロからカスタム SMTP/IMAP サーバーを構築する
信頼性に焦点を当てる: 99.99%の稼働率適切なエラー処理
既存のワークフローを強化する: すべてのメールクライアントで動作します
開発者にサービスを提供する: 実際に機能するAPIとツール
互換性を維持する： 満杯 SMTP/IMAP/POP3 コンプライアンス

私たちが行わないこと

「革命的な」メールクライアントを構築する
既存の電子メールプロトコルを置き換えてみる
不要なAI機能を追加する
メールを「修正する」ことを約束する

実際に機能するメールインフラの構築方法
私たちの反スタートアップアプローチ
他の企業が電子メールの改革に何百万ドルも費やしている間、当社は信頼性の高いインフラストラクチャの構築に重点を置いています。

ピボットなし: 私たちは7年以上にわたりメールインフラを構築してきました
買収戦略なし: 私たちは長期的な視点で構築しています
「革命的」な主張はなし: メールをより良く機能させる

私たちの違い

[!TIP]
政府レベルのコンプライアンス: メール転送は セクション889に準拠 また、米国海軍兵学校などの組織にもサービスを提供しており、厳格な連邦政府のセキュリティ要件を満たすという当社の取り組みを実証しています。


[!NOTE]
OpenPGPとOpenWKDの実装: Fastmailとは異なり、 PGPの実装を拒否 複雑さに関する懸念を理由に、Forward Email は OpenWKD (Web Key Directory) 準拠の完全な OpenPGP サポートを提供し、JMAP などの実験的なプロトコルの使用を強制することなく、ユーザーが実際に必要とする暗号化を提供します。

技術スタックの比較:
graph TD
    A[Proton Mail Stack] --> B[Postfix SMTP Server]
    A --> C[Custom Encryption Layer]
    A --> D[Web Interface]
E[Forward Email Stack] --> F[100% Custom Node.js]
E --> G[JavaScript Throughout]
E --> H[Built From Scratch]

B --> I[1980s C code]
C --> J[Glue code required]
D --> K[Integration complexity]

F --> L[Modern language]
G --> M[No glue code needed]
H --> N[Web-native design]



= APNICブログ投稿 Protonがpostfix-mta-sts-resolverを使用していることを確認し、Postfixスタックを実行していることを示しています。

主な違い:

現代語: スタック全体にわたるJavaScriptと1980年代のCコードの比較
グルーコードなし: 単一言語により統合の複雑さが解消されます
ウェブネイティブ: 現代のウェブ開発のためにゼロから構築
メンテナンス可能: ウェブ開発者なら誰でも理解し貢献できる
レガシー債務なし: 数十年にわたるパッチのない、クリーンでモダンなコードベース


[!NOTE]
プライバシーバイデザイン： 私たちの 個人情報保護方針 転送されたメールをディスク ストレージやデータベースに保存せず、メールに関するメタデータを保存せず、ログや IP アドレスを保存しないことを保証します。メール転送サービスの場合のみメモリ内で動作します。

技術文書: 当社のアプローチ、アーキテクチャ、セキュリティ実装に関する包括的な詳細については、 技術ホワイトペーパー および広範な技術ドキュメント。
メールサービスプロバイダの比較：実績のあるプロトコルによる成長

[!NOTE]
実質成長率他のプロバイダーが実験的なプロトコルを追いかける一方で、Forward Emailはユーザーが本当に求めているもの、つまりあらゆるデバイスで動作する信頼性の高いIMAP、POP3、SMTP、CalDAV、CardDAVに重点を置いています。私たちの成長は、このアプローチの価値を証明しています。

プロバイダー
ドメイン名（2024年経由 セキュリティトレイル)
ドメイン名（2025年経由 ビューDNS)
変化率
MXレコード
前方のメール
418,477
506,653
+21.1%
mx1.forwardemail.net
プロトンメール
253,977
334,909
+31.9%
mail.protonmail.ch
ファストメール
168,433
192,075
+14%
in1-smtp.messagingengine.com
メールボックス
38,659
43,337
+12.1%
mxext1.mailbox.org
合計
18,781
21,720
+15.6%
mail.tutanota.de
スキフ（廃止）
7,504
3,361
-55.2%
inbound-smtp.skiff.com
重要な洞察:

前方のメール MXレコードを使用しているドメインが50万件を超え、堅調な成長（+21.1%）を示しています
実績のあるインフラが勝利: 信頼性の高いIMAP/SMTPを備えたサービスは、一貫したドメイン採用を示しています
JMAPの無関係性: ファストメールのJMAP投資は、標準プロトコルに重点を置くプロバイダーと比較して、成長が鈍化している（+14%）
スキフの崩壊: 倒産したスタートアップはドメインの55.2%を失い、「革命的な」電子メールアプローチの失敗を証明した。
市場検証: ドメイン数の増加はマーケティング指標ではなく、実際のユーザー採用を反映しています

技術的なタイムライン
私たちの 公式の会社タイムライン実際に機能する電子メール インフラストラクチャの構築方法は次のとおりです。
timeline
    title Forward Email Development Timeline
    2017 : October 2nd - Domain purchased : November 5th - 634-line JavaScript file created : November - Official launch with DNS-based forwarding
    2018 : April - Switched to Cloudflare DNS for privacy : October - Gmail and Outlook "Send Mail As" integration
    2019 : May - v2 release with performance improvements using Node.js streams
    2020 : February - Enhanced Privacy Protection plan : April - Spam Scanner alpha release and 2FA : May - Custom port forwarding and RESTful API : August - ARC email authentication support : November 23rd - Public launch out of beta
    2021 : February - 100% JavaScript/Node.js stack (removed Python) : September 27th - Regular expression alias support
    2023 : January - Redesigned website : February - Error logs and dark mode : March - Tangerine integration and DNS over HTTPS : April - New infrastructure with bare metal servers : May - Outbound SMTP feature launch : November - Encrypted mailbox storage with IMAP support : December - POP3, passkeys, WebAuthn, and OpenPGP support
    2024 : February - CalDAV support : March-July - IMAP/POP3/CalDAV optimizations : July - iOS Push support and TTI monitoring : August - EML/Mbox export and webhook signatures : September-January 2025 - Vacation responder and OpenPGP/WKD encryption

他社が失敗する中で当社が成功する理由

私たちはアプリではなくインフラを構築します: サーバーとプロトコルに焦点を当てる
置き換えるのではなく、強化します: 既存のメールクライアントと連携
私たちは利益を上げています: 「早く成長して物事を壊せ」というVCからのプレッシャーはない
メールを理解しています: 7年以上の深い技術的経験
開発者にサービスを提供: 実際に問題を解決するAPIとツール

コストの現実チェック
graph TD
    A[Typical Email Startup] --> B[$500K-2M per month burn]
    A --> C[20-50 employees]
    A --> D[Expensive office space]
    A --> E[Marketing costs]
F[Forward Email] --> G[Profitable from day one]
F --> H[Small focused team]
F --> I[Remote-first, low overhead]
F --> J[Organic growth]


電子メールインフラストラクチャにおけるセキュリティの課題

[!IMPORTANT]
耐量子メールセキュリティ: メール転送は 量子耐性と個別に暗号化されたSQLiteメールボックスを使用する世界初で唯一のメールサービス将来の量子コンピューティングの脅威に対して前例のないセキュリティを提供します。

メールセキュリティは、業界のすべてのプロバイダーに影響を及ぼす複雑な課題です。個々のインシデントに焦点を当てるよりも、すべてのメールインフラプロバイダーが対処しなければならない共通のセキュリティ上の考慮事項を理解することの方が重要です。
一般的なセキュリティ上の考慮事項
すべてのメールプロバイダーは同様のセキュリティ上の課題に直面しています。

データ保護: ユーザーデータと通信のセキュリティ保護
アクセス制御: 認証と承認の管理
インフラストラクチャセキュリティ: サーバーとデータベースの保護
コンプライアンス: さまざまな規制要件を満たす GDPR と CCPA


[!NOTE]
高度な暗号化： 私たちの セキュリティ対策 メールボックスの ChaCha20-Poly1305 暗号化、LUKS v2 によるフルディスク暗号化、保存時の暗号化、メモリ内の暗号化、転送中の暗号化による包括的な保護が含まれます。

透明性の価値
セキュリティインシデントが発生した場合、最も効果的な対応は透明性と迅速な対応です。以下の点に留意した企業

事件を速やかに開示する: ユーザーが情報に基づいた意思決定を行えるように支援する
詳細なタイムラインを提供する: 問題の範囲を理解していることを示す
修正を迅速に実施する: 技術的能力を証明する
学んだ教訓を共有する: 業界全体のセキュリティ向上に貢献

これらの対応は、ベスト プラクティスを促進し、他のプロバイダーが高いセキュリティ標準を維持するよう促すことで、電子メール エコシステム全体にメリットをもたらします。
継続的なセキュリティ上の課題
電子メール業界は、セキュリティ対策を進化させ続けています。

暗号化規格: より優れた暗号化方式の実装 TLS 1.3
認証プロトコル: 改善中 DKIM, SPF、 と DMARC
脅威検出: より優れたスパムおよびフィッシングフィルターの開発
インフラの強化: サーバーとデータベースのセキュリティ保護
ドメインレピュテーション管理: 対処 Microsoftのonmicrosoft.comドメインからの前例のないスパム 必要とする 恣意的なブロックルール と 追加のMSPの議論

これらの課題を解決するには、この分野のすべてのプロバイダーからの継続的な投資と専門知識が必要です。
結論: アプリではなくインフラに重点を置く
証拠は明らかだ
数百の電子メールスタートアップを分析した結果:

80%以上の失敗率: ほとんどのメールスタートアップは完全に失敗します（この数字はおそらく80％をはるかに上回ります。私たちは良いほうです）
クライアントアプリは通常失敗する: 買収されるということは、メールクライアントにとっては通常死を意味する
インフラは成功するSMTP/APIサービスを構築する企業はしばしば成功する
VCの資金調達はプレッシャーを生み出すベンチャーキャピタルは非現実的な成長期待を生み出す
技術的負債が蓄積される: メールインフラの構築は見た目よりも難しい

歴史的背景
スタートアップ企業によると、電子メールは20年以上「死につつある」という。

2004：「ソーシャルネットワークが電子メールに取って代わる」
2008：「モバイルメッセージングは電子メールを殺すだろう」
2012: "スラック メールに代わる」
2016「AIは電子メールに革命を起こす」
2020：「リモートワークには新しいコミュニケーションツールが必要」
2024「AIがついに電子メール問題を解決する」

メールはまだここにありますまだ成長を続けています。依然として不可欠です。
本当の教訓
教訓は、メールは改善できないということではなく、適切なアプローチを選択することです。

電子メールプロトコルは機能する: SMTP, IMAP, POP3 実戦テスト済み
インフラは重要: 信頼性とパフォーマンスは派手な機能よりも重要です
強化は交換に勝る: メールと戦うのではなく、メールを活用しよう
持続可能性は成長に勝る: 収益性の高いビジネスはVCの資金提供を受けたビジネスよりも長く続く
開発者にサービスを提供するツールとAPIはエンドユーザーアプリよりも多くの価値を生み出します

機会: プロトコルの置き換えではなく、実証済みのプロトコルのより適切な実装。

[!TIP]
包括的なメールサービス分析: 2025 年の 79 のメール サービスの詳細な比較 (詳細なレビュー、スクリーンショット、技術分析を含む) については、当社の包括的なガイドをご覧ください。 79のベストメールサービスこの分析は、信頼性、セキュリティ、標準準拠の面で Forward Email が一貫して推奨される選択肢としてランク付けされている理由を示しています。


[!NOTE]
実世界検証: 私たちのアプローチは、 セクション889の遵守を要求する政府機関 に 数万の卒業生の住所を管理する主要大学信頼性の高いインフラストラクチャを構築することが電子メールの成功への道であることを証明しています。

メールスタートアップの立ち上げを考えているなら、メールインフラの構築を検討してみてはいかがでしょうか。世界に必要なのは、より多くのメールアプリではなく、より優れたメールサーバーなのです。
拡張メール墓場：さらなる障害とシャットダウン
Googleのメール実験は失敗に終わった
Googleは、 Gメール、複数の電子メール プロジェクトを中止しました。

Google Wave (2009-2012): 誰も理解できなかった「メールキラー」
Googleバズ (2010-2011): ソーシャルメール統合の失敗
Gmailの受信トレイ  (2014-2019): Gmailの「スマート」な後継、放棄
グーグル+ メール機能（2011-2019）：ソーシャルネットワークメール統合

パターン: Google でさえ、電子メールをうまく再発明することはできません。
連続失敗：ニュートン・メールの3人の死
ニュートンメール 死亡した 3回:

クラウドマジック (2013-2016): メールクライアントがニュートンに買収された
ニュートンメール (2016-2018): ブランド変更、サブスクリプションモデルは失敗
ニュートン・メール・リバイバル (2019-2020): 復帰を試みたが、再び失敗

レッスン: 電子メールクライアントはサブスクリプションモデルを維持できません。
リリースされなかったアプリ
多くの電子メールスタートアップは立ち上げ前に消滅した。

時間 （2014年）：カレンダーとメールの統合、リリース前にシャットダウン
メールストリーム （2011）：電子メール管理ツール、リリース前に取得
流暢 （2013年）：電子メールクライアント、開発中止

買収から閉鎖までのパターン

スパロウ → Google → シャットダウン (2012-2013)
reMail → Google → シャットダウン (2010-2011)
メールボックス → Dropbox → シャットダウン (2013-2015)
完了 → マイクロソフト → シャットダウン (Outlook Mobileになりました)
Acompli → Microsoft → 統合 （稀な成功）

電子メールインフラストラクチャの統合

ポストボックス → eMクライアント （2024年）：買収後すぐに郵便ポストを閉鎖
複数の買収: インプロブMX 複数回買収されており、 プライバシーに関する懸念が浮上 と 買収発表 と ビジネスリスト
サービスの低下多くのサービスは買収後に悪化する

オープンソースメールの墓場：「無料」が持続不可能なとき
Nylas Mail → Mailspring: できなかったフォーク

ニラス・メール: オープンソースの電子メールクライアント、 2017年廃止 そして持っていた 大量のメモリ使用量の問題
メールスプリング: コミュニティフォーク、メンテナンスに苦労し、 RAM使用量が多い問題
現実オープンソースのメールクライアントはネイティブアプリに勝てない

ユードラ：18年間の死の行進

1988-2006: Mac/Windows用の主要なメールクライアント
2006: クアルコムは開発を中止した
2007: 「Eudora OSE」としてオープンソース化
2010: プロジェクトは中止されました
レッスン: 成功した電子メールクライアントも最終的には消滅する

FairEmail：Google Playの政治によって殺された

フェアメール: プライバシー重視のAndroidメールクライアント
グーグルプレイ: 「ポリシー違反」のため禁止
現実プラットフォームポリシーによってメールアプリが即座に停止される可能性がある

メンテナンスの問題
オープンソースの電子メール プロジェクトが失敗する理由:

複雑: 電子メールプロトコルを正しく実装するのは複雑です
セキュリティ: 継続的なセキュリティアップデートが必要
互換性: すべてのメールプロバイダーで動作する必要がある
資源: ボランティア開発者の燃え尽き症候群

AIメールスタートアップの急増：「インテリジェンス」で歴史は繰り返される
現在のAIメールゴールドラッシュ
2024年のAIメールスタートアップ：

超人: 3,300万ドルを調達, Grammarlyに買収された (2025)
短波: Yコンビネーター、Gmail + AI
セインボックス: AIメールフィルタリング（実際に収益性あり）
ブーメラン: AIのスケジュールと応答
メール0/ゼロAI搭載のメールクライアントスタートアップが新たなメールインターフェースを構築
受信トレイゼロ: メール管理の自動化を目指すオープンソースのAIメールアシスタント

資金調達の熱狂
VC は「AI + メール」に資金を投じている。

1億ドル以上投資 2024年のAIメールスタートアップ
同じ約束：「革命的なメール体験」
同じ問題: 既存のインフラストラクチャ上に構築
同じ結果: ほとんどが3年以内に失敗する

なぜ彼らは皆失敗するのか（再び）

AIはメールの非問題を解決しない: メールは正常に動作します
GmailにはすでにAIが搭載されている: スマート返信、優先受信トレイ、スパムフィルタリング
プライバシーに関する懸念: AIはあなたのメールをすべて読む必要があります
コスト構造AI処理は高価、電子メールはコモディティ
ネットワーク効果Gmail/Outlookの優位性は崩れない

避けられない結果

2025: SuperhumanがGrammarlyに買収される - 電子メールクライアントとしては珍しい成功例
2025-2026: 残りのAIメールスタートアップのほとんどは方向転換するか閉鎖されるだろう
2027: 生存者は獲得されるが、結果はまちまちである
2028：「ブロックチェーンメール」か、次のトレンドが生まれるか

統合大惨事：「生き残り」が災害に変わるとき
大規模なメールサービス統合
電子メール業界は劇的に統合されました。

ActiveCampaignがPostmarkを買収 (2022)
シンチがメールガンを買収 (2021)
TwilioがSendGridを買収 (2019)
複数 インプロブMX 買収 （継続中） プライバシーに関する懸念 と 買収発表 と ビジネスリスト

展望：破壊を止められない「サバイバー」
マイクロソフトアウトルックは、「生存者」であるにもかかわらず、常に問題を抱えています。

メモリリーク: Outlookは数ギガバイトのRAMを消費します と 頻繁な再起動が必要
同期の問題: メールがランダムに消えたり現れたりする
パフォーマンスの問題: 起動が遅く、頻繁にクラッシュする
互換性の問題: サードパーティのメールプロバイダーとの決別

私たちの現実世界での経験: Outlook の設定により、弊社の完全準拠の IMAP 実装が壊れてしまうお客様を、弊社では定期的にサポートしています。
消印インフラ問題
後 ActiveCampaignの買収:

SSL証明書の失敗: 2024年9月に10時間近くの停電 SSL証明書の期限切れのため
ユーザーの拒否: マーク・コールブルッゲが拒否される 合法的な使用にもかかわらず
開発者の流出: @levelsio は「Amazon SES は私たちの最後の希望です」と述べています
MailGunの問題: スコットは報告した: 「@Mail_Gun のサービスは最悪です... 2 週間もメールを送信できませんでした」

最近のメールクライアントの犠牲者（2024～2025年）
ポストボックス → eMクライアント 取得: 2024年にeMクライアントはPostboxを買収し、 すぐにシャットダウンする何千人ものユーザーが移行を余儀なくされました。
カナリアメール 問題： にもかかわらず セコイアのバックアップユーザーからは、機能が動作しないことや顧客サポートが不十分であることが報告されています。
ReaddleのSpark: 電子メール クライアントのエクスペリエンスが悪いというユーザーからの報告が増えています。
メールバード ライセンスの問題: Windows ユーザーはライセンスの問題とサブスクリプションの混乱に直面しています。
航空便 衰退: 失敗したSparrowコードベースをベースにしたMac/iOSメールクライアントは、引き続き 悪いレビュー 信頼性の問題のため。
電子メールの拡張とサービスの獲得
HubSpotサイドキック → 販売終了: HubSpotのメールトラッキング拡張機能は 2016年に廃止 「HubSpot Sales」に置き換えられました。
Gmail向けEngage → 引退: SalesforceのGmail拡張機能は 2024年6月に引退ユーザーは他のソリューションに移行することを余儀なくされます。
生き残り：実際に機能するメール配信会社
すべてのメール会社が失敗するわけではありません。実際に成功している会社をご紹介します。
メールモード: Yコンビネーターの成功物語, セコイアの急騰による200万ドル インタラクティブな電子メール キャンペーンに重点を置きます。
ミックスマックス: 上げられた 総資金調達額1,330万ドル 成功したセールスエンゲージメントプラットフォームとして運営を続けています。
Outreach.io: 到達しました 評価額44億ドル以上 セールスエンゲージメントプラットフォームとして IPO の可能性に向けて準備を進めています。
Apollo.io： 達成 16億ドルの評価額 2023年にセールスインテリジェンスプラットフォーム向けに1億ドルのシリーズD資金調達を予定しています。
GMass: Bootstrapの成功事例生成 月額14万ドル 電子メール マーケティング用の Gmail 拡張機能として。
ストリークCRM: 運用されている成功したGmailベースのCRM 2012年以来 大きな問題もなく。
トゥートアプリ: 成功しました 2017年にマルケトに買収された 1,500万ドル以上の資金を調達した後。
バナナタグ: 2021年にStaffbaseに買収された 「Staffbase Email」として運営を続けています。
キーパターンこれらの企業が成功するのは、 既存の電子メールワークフローを強化する メールを完全に置き換えようとするのではなく、機能するツールを構築します と 電子メール インフラストラクチャを支持するのではなく、反対するのです。

[!TIP]
あなたが知っているプロバイダーがここに記載されていませんか? (例: Posteo、Mailbox.org、Migadu など) 総合的なメールサービス比較ページ より多くの洞察を得るために。