Dmail linked Web3 identities with email and project messaging before its announced shutdown
Dmail, also known as Dmail Network, was a decentralized messaging network that connected Web3 identities with email, subscriptions, and project notifications. Its decentralized application (DApp) combined wallet-linked mailboxes with decentralized storage, while SubHub handled messages between projects and subscribers. In April 2026, the team announced a gradual shutdown beginning May 15, 2026, and instructed users to export their emails beforehand. The announcement attributed the closure to infrastructure costs and unsuccessful monetization.
Updated on
Mailboxes and identity services shared the messaging protocol
The Dmail Messaging Protocol joined several address types to a common communication system. The DApp provided mailbox functions, while DaaS supplied an identity-binding service.
The mailbox application
The application supported sending, receiving, and managing email through wallet-linked accounts. Its inbox included ordinary correspondence and subscription messages, with reply, forward, delete, and batch actions. Senders could choose different activated identities within the account system. Traditional email compatibility extended correspondence beyond blockchain-based addresses. Cross-chain asset-transfer functions also formed part of the wider product design, alongside an AI Mail Assistant for composing messages and replies.
DaaS and named addresses
DaaS (DID-as-a-Service) let users bind supported decentralized identity domains as Web3 email addresses. Supported decentralized identifiers (DIDs) included names from ENS, SPACE ID, and Unstoppable Domains. Native non-fungible token (NFT) domains provided another route: users could bind these transferable blockchain assets to their mailbox.
Subscriptions connected users with project messages and activity alerts
Subscription & Notification, also called SubHub, connected a project’s subscribed audience with its messages. The Subscription Center let users choose projects or topics and manage subscriptions. Its Tracking Bot monitored on-chain and off-chain events, including asset transfers and token price changes, with customizable alert thresholds. Project profiles collected descriptions, announcements, events, and subscription information, while users could leave subscriptions and choose notification channels.
The project-facing tools combined subscriber management, message distribution, and task-related rewards. Projects could send to their full subscriber list or selected recipients. Updates reached the application’s inbox and configured channels, including browser notifications, ordinary email, Telegram, and Discord. Audience selection governed who received a project message, while delivery settings governed where the subscriber received an alert.
Pre-shutdown service options involved different kinds of control
Some choices concerned the identity used for correspondence; others concerned subscriptions, audience selection, or drafting help.
| Service option | Main use | User or sender control |
|---|---|---|
| DApp mailbox | Read and manage correspondence | Mailbox user chose the sending identity |
| NFT domain address | Use a personalized blockchain-based mail identity | NFT owner could bind, transfer, or trade the domain |
| DaaS-linked DID | Use an existing supported identity for email | DID holder chose which owned identity to activate |
| Subscription Center | Receive updates from selected projects | Subscriber chose projects, channels, and whether to unsubscribe |
| SubHub project messaging | Contact a subscribed audience | Project operator chose all subscribers or selected recipients |
| AI Mail Assistant | Get help drafting messages and replies | Mailbox user requested assistance with message content |
The Marketing Hub proposal added targeted advertising and rewards for viewing advertisements to the product vision. It combined wallet-profile targeting with user preferences for advertising. That proposed offering had a different purpose from ordinary subscribed project updates.
Points and DMAIL served different roles
Task points supported mailbox privileges, while the DMAIL token belonged to the network’s governance and utility design.
Points and account levels
Account levels depended on the point attributes of the bound NFT domain. Those levels affected daily sending allowances, encrypted storage space, and task-reward multipliers. Users could import earned points into their active domain, creating an on-chain attribute update that could not be reversed. The point attributes stayed with an NFT when its owner transferred or sold it. The account that later bound the domain used the level associated with those attributes. Some additional services, including the AI Mail Assistant, also used points.
DMAIL and network utility
DMAIL was issued on Ethereum as an ERC-20 token and on BNB Chain as a BEP-20 token. Its token design covered governance voting, ecosystem incentives, payments for specified services, and relay-node staking. These intended uses depended on the surrounding services and network.
Content privacy and audience profiling covered different data
The DApp’s design used end-to-end encryption to protect message content and decentralized storage to retain it. These functions addressed confidentiality and availability, respectively.
Wallet-linked messaging also supported subscriber profiling. Project-side audience management categorized subscribed addresses using blockchain assets, transaction records, and transaction frequency. Operators could organize audiences with tags and groups based on that activity. The encrypted mailbox’s privacy design concerned the contents of messages.
Exchanging messages with conventional email addresses was a separate function from binding a native NFT domain or an existing DID.
The shutdown notice separately warned that emails would become inaccessible when nodes stopped. Protecting message contents and maintaining access to those messages required different safeguards. Decentralized storage still needed infrastructure that could continue operating.
Infrastructure costs drove the shutdown announcement
Bandwidth, storage, and computing costs became central reasons for ending the service. The shutdown explanation also identified unsuccessful paid models and a token economy that had not developed sufficient practical demand.
Financing and acquisition attempts failed as well, while core-team departures left remaining members without enough capacity to maintain the expensive infrastructure. The announcement followed five years of operations.
The team announced that services would begin winding down on May 15, 2026. Users were told to export their email content before that date. The notice connected the loss of mailbox access with the stopping of the network’s nodes, making external copies necessary for preserving existing correspondence.
Address ownership and saved email had different limits
An address NFT and the messages in its mailbox were different objects. The NFT represented a mail identity and carried point-related attributes. Email content depended on the network’s storage services, which the shutdown notice said would stop. Continued possession of an address identity therefore could not substitute for an exported copy of the correspondence.
Exporting before the deadline preserved a copy outside the nodes covered by that warning. The team also expressed a hope of relaunching in a more mature form if future conditions allowed. That possibility did not change the export deadline that applied to the original service.
Details worth knowing about Dmail
Was a recipient’s PID required for every Dmail address type?
The historical sending rules required a Principal ID (PID) alongside the recipient address for default wallet-based addresses and native NFT domain accounts. This pairing supported address matching and spam prevention. DID-addressed messages followed separate activation rules, so the PID requirement should not be extended to every communication address.
Which networks could a connected wallet select for sending email?
The earlier sending interface allowed sending through networks supported by the wallet used for the session. Available network choices therefore depended on that wallet’s support. Gas costs varied with the selected network; the interface did not establish one universal sending charge across all supported chains.
What was Dmail’s email attachment limit before the shutdown?
The earlier email-sending interface supported attachments up to 3 MB. That limit applied to the historical sending interface and was separate from the account’s overall encrypted storage allowance.
Could the AI Mail Assistant create multilingual email drafts?
The AI Mail Assistant supported multilingual email templates in the historical DApp design. Its GPT-4 integration provided help with composing messages and replying in context. The assistant had an initial free allowance, with later uses charged in points.
Where did messages sent to an inactive DID go?
The pre-shutdown system kept messages for an inactive supported DID in its inbox until the owner activated that identity or logged in with it. An inactive identity therefore did not automatically mean that a message had failed. That waiting behavior required the mailbox service’s storage nodes to remain operational.
Were rewards offered for every subscription notification?
The historical subscription system offered rewards for reading certain messages and meeting specified activity or credential conditions. The tools combined ordinary project updates with specific reward opportunities and task-related programs. Receiving an announcement alone did not establish eligibility for a token payment.
Did holding DMAIL confer ownership of the operating company?
DMAIL’s token terms excluded shareholding or ownership interests in the company and foundation. The token’s governance design concerned network decisions and specified ecosystem uses. Holding it was different from holding corporate equity.