Dmail

Dmail requirements are wallet login and recipient address format rules

Dmail requirements are a supported sign-in method, control of the selected wallet and a recipient identity that Dmail can resolve into a mailbox identity. Connect the wallet on its intended network, approve the login signature and enter a complete wallet address, activated DID, Dmail default address, NFT domain or traditional email address.

Choose the login identity before opening the mailbox

The login route settles the Dmail requirements for wallet control, network selection and the recipient identity that Dmail will resolve.

For an EVM identity, retain the 2-character 0x prefix and all 40 hexadecimal characters. The underlying 20-byte address therefore occupies 42 visible characters. MetaMask handles EVM accounts on Ethereum, zkSync Era and Linea. A Solana identity uses a 32-byte public key, which Phantom displays in Base58 without an 0x prefix. Internet Identity exposes an Internet Computer principal instead of either form. Dmail routes the mailbox through the identity selected during access, so control of that account determines later retrieval.

Choose Google or World ID only when that account, rather than a wallet key, is the identity you intend to maintain.

Wallet access, Google access and DIDs serve different control cases

Wallet access proves key control, Google access proves account control and an activated DID adds a resolvable label to an existing identity.

MetaMask and Phantom present public addresses directly, while Internet Identity and World ID supply their own authentication paths. Dmail also recognizes identity names from ENS, SPACE ID and Unstoppable Domains after the relevant identity appears in the account and is activated. A formal W3C DID starts with the 4-character did: scheme and contains at least 2 colon separators: one before the method name and another before the method-specific identifier. Human-readable name systems use their own resolution rules, so copy the exact activated label rather than converting it by eye.

A wallet address is the clearest choice for machine-verifiable routing. A DID or NFT domain is easier to read, while Google access avoids a browser-wallet dependency. None of these routes requires ownership of DMAIL merely to authenticate. The deciding condition is continuity: use the control path that the mailbox owner expects to retain.

Prepare the wallet session on the intended network

A Dmail wallet session needs an unlocked compatible wallet, the intended account and a network context that the connector recognizes.

Connection context

A DApp connection reveals the selected public address and lets Dmail request a signature. It never requires the private key or recovery phrase. If MetaMask and Phantom both handle EVM connections in one browser profile, confirm which extension answered the request because the displayed account becomes the login identity.

Network identifiers

Ethereum Mainnet uses chain ID 1, zkSync Era uses chain ID 324 and Linea uses chain ID 59144. Those identifiers are fixed network selectors, not balances or prices. Dmail has documented MetaMask access on zkSync Era and Linea, while Phantom supplies the separate Solana account model. Match the wallet network label to the intended login option before signing.

Signature and gas

A login signature is an off-chain proof and transfers 0 ETH. Read the wallet prompt before approval: a plain signature authenticates the session, while a transaction request belongs to a later on-chain action such as sending on a selected network. This distinction separates mailbox access from the network fee needed for execution.

Which recipient address format should I enter?

Dmail accepts the complete recipient identity for its selected class: raw wallet address, activated DID, default address, NFT domain or traditional email address.

EVM recipients

An EVM recipient starts with 0x and carries exactly 40 hexadecimal characters after it. Letters use the range A through F in either case, while digits use 0 through 9. EIP-55 keeps the hexadecimal body at 40 characters, supplies about 15 check bits and leaves a 0.0247% accidental acceptance probability for a mistyped address. Mixed-case checksum form provides an extra validation signal, so preserve the casing supplied by the wallet or ENS resolver.

Solana and Internet Computer recipients

A Solana public key encodes 32 bytes with the 58-symbol Base58 alphabet, which is case-sensitive and omits 4 visually ambiguous characters: zero, uppercase O, uppercase I and lowercase l. An Internet Computer principal holds at most 29 bytes. Its textual form prepends a 4-byte CRC-32 checksum, applies Base32, groups characters in blocks of 5 and reaches no more than 63 characters including hyphens. Paste either form without changing case or separators, as set out in practice.

Worked address-length check

In this hypothetical worked example, the changing input is a 41-character EVM recipient string. Subtracting the fixed 2-character prefix leaves 39 hexadecimal characters, one short of the required 40. Adding the missing character produces the fixed 42-character total, so the string passes the length gate. Dmail must still resolve the completed value to the intended recipient identity before routing.

Default addresses and NFT domains require PID matching

Day to day, Dmail generates a default address at first login, and dual verification then requires the recipient’s PID alongside the visible mailbox label.

The compose interface expands a PID field for those 2 address classes. Treat the label and PID as one routing pair, because matching only one value does not complete the resolver input. Obtain both values from the recipient’s Dmail account view and preserve every character. An activated ENS, SPACE ID or Unstoppable Domains identity follows its displayed DID or name record instead. The extra PID requirement therefore changes with the address class chosen in the recipient field, not with the sender’s wallet brand or token balance.

The sending network sets the transaction requirements

The Dmail sending network must be supported by the connected wallet, and any transaction fee comes from that network’s execution model.

Connecting the wallet and signing the login proof costs 0 native tokens. A send that invokes an EVM transaction pays gas in the chain’s native asset. Ethereum denomination is fixed: 1 ETH equals 10^18 wei and 1 gwei equals 10^9 wei. The wallet calculates the payable amount from gas units, the network’s base fee and any priority fee. On BNB Chain the native asset is BNB, while Solana denominates transaction charges in SOL.

Next to that, Dmail lets the sender choose a sending network supported by the login wallet. That choice affects the transaction prompt and fee asset, not the syntax of a recipient on another supported route. Hold enough native asset only when the composed send requests an on-chain transaction; mailbox connection alone has no network charge.

Verify the routed identity before repeating a send

Ahead of that, Dmail verification should confirm the sender identity, resolved recipient, PID when required and selected sending network before a repeated message leaves the compose view.

Pre-send confirmation

Compare the full recipient string with the supplied value, including EIP-55 casing, Base58 case or Internet Computer hyphens. Check the expanded PID field when a default address or NFT domain triggers it. Subject and body are separate from routing, while an attachment must stay within Dmail’s fixed 3 MB limit.

Mailbox evidence

After sending, use the sent-mail record and the displayed recipient identity as the verification pair. Dmail automatically adds addresses that have sent or received messages to its address book, which reduces later transcription. Select that stored contact only after its first message shows the intended identity. A different account, DID binding or network label changes the verification decision.

The Dmail ID links login and retrieval

The Dmail ID turns a login network and public identity into the internal key that links routing, storage and later mailbox retrieval.

During dispatch, Dmail packages the sender, recipient, subject, message URI and timestamp for the relay path. Its router evaluates the recipient format and aligns that value with the corresponding Dmail ID. The recipient then authenticates through the linked wallet, Internet Identity, World ID or Google account to retrieve and decrypt the mailbox content. Internet Computer infrastructure remains part of Dmail’s storage and retrieval design, while the identity layer accepts multiple chain-specific address forms.

Maintain access to the original control path and record any activated DID or PID pairing. A new public address creates a new routing input; continuity changes after Dmail links or activates that identity within the unified account.

Frequently asked questions

Can a read-only wallet address create a Dmail session?

A read-only address cannot complete wallet-based Dmail authentication because it cannot produce the requested signature. The public address is enough for another sender to identify a recipient, but opening the associated mailbox requires control of the corresponding signing method. Use MetaMask, Phantom or the wallet that owns the key. If the mailbox uses Google, World ID or Internet Identity instead, authenticate through that linked account rather than importing a watch-only address.

Does a Dmail login signature move funds from the wallet?

A plain Dmail login signature does not move funds because it signs authentication data off-chain. The wallet prompt should identify the action as a message or sign-in request, and the balance remains unchanged. A transaction prompt is a separate operation with a network fee and execution details. Sending through an on-chain route can produce that second prompt, so distinguish the initial session signature from the transaction that dispatches the message.

Which EVM address casing is best for a Dmail recipient?

The EIP-55 mixed-case checksum form is the best EVM recipient representation because its casing carries validation information. All-lowercase hexadecimal remains structurally possible for many EVM parsers, but it discards that check. Preserve the complete 42-character string produced by MetaMask, an ENS resolver or another trusted wallet interface. Do not normalize the letters by hand. Dmail still needs the correct address class and any separate PID that its compose form requests.

When should I activate an ENS name before using it as a recipient?

Activate the ENS identity in Dmail before relying on it as a recipient label. Dmail’s account settings show DIDs and supported name identities held by the connected address, then let the user activate one as a Web3 email identity. Registration alone does not establish how the compose resolver should route that name. After activation, copy the displayed form exactly and confirm whether the recipient view also supplies a PID or another matching field.

Are uppercase and lowercase Solana recipient strings equivalent?

Uppercase and lowercase Solana characters are not interchangeable because Base58 encoding is case-sensitive. A 32-byte Solana public key becomes a text string whose exact letter case contributes to the decoded value. Changing one letter can produce a different address or an invalid string. Copy the public key directly from Phantom or the recipient’s Dmail identity view, retain every character and do not add the EVM-specific 0x prefix.

Can one wallet expose several sender identities in Dmail?

One connected wallet can expose multiple Dmail sender identities when the account contains a generated default address, bound NFT domain or activated DID. The compose view lets the user choose among available identities in the From field. Each label still resolves through the unified account and its control path. Before sending, select the identity that recipients should recognize and keep its domain or DID activation intact for future replies and mailbox retrieval.