⏱️ Lectura: 10 min
Since July 2026, there’s a standardized for-sale DNS record that states, unambiguously, that an active domain is for sale: without touching the site it already serves or the email that already works. It’s called _for-sale, a reserved TXT record, defined in RFC 10023, published as Informational and registered with IANA.
📑 En este artículo
The problem it solves is specific: today, if the owner of an active domain wants to sell it, there’s no reliable channel to announce it. A cold email to the WHOIS contact, which privacy protection has probably already hidden, is the only option available. _for-sale moves that signal to where brokers and automated availability services already look: DNS itself.
TL;DR
- RFC 10023 (Informational, July 2026) standardizes the
_for-saleDNS record and registers it with IANA. - The TXT record is published at
_for-sale.domain.comwithout affecting the site, email, or any other service on the domain. - Required format: it starts with
v=FORSALE1;followed by a singletag=valuepair (ftxt, furi, fval, or fcod). - Only one pair is allowed per record: for both price and contact, you need two TXT records in the same RRset.
- The limit is 255 octets per character-string, and a TTL of 3600 seconds or less is recommended.
- It doesn’t replace WHOIS or RDAP: a registered domain can still be for sale, and that gap is exactly what it solves.
- The RFC recommends signing the zone with DNSSEC, because an unsigned TXT record with a price and contact is easy to forge.
- specification.website, the source for this article, clarifies that its own domain doesn’t publish the record: it’s not for sale.
What Happened
RFC 10023 formally reserves the _for-sale leaf node name within the DNS tree and registers it with IANA as an underscore namespace, the same technical family already used by _dmarc for mail policies or _acme-challenge for certificate validation. The full specification, with the tag table and common implementation errors, is published at specification.website.
A minimal record looks like this:
_for-sale IN TXT "v=FORSALE1;furi=https://miempresa.com/en-venta"The core rule is that this TXT record doesn’t change anything the domain already does. The homepage keeps responding, email keeps being delivered, and the record can be added or removed without any side effects on traffic. A browser never sees it: only those who already know to look for it query it.
Context and History
The most common confusion is thinking _for-sale is a form of domain parking. It’s nearly the opposite. Parking a domain replaces the site with a sales page, which costs every visit the domain still receives. _for-sale coexists with an active site without telling the browser anything.
It’s also not the same as registration data. WHOIS and RDAP answer a different question: is this name registered? A registered name can still be for sale, and an unregistered one might be worthless. That difference is why the convention exists, and it explains why the target audience is brokers and automated availability services, not people browsing by hand.
Technical Details and Performance of the for-sale DNS Record
The record supports four tags, and each TXT record carries at most one:
| Tag | Meaning | Example | When to Use It |
|---|---|---|---|
ftxt= | Free human-readable text | ftxt=Serious offers only | Clarify conditions without giving direct contact |
furi= | Contact or information URI | furi=mailto:[email protected] | Route offers to a single point |
fval= | Asking price: currency + amount | fval=USD12500 | When the price is fixed and public |
fcod= | Proprietary code, by prior agreement | fcod=XX-aHR0cHM... | Broker-platform integrations with a custom format |
The format rules are strict on purpose, so an automated processor never has to guess:
- The version tag is mandatory and case-sensitive: every record starts with
v=FORSALE1;. It exists so a processor can distinguish a real_for-salerecord from an unrelated TXT record that a DNS wildcard accidentally expanded to that name. - Only one tag-value pair per record. To publish both a price and a contact URI, two records are published in the same RRset, and the processor picks the one it understands. It’s not like SPF: the pairs don’t get concatenated.
- One character-string per record, with a maximum of 255 octets, so nothing has to be reassembled during parsing.
- The recommended TTL is 3600 seconds or less. A stale record announcing a price that’s already been withdrawn, or a domain that’s already sold, is worse than having no record at all.
- The record goes on a leaf node.
_for-sale.miempresa.comis valid at any level of the tree, butalgo._for-sale.miempresa.comis not, and records under.arpamust be ignored: an offer to sell address space falls outside the scope.
Here’s what the flow looks like when a broker queries a candidate domain:
sequenceDiagram
participant B as Broker
participant D as DNS Resolver
participant Z as Domain Zone
B->>D: query TXT _for-sale.midominio.com
D->>Z: resolve the record
Z-->>D: v=FORSALE1;fval=USD12500
D-->>B: responds with the TXT record
Note over B,Z: the website never takes part in the query⚠️ Heads up: an unsigned TXT record announcing a price and contact is an easy target to forge. The RFC recommends signing the zone with DNSSEC before publishing the record.
How to Start Implementing It
Publishing the for-sale DNS record is a single line in the zone file, at the _for-sale leaf node of the zone being sold, and only while the offer stands:
; Zone: midominio.com
_for-sale IN TXT "v=FORSALE1;fval=USD12500"
_for-sale IN TXT "v=FORSALE1;furi=https://midominio.com/en-venta"With that, any broker or availability service that already resolves the domain gets, with one extra query, something a rendered page can’t say: that what’s underneath is negotiable.
To confirm the record is published and well-formed, the query differs depending on the operating system:
Linux (Debian/Ubuntu):
sudo apt install -y dnsutils
dig +short TXT _for-sale.midominio.commacOS:
brew install bind
dig +short TXT _for-sale.midominio.comWindows:
nslookup -type=TXT _for-sale.midominio.com
REM alternative with dig, via Chocolatey
choco install bind-toolsonly -y
dig +short TXT _for-sale.midominio.comThe response should start with v=FORSALE1; and contain at most one tag=value pair per string. To check the TTL specifically:
dig TXT _for-sale.midominio.com | grep _for-sale💡 Tip: if the domain is no longer for sale, deleting the record is the only way to say no: the convention doesn’t define a “not for sale” value.
On the reading side, the content of ftxt= and furi= is controlled by whoever published it, not by you. The RFC says this explicitly, with an example of <script>...</script> as possible content. Any processor has to sanitize before displaying it, and should never automatically navigate to a furi= without explicit user confirmation:
// saneaSenalForSale.js
const dns = require('node:dns').promises;
async function leerForSale(dominio) {
const registros = await dns.resolveTxt(`_for-sale.${dominio}`);
const valor = registros.map(partes => partes.join('')).join('');
if (!valor.startsWith('v=FORSALE1;')) return null;
const par = valor.slice('v=FORSALE1;'.length);
const [tag, ...resto] = par.split('=');
const contenido = resto.join('=');
const escapado = contenido.replace(/[<>&\"]/g, c => ({
'<': '<', '>': '>', '&': '&', '\"': '"'
}[c]));
return { tag, valor: escapado };
}
leerForSale('midominio.com').then(console.log);The script resolves the TXT record, validates the version prefix, splits the tag from the value, and escapes characters before returning it. For a domain publishing fval=USD12500, the expected output is { tag: 'fval', valor: 'USD12500' }.
Impact and Analysis
The most relevant design point is that the record doesn’t ask anyone’s permission or obligate anyone. Publishing it doesn’t commit the domain owner to selling, and a published fval= is indicative: the RFC instructs processors to display a disclaimer and never treat it as a purchase commitment.
For brokers and domain marketplaces, the savings amounts to one query: if they already resolve the name to check availability, adding a TXT query for _for-sale gives them a signal that previously didn’t exist in any standard protocol. There’s no way to say “every domain under this TLD is for sale” with a single record, because _for-sale.*.miempresa.com isn’t a valid wildcard: each domain needs its own TXT record.
💭 Key point: publishing the record aspirationally, to attract offers that aren’t real, is exactly the abuse the RFC explicitly names as misuse of the convention.
The honest limitation is that RFC 10023 is Informational, not Standards Track. That means no registrar or DNS panel is required to make editing underscore names easy, and adoption depends on brokers, registrars, and panels deciding to support it. Publishing the TXT record by hand on a provider that doesn’t expose underscore subdomain editing may require technical support or a different DNS provider.
What’s Next
What comes next depends on adoption, not on the specification: if a major registrar adds a “publish _for-sale” field to its panel, or if a domain marketplace starts querying the TXT record as part of its appraisal flow, the convention goes from being a DNS trick to a real market signal. Until then, anyone with write access to their zone can try it out today.
📖 Summary on Telegram: View summary
Try it yourself: publish a test TXT record at _for-sale.tudominio.com and run dig +short TXT _for-sale.tudominio.com to confirm in minutes whether your DNS provider supports it.
Frequently Asked Questions
Does _for-sale replace parking a domain?
No. Parking replaces the site with a sales page and loses the traffic the domain still receives. _for-sale coexists with an active site without touching it.
Can I publish price and contact in the same record?
Not in the same string. Each TXT record carries a single tag-value pair; for both price and contact, you need two TXT records in the same RRset.
Does _for-sale replace WHOIS or RDAP?
No, it answers a different question. WHOIS and RDAP confirm whether a name is registered; _for-sale confirms whether, being registered, its owner is selling it.
Is DNSSEC required to use _for-sale?
It’s not required, but the RFC recommends it: without a signature, anyone can forge a TXT record with a fake price and contact.
What happens if I want to withdraw the offer?
You delete the record. The convention doesn’t define a “not for sale” value: the absence of the TXT record is the only way to say no.
Can I put every domain under a TLD up for sale with a single record?
No. _for-sale.*.miempresa.com is not a valid wildcard; each domain needs its own TXT record.
References
- specification.website: _for-sale DNS records: the full specification with the tag table, implementation rules, and common errors.
- IANA: the authority that registers reserved namespaces like _for-sale within DNS.
- RFC Editor: the official IETF RFC repository, where documents like RFC 10023 get published.
- Wikipedia: TXT record: general background on the DNS record type this convention uses.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Lightsaber Collection en Unsplash
0 Comments