Copied to clipboard
← All posts

RFC 10023 Explained: The _for-sale DNS Record That Says a Domain Is Available

Until recently, the only ways to tell the world that a domain was for sale were clumsy: park it on a landing page, hope a buyer thinks to check the WHOIS contact, or list it on a marketplace and wait. Each of those either takes the site offline or depends on someone guessing where to look. In July 2026 the IETF published RFC 10023, a short Informational document that solves the problem with a single DNS record. This post explains what the record looks like, how to publish and read one, and why the details matter more than they first appear.

The idea in one sentence

If a domain has a TXT record at the underscored name _for-sale directly beneath it, and that record starts with v=FORSALE1;, the domain holder is saying the name is available for purchase. Nothing else about the domain has to change: the website keeps serving, mail keeps flowing, and the signal sits quietly in DNS for anyone who queries it.

The underscore prefix is not decoration. RFC 8552 reserves underscored leaf names for exactly this kind of machine-readable metadata, which is why _dmarc, _acme-challenge and _dkim already live in that namespace. RFC 10023 registers _for-sale alongside them, making it the first IETF-registered DNS node whose whole purpose is to express commercial intent.

What a record looks like

The simplest valid listing is the version tag alone:

_for-sale.example.com. IN TXT "v=FORSALE1;"

Optionally, a record carries one content tag after the version tag. Four are defined:

  • ftxt= — free text for humans, such as ftxt=Serious offers only, contact via the URL.
  • furi= — a single contact URI. Only four schemes are allowed: http, https, mailto and tel. For example furi=mailto:sales@example.com or furi=https://broker.example/listing/123.
  • fval= — an asking price as a one-to-three-letter uppercase currency code followed by an amount, with an optional decimal part: fval=EUR999, fval=USD750, fval=BTC0.000010.
  • fcod= — an opaque code meaningful to a particular registry, broker or marketplace, such as a listing reference.

Because each record may hold only one tag, a fully described listing is a small set of records rather than one long string:

_for-sale IN TXT "v=FORSALE1;ftxt=This domain name is for sale"
_for-sale IN TXT "v=FORSALE1;furi=https://fs.example.com/"
_for-sale IN TXT "v=FORSALE1;fval=EUR500"
_for-sale IN TXT "v=FORSALE1;fcod=EXCO-ZGVhZGJlZWYx"

A few rules are easy to miss. Tags are case-sensitive: the version tag is uppercase, the content tags lowercase. Values are limited to 239 octets and the whole record must fit in a single 255-octet character string, so you cannot split a long value across two quoted strings the way long DKIM keys do. The same tag may appear in several records with different values, but the same tag-value pair must not be repeated. Anything that breaks these rules is simply not a valid listing, and well-behaved tools ignore it rather than guess.

Where the record may live

The RFC allows the node at any level of the tree, not just under a registered domain. _for-sale.shop.example.com is a legitimate way to say that the subdomain shop.example.com is available, which matters for organisations that lease or sell names beneath their own. The one hard exclusion is the .arpa infrastructure zone, and special-use names such as .onion or .alt are out of scope too. Wildcards do not help here: _for-sale.*.example.com is not a valid wildcard, although an ordinary wildcard record and a real _for-sale node can coexist at the same parent without interfering.

How to publish one

  • Add a TXT record in your DNS provider's control panel with the host _for-sale (most panels append your domain automatically) and the value v=FORSALE1;.
  • Add optional records for a contact URI, a price and a note, one tag per record.
  • Check propagation before telling anyone. Our DNS propagation checker now accepts underscored names, so you can watch the record appear across resolvers worldwide.
  • Keep it current. A listing that outlives the sale, or a price that no longer applies, is worse than no listing. Remove or update the records when the situation changes.

How to read one

Any DNS client can query the node directly: dig TXT _for-sale.example.nl. That domain is the reference test zone used by the specification's authors and publishes a full set of records, including a decoy line that a correct parser must ignore.

We have built RFC 10023 support into every tool on this site that takes a domain. A WHOIS lookup, an IP and hostname lookup, an email domain check or a hostname resolution will show a "For sale" badge and a card with the seller's text, a clickable contact link, the asking price and any listing codes. The JSON API returns the same information in a for_sale object, with the raw records and a list of anything that was rejected and why, so you can build your own checks on top of it.

The security section is the interesting part

A record that anyone can publish and that contains URIs and prices is an obvious target for abuse, and the RFC spends real effort on it. Three points deserve attention from anyone building a reader:

  • Never redirect automatically. A furi= value is a suggestion, not an instruction. Tools must show it and let a person decide to click. Ours render it as a plain link with the full target visible on hover.
  • Treat prices as indicative. The RFC asks processors to say so explicitly, and warns automated systems not to make purchase commitments based on an advertised figure. A fval is an opening position, not a contract.
  • Sanitise everything. Free text and URIs arrive from an untrusted source. Validate the schemes, reject control characters, escape before rendering, and be alert to Unicode look-alikes in text meant to build trust.

There is a broader caveat the document is honest about: a _for-sale record proves that whoever controls the zone chose to publish it. It does not prove that the person answering the contact address owns the domain, and it does not prove the price. Treat the record as the start of a conversation and verify ownership through the registrar before any money moves, exactly as you would for a domain found any other way.

Why this is worth adopting

The convention costs nothing to deploy, works with every DNS provider that supports TXT records, and needs no coordination with registrars or marketplaces. For sellers it means a name can stay in productive use while still being discoverable. For buyers and brokers it turns a guessing game into a single, cheap query. For tools like ours it replaces heuristics such as "is this a parking page?" with an explicit, machine-readable statement of intent. That is a rare combination in DNS, where most new conventions ask for far more than one record.