_for-sale is a reserved DNS leaf node name, defined by RFC 10023 (Informational, July 2026) and registered with IANA. A TXT record published at _for-sale.example.com signals that example.com, although registered and resolving normally, is available for purchase.
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/for-sale"The record carries a mandatory version tag followed by at most one tag=value pair:
| Tag | Meaning | Example |
|---|---|---|
ftxt= |
Free human-readable text | ftxt=Eligibility criteria apply. |
furi= |
Contact or information URI | furi=mailto:hq@example.com |
fval= |
Asking price, currency + amount | fval=EUR2500.00 |
fcod= |
Proprietary code, by prior agreement | fcod=XX-aHR0cHM... |
The wrong belief to clear first is that this is a way of parking a domain. It is close to the opposite. Parking replaces the site with a sales page, which costs you every visitor the domain still has. _for-sale sits beside a live site in DNS and says nothing to a browser: the homepage keeps serving, the mail keeps flowing, and the record can be added and removed at will. RFC 10023 makes the point explicitly — the convention is designed to work while the domain is still in active use.
It is also not the same thing as registration data. WHOIS and RDAP answer “is this name registered?”; a registered name may still be purchasable, and an unregistered one may not be worth having. That gap is the whole reason the convention exists, and it is why brokers and automated availability services are the intended audience rather than people.
The signal a domain owner most wants to send is the one there has never been a channel for. If you are willing to sell, the interested buyer has no way to learn that short of a cold email to a WHOIS contact that privacy redaction has probably removed. Enquiries that would have been welcome never arrive, and the ones that do arrive are indistinguishable from spam.
Putting the signal in DNS rather than on the page is what makes it useful to the parties who can act on it. A broker or an availability service checking a name resolves it anyway; one extra lookup tells them what a rendered page could not, because nothing on a working homepage says “the domain under this is negotiable”. It is externally checkable, costs one record, and carries no risk to the site itself — a browser never sees it.
Publish a single TXT record at the _for-sale leaf of the zone you are selling, and only while you mean it.
; Free text
_for-sale IN TXT "v=FORSALE1;ftxt=Serious offers only"
; A URI to negotiate through — https, mailto and tel are the usable schemes
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/fs?d=eHl6"
; An asking price: uppercase currency code, then the amount
_for-sale IN TXT "v=FORSALE1;fval=USD12500"Rules worth getting right the first time:
v=FORSALE1;. It exists so a processor can tell a real _for-sale record from an unrelated TXT record that a DNS wildcard happened to expand into that name._for-sale.example.com is valid at any level of the tree, but xyz._for-sale.example.com is not, and records under .arpa must be ignored — an offer to sell address space is out of scope.Sign the zone with DNSSEC if you can. An unsigned TXT record asserting your domain is for sale, at a price, with a contact URI, is a comfortable thing for someone else to forge.
This site does not ship a _for-sale record: specification.website is not for sale.
"v=FORSALE1;fval=EUR2500;furi=https://…" looks reasonable and is not what the format defines. Use one pair per record, multiple records per RRset.fval= price is indicative — the RFC tells processors to display a disclaimer and never to treat it as a purchase commitment._for-sale.*.example.com is not a valid wildcard. There is no way to put every domain under a TLD up for sale with one record.ftxt= is attacker-controlled text and furi= is an attacker-controlled URI. Sanitise before display — the RFC’s own example content is <script>...</script> — and never auto-navigate a user to a furi= target without an explicit confirmation step.dig +short TXT _for-sale.example.comv=FORSALE1; and contains at most one tag=value pair per string.dig TXT _for-sale.example.com | grep _for-sale.dig +dnssec TXT _for-sale.example.com returns a validating RRSIG.pendingDelete period, or when DNSSEC validation is bogus, the name will not resolve and the signal silently disappears.