Email and onchain names: what does not work yet
Why staff cannot have an ordinary mailbox at .yourbrand, which parts of email depend on the DNS, and how the DNS domain and the onchain name share the work.
The question usually arrives a few days after the organization takes control of its onchain TLD. Someone in marketing, or a member of the executive team, asks the IT lead whether staff can have a mail address that ends in .yourbrand. It is a reasonable request. The name is short, it is the brand itself, and it now belongs to the company.
The answer is no, and it is worth giving that answer with the reason attached. Internet email is built on the DNS. Every mail server in the world finds its destination by asking the DNS where mail for a domain should go. An onchain name is recorded on a blockchain and not in the DNS root, so the question a sending server asks comes back empty. No setting in your mail platform changes that, because the lookup happens on the sender’s side, on machines you do not run.
This article explains the limit at the level of detail an IT or brand lead needs to defend it in a meeting. It then sets out what the workarounds on offer really are, where the DNS is simply the better tool, what the onchain name does carry, and how to give staff an identity that uses both names without confusing anyone.
How a message finds a mailbox: one lookup in the DNS
An email address has two parts. The part before the at sign names a mailbox. The part after it names a domain. The mailbox part means something only to the organization that runs the mail for that domain. The domain part is the piece the rest of the internet has to understand.
When a colleague at another company presses send, their mail server takes the domain part and asks the DNS a specific question: which servers accept mail for this domain? The answer is held in mail exchanger records, usually shortened to MX records. An MX record is a line in the domain’s DNS zone that names a mail server and gives it a priority. The sending server picks the preferred one, looks up its network address, again in the DNS, opens a connection and hands the message over.
That lookup is not a courtesy or a convention that a clever provider can skip. It is the only way the sending server has of learning where to connect. The sender’s software has no directory of mailboxes, no list of companies and no knowledge of your internal systems. It has a domain name and a resolver, which is the component that walks the DNS from the DNS root down to the zone that holds the answer.
Two consequences follow, and both matter for the request on your desk. First, delivery is decided by the sender’s infrastructure and not by yours. Second, the sender’s infrastructure asks one naming system only. Mail servers were written to query the DNS, and the operators of the large mail platforms have had no reason to teach them another source.
Why an address ending in .yourbrand has no route
An onchain TLD is a top-level name recorded on a blockchain. On Freename, the registry most readers will meet, the TLD exists as a token sitting in a wallet, and whoever controls that wallet is the only party able to create names beneath it, such as pay.yourbrand. These names live outside the ICANN DNS root. A wallet or a browser that has been built or extended to read the registry can resolve them. Software that has not been taught to do so cannot.
Put the two facts side by side and the limit is plain. A sending mail server receives a message for a mailbox at a name under .yourbrand. It asks its resolver for the MX records of that name. The resolver starts at the DNS root, which holds the table of every top-level domain delegated in the DNS. The string is not in that table. The resolver returns the standard reply for a domain that does not exist, and the sending server reports a permanent failure to the person who wrote the message.
The failure happens before any connection is attempted. Your mail platform never sees the message, so there is nothing to accept, filter or redirect. This is why configuring a mailbox on your side achieves nothing. You can create the mailbox, and your own platform may even agree to hold it, but nobody outside can reach it.
The obstacle starts earlier than delivery in many cases. Web forms, customer relationship tools and mail clients validate an address before they accept it. Some check only the shape of the address. Others check the ending against the set of top-level domains that exist in the DNS, or try a DNS lookup of the domain on the spot. An address ending in .yourbrand fails the stricter checks, so a member of staff could not use it to register for a conference, open a supplier account or reset a password.
Records that an onchain name can hold do not fill the gap. A name can point to wallet addresses and to content, and a registry may let the holder store other text against it. A sending mail server does not read any of that. It asks the DNS, and the DNS has no entry.
The four DNS layers under a working mailbox
Even if delivery could be solved, a working corporate mailbox depends on more than MX records. Over the years, the protections that keep mail trustworthy were all anchored in the same place. An IT lead should know them by name, because each one is a separate reason the answer is no, and each one is a reason the DNS domain deserves care.
The table sets out the layers. The abbreviations are the standard ones: SPF, DKIM and DMARC are the three mechanisms a receiving server uses to decide whether a message really comes from the domain it claims.
| Layer | What it does | Where it lives |
|---|---|---|
| Routing | Names the servers that accept mail | MX records in the DNS |
| Sender authorization | States which servers may send for the domain (SPF) | A text record in the DNS |
| Message integrity | Publishes the key used to verify a message (DKIM) | A text record in the DNS |
| Domain policy | Tells receivers what to do with failures (DMARC) | A text record in the DNS |
Routing has been covered. The three authentication layers work on the receiving side. When your staff send a message, the receiving server looks up records under the sending domain to see whether the sending machine is authorized, whether the message was altered on the way, and what the domain owner wants done with messages that fail. All three lookups are DNS queries. A message that claims to come from a name with no DNS presence cannot pass any of them, and large receiving platforms treat mail that fails authentication as suspect or refuse it.
Encryption between mail servers leans on the DNS as well. It uses certificates, and the certificate authorities that the major platforms trust validate names in the DNS. Email is therefore not one feature waiting for one integration. It is a stack of agreements between independent operators, and every layer points at the DNS.
Workarounds on offer and what each one really is
Once the request is known inside the company, suggestions arrive. Most describe something real. None of them is a mailbox at .yourbrand that the outside world can write to. It helps to know what each one actually delivers.
Messaging between wallets
Some services let one wallet send a message to another, and some let the recipient be addressed by an onchain name. This can be useful between two parties who both use the same service. It is a separate, closed system. A customer writing from an ordinary mail client cannot reach it, your archiving and compliance tools do not see it, and your staff would have a second inbox to watch. Calling it email creates an expectation it cannot meet.
A provider that accepts the name inside its own platform
A mail or collaboration provider can choose to recognize any label it likes among its own users. Messages between two accounts on the same platform never leave it, so no DNS lookup is needed. The address works inside the walls and fails the moment anyone outside replies or writes first. For staff mail, where most correspondents are outside, this is a demonstration and not a service.
A private resolver on the company network
An internal DNS server can be told to answer for any name, including one that does not exist in the public DNS. Inside the network, machines would then find a mail server for the name. Outside, nothing changes. This also creates a name that behaves differently depending on where the user sits, which is a classic source of support tickets and, in the DNS world, a recognized collision problem.
Showing the name without routing to it
The display name of a mailbox, the mail footer and the business card are all free text. A footer can show pay.yourbrand as the place to send a payment, next to the mail address at the DNS domain. This is honest, and it is the route that works, provided the name is presented as what it is.
Where the DNS is simply the better tool for staff mail
It would be easy to present the limit as a temporary inconvenience. A fairer reading is that mail is one of the things the DNS does very well, and that the qualities that make it good are the opposite of what an onchain registry is designed for.
Mail needs universal reach. A message must be deliverable from any sender on any platform without prior arrangement. The DNS gives that because every operator queries the same DNS root and gets the same answer. Onchain names resolve where software supports them, and support is partial and changes over time. Partial reach is acceptable for a payment name that you show to people who already hold a wallet. It is not acceptable for the address on an invoice or a contract notice.
Mail needs records that change often and quietly. Moving to a new mail provider, adding a sending service for newsletters, rotating a key, tightening a policy: each is an edit to a DNS zone that takes effect within the time the records allow, and that a competent administrator makes without ceremony. Operations on an onchain name are transactions from the wallet that holds it. For a TLD, that wallet should be among the most protected things the company owns. Routine mail administration is the wrong job for it.
Mail needs delegation. A DNS zone can be administered by a team, with roles, change logs and a provider’s support desk behind it. On Freename, only the holder manages a TLD and there is no delegated management. That is a sound property for an asset whose control must be unambiguous. It is a poor fit for a service that a help desk has to keep running.
None of this is a criticism of onchain names. It is a statement about fit. A naming system built so that one wallet holds exclusive, verifiable control is strong where exclusive control is the point. Mail is a shared public utility, and the DNS is the registry that utility was built around.
What the name under .yourbrand does carry
The person who asked for a mail address usually wants something more general: to see the brand’s own name in use. That wish can be met, in the places where the name works.
The first is wallets. A name can stand in for a long wallet address, so that someone sending funds types pay.yourbrand and the wallet finds the destination. Two wallets read Freename names: Bitcoin.com Wallet, and MetaMask by way of Freename’s resolver. Coverage does not extend to every wallet, so each name you intend to publish is tested in the wallets your counterparties actually use. The page on names that resolve in wallets keeps track of where this stands.
The second is payments. A payment link can pay out to a name and not to a raw string of characters. With shaka, an onchain payment router, the division of a payment between several parties is agreed and signed onchain before any funds move, and the router passes funds through without holding them. For a finance team, the gain is legibility: the payee is a name under the company’s own TLD, which a human can read and compare. More on this pattern is on the page about payments to a name.
The third is websites. Freename’s builder, at builder.freename.com, lets a holder assemble pages or have them drafted from a short brief, then publishes them to IPFS, a network that stores content by its fingerprint. The site is reached through the onchain name in browsers that support it, which on the desktop means browsers running the Freename Web3 extension. An ordinary browser without support does not open the name. A site on the onchain name is therefore a complement to the DNS site, as the page on websites published on an onchain TLD explains.
The split that results is simple enough to put on one slide.
| Task | DNS domain | Name under .yourbrand |
|---|---|---|
| Staff and shared mailboxes | Yes | No |
| Public website for all browsers | Yes | Only with support |
| Receiving onchain payments | Not designed for it | Yes, in supporting wallets |
| A readable name for a wallet | Not designed for it | Yes, in supporting wallets |
The full inventory of capabilities, with sources, is kept on the page that records what works on onchain TLDs. It is the page to check before promising a function to a colleague.
Pairing a mail address with a name under .yourbrand
The durable arrangement is two names per function, each doing the job it is good at. The DNS domain carries mail and the main website. The onchain TLD carries payment names, wallet identities and, where it helps, a published site.
Start with functions and not with people. A treasury team that receives onchain payments gets a name such as pay.yourbrand, pointing at a wallet the company controls under its own custody rules. A regional office might get its own payment name. Whether individual employees should hold names under the TLD is a separate decision with its own questions about wallets and departures, and it deserves its own policy.
Then decide how the two names appear together. A mail footer can carry the usual DNS address and, on a separate line, the payment name with a short label such as “onchain payments”. An invoice can show bank details and, as an alternative, the payment name. In each case the reader sees two things with two clear purposes. What you avoid is any layout that suggests the onchain name is a place to write to.
Decide who issues and who records. Since the wallet that holds the TLD is the only source of names beneath it, each new name is a deliberate act by whoever controls that wallet. Keep a register that pairs each onchain name with its function, the wallet it points to, the person accountable and the mail address of the team behind it. The register is what lets the help desk answer when someone asks what a name is for.
Plan the confirmation loop. The most useful habit to teach counterparties is to confirm a payment name through a channel they already trust, and for most of them that channel is mail from your DNS domain. So the two systems support each other. Authenticated mail from the DNS domain tells a supplier that pay.yourbrand is yours. The public registry record lets the supplier see that the name exists under the TLD and where it points. Neither replaces the other.
Finally, write the departure rule before it is needed. When a mailbox is closed, the DNS side follows a known routine. For an onchain name the question is which wallet it points to and who controls that wallet. A name pointing at a company wallet survives a change of staff untouched, which is one more reason to name functions before people.
What would have to change before mail could use an onchain name
The title says “yet”, and a careful reader will ask what the word is hiding. There are two distinct paths, and neither is in your hands.
The first path is that mail software learns to resolve onchain names. For that to be useful, it is not enough for one provider to add support. Sending servers at every organization that might write to you would have to query the registry, receiving platforms would have to find an equivalent of the authentication records, and certificate authorities would need a way to validate control of a name outside the DNS root. Each of these is a decision by a different set of operators. Nothing prevents it in principle. Nothing in how mail is run suggests those operators are close to it either, and a plan that depends on it is a hope and not a plan.
The second path is that the same string comes to exist in the DNS. In an ICANN application round, an organization can apply to have a top-level domain delegated into the DNS root, typically as a dotBrand reserved for its own use. If that happens, mail under the string works for the ordinary reason: there is a DNS zone, and MX records can be published in it. That is a different asset obtained through a different process, with its own cost, contract and operating obligations, and it would exist alongside the onchain TLD. The comparison of a dotBrand and an onchain TLD sets the two side by side.
The honest position for a planning document is that staff mail stays on the DNS domain for the foreseeable life of the plan, and that the onchain name is budgeted and justified on the functions it performs.
Answering the request for mailboxes at .yourbrand
The person who asked deserves more than a refusal. The sequence below turns the question into a decision the organization can use, and it can be completed in a few working sessions.
- Give the reason in two sentencesMail servers find their destination in the DNS, and the onchain name is not in the DNS. The limit sits on every sender's side, so no change to the company's own platform removes it.
- Ask what the name was meant to achieveMost requests are about visibility of the brand name, not about mail as such. Write down the real goal: a payment name, a campaign address, a sign of ownership, an identity for a team.
- Match each goal to a function that worksUse the task table above. Goals that need universal reach stay on the DNS domain. Goals that involve wallets, payments or a published site can move to a name under the TLD.
- Test before anything is printedResolve each proposed name in the wallets and browsers your audience uses, on the devices they use, and record the result. Publish only what passed.
- Write the wording that accompanies the nameEvery public appearance of the name says what it is for and where it resolves. Brand, legal and IT agree the sentence once and reuse it.
- Record the decisionNote that staff mail remains on the DNS domain, who may ask for a name under the TLD, and when the question will be looked at again.
A first working session for IT and brand leads
Put three items on the agenda of one meeting, with IT, brand and whoever is accountable for the wallet in the room.
First, list every place where the company’s mail address appears in public, and confirm that all of them use the DNS domain and will continue to. While you are there, check that the domain’s authentication records are in good order. The discussion about onchain names is a good occasion to give the mail domain the attention it rarely gets.
Second, choose the first two or three names under the TLD that have a real function, starting with a payment name, and agree the wallet each one points to. If the organization has not yet planned how the TLD is put to use after it changed hands, the page on post-transfer activation describes the work involved, and the glossary gives the team a common vocabulary for resolvers, records and wallets.
Third, agree the sentence that will accompany the name wherever it is shown, including the plain statement that it is not a mail address.
Hush Partners works on the acquisition and transfer of onchain TLDs, and on putting them to use afterward. If the mail question has surfaced because your organization is weighing whether to acquire the TLD that matches its name, or has just done so, the desk can be reached through the contact form. Mail itself is a matter for your DNS and messaging teams.
Questions people ask
Could a mail address at our DNS domain forward to an onchain name?
No. Forwarding sends a message from one mailbox to another, and the destination still has to be found through MX records in the DNS. An onchain name gives the forwarding server nothing to look up. Forwarding between two DNS domains works as usual and has nothing to do with the onchain name.
Does the limit also apply to calendar invitations and collaboration tools?
Largely, yes. Calendar invitations travel as mail, and most collaboration and single sign-on tools identify a user by a mail address whose domain the organization has proven it controls through a DNS record. An identity ending in .yourbrand cannot complete that proof, so these tools stay on the DNS domain as well.
Can an AI assistant connected to the registry set up mail on the name?
No. Freename publishes a Model Context Protocol server that lets an AI assistant work with the registry in a conversation, including managing the records of a name, and an assistant connected this way acts as the holder. It can do what the holder can do. Mail fails on the sender’s side, in the DNS, and no record set on an onchain name alters that.
