Table of Contents
RFC 10023 defines the _for-sale TXT record, a way for a domain holder to say in DNS that a registered domain is available to buy. The RFC Editor published it in July 2026. The author is Marco Davids from SIDN Labs, the research team at SIDN, the .nl registry. Marco also reviewed this post before we published it, and his feedback made it better in a few places. Thanks, Marco.
The whole mechanism is one TXT record at _for-sale.<domain>. No protocol change, no new RR type, nothing for registrars or resolvers to upgrade. You publish the record when you want to sell, pull it when you don't, and the domain keeps serving its site and mail the whole time.
It's an Informational RFC, not Standards Track. Still, IANA has already added _for-sale to the Underscored and Globally Scoped DNS Node Names registry (the attrleaf registry from RFC 8552), so the label is reserved for this use.
WHOIS and RDAP tell you a domain is taken. They don't tell you if the owner would sell it. RFC 10023 fills that gap, and that's good news for domain marketplaces. From a security angle it's a bit messier.
The record holds free text and URLs written by whoever controls the zone, and tools are starting to parse and display it. The RFC's own security section warns about XSS, injection, homograph tricks and phishing links in these records, and about contact details getting scraped. On top of that, a _for-sale record on a live domain tells everyone its ownership might change soon.
That's the part this post focuses on: what the record looks like, how widely it's deployed, where parsers get it wrong, the security risks, and what to check if it shows up in a zone you're responsible for.
The _for-sale TXT record format
Every valid record starts with v=FORSALE1;. Case sensitive, no spaces, semicolon included. After the tag you can add one tag=value pair per record. Want to publish a URL and a price? That's two TXT records in the same RRset, not one record with both.
The smallest valid record is the version tag on its own:
_for-sale.example.com. IN TXT "v=FORSALE1;"If the tag is there but the rest is empty or doesn't parse, RFC 10023 says processors should still treat the domain as for sale and fall back to WHOIS or RDAP for contact info.
There are four content tags:
| Tag | What it carries | Example |
|---|---|---|
furi= | Exactly one URI. http, https, mailto and tel are the recommended schemes | v=FORSALE1;furi=https://example.com/fs?d=eHl6 |
fval= | Asking price: uppercase currency code plus amount, indicative only | v=FORSALE1;fval=EUR999 |
ftxt= | Short human-readable text | v=FORSALE1;ftxt=Call for info. |
fcod= | Opaque code that only means something to parties who agreed on it, like a registry and its registrars | v=FORSALE1;fcod=EXCO-S2lscm95IHdhcyBoZXJl |
fcod= is the odd one. A registry can map the code to a sales page in its own back end, so a buyer checking the name on the registry's site gets sent somewhere the registry controls instead of wherever the TXT record points. SIDN already does this: an NLFS- code on a .nl domain puts a For Sale button on its WHOIS page.
A full RRset can mix all of them. This one is from Appendix A.5 of the RFC:
_for-sale IN TXT "v=FORSALE1;furi=https://fs.example.com/"
IN TXT "v=FORSALE1;ftxt=This domain name is for sale"
IN TXT "v=FORSALE1;fval=EUR500"
IN TXT "v=FORSALE1;fcod=EXCO-ZGVhZGJlZWYx"Records in the RRset without the version tag don't count as a sale signal (people can still read them as extra info). If none of the records carry the tag, the whole node is ignored.
How many domains publish a _for-sale TXT record today?
More than you'd guess for an RFC that's a few months old. ForSaleDNS, an independent project that scans public DNS for these records, froze a baseline on 20 August 2026 and counted 341,642 domains with a valid v=FORSALE1; record, according to The State of For-Sale DNS 2026.
That number needs context, and to their credit the report gives it. SIDN has been running this with .nl registrars since 2022, back when it was a pilot, so .nl alone is 56.78% of the inventory. Two exact fcod values cover most of the records. So it's a few big broker deployments plus a smaller long tail, not 341k separate adopters.
What the records actually contain, per the same baseline:
| Tag | Share of current listings |
|---|---|
fcod= | 98.22% |
furi= | 64.07% |
fval= | 25.28% |
ftxt= | 0.04% |
Mostly machine codes and URLs, almost no free text. About 35.67% of listings had at least one TTL above the 3600 seconds the RFC recommends, and the report traces nearly all of those to a single .nl deployment using 86400.
Tooling is moving too. SIDN Labs keeps a resource page at rfc10023.nl with validators, test domains and third-party tools that already read the record, including happyDomain and marketplaces like Namegarage and Atom.
Validating a _for-sale TXT record: where parsers get it wrong
The spec is short, but there are a handful of places where a lazy parser will either miss real records or accept junk.
How strict to be with v=FORSALE1;
The ABNF is exact: uppercase, case sensitive, semicolon required. Lowercase v=forsale1; or a missing semicolon is not valid. The one bit of slack is in section 3.6 (Robustness), which says processors MAY accept a space right after the tag, so "v=FORSALE1; " can be treated as valid too.
In practice malformed tags look rare. The ForSaleDNS baseline classified 341,631 of its current listings as conforming and kept only 11 with tolerated syntax problems. They're careful to say that's only among records they stored as positive, not every broken record out there.
If you want to see what bad input looks like, the test domains on rfc10023.nl are a good place to start, and forsale.bitfire.nl is a syntax validator you can compare your results against.
One string per record, and parse the RDATA
Each record's RDATA has to be a single character-string of 255 octets max. "v=FORSALE1;" "ftxt=foo" "bar" is invalid. Some DNS dashboards split long TXT values on their own, so this one can happen without anyone noticing.
The RFC also tells parsers to work on the raw TXT RDATA, not the escaped presentation format you get from dig. Run the ABNF over dig output and escaped characters will break it. For non-ASCII content, it recommends UTF-8 and a restricted set of Unicode characters.
Wildcards
You can't put a whole zone up for sale with _for-sale.*.example., that isn't a valid wildcard. The more annoying case goes the other way. A zone with a wildcard TXT will answer a _for-sale query with whatever the wildcard holds, and the owner never meant it as a sale signal. That's the reason the version tag is mandatory.
Section 3.1 also warns that wildcards mixed with CNAME or DNAME can produce listings that point at someone else's domain.
Placement, TTL and resolution
The label must be a leaf, so xyz._for-sale.example. is non-conformant. Second level or deeper is fine. Anything under .arpa must be ignored (no selling IP space through this), and special-use names like .onion or .alt are out of scope.
Keep the TTL at 3600 or less. With a long TTL, buyers keep seeing the sale signal, or an old price, after the owner removed it. There's more on picking values in our TTL best practices guide.
And the record only works if the domain resolves. During redemption, in pendingDelete, or when DNSSEC validation comes back bogus, you won't see it.
One last thing that surprises people: publishing the record doesn't oblige anyone to sell. That's there to cover mistakes, not fake listings. The record is only meant for domains that are genuinely for sale or lease. Text saying the domain is not for sale is invalid content, the record should just be removed.
Security risks of the _for-sale record
It's a marketplace feature, sure. But it's also a public TXT record full of text written by whoever controls the zone, and a growing number of tools scrape it, parse it and show it to users. Section 4 of RFC 10023 is worth reading in full if you build any of those tools.
The RFC gives v=FORSALE1;ftxt=<script>...</script> as an example of a record that is malicious and still technically valid. It lists XSS, SQL injection, and Unicode tricks like bidirectional text and homographs as risks for anyone who renders the content without sanitizing it. So treat it like any other user input, because that's what it is. TXT records have carried malicious payloads before, this is just a new label for an old problem.
Then there's furi=. Processors MUST NOT redirect users to it without explicit confirmation. Think about who's reading these records: someone already in buying mode, ready to click a link and fill in a form. That's a nice audience for a phishing page.
The RFC also calls out the lazier abuse, using the record as a marketing lure with no intention of selling anything. Prices work the same way. fval= isn't binding, tools showing it SHOULD add a disclaimer, and automated systems SHOULD NOT commit to a purchase based on that number alone.
On the publisher side, a mailto: or tel: URI in public DNS will get scraped, the RFC says as much in its privacy section. We've already looked at how much TXT records give away on large company domains, and this adds contact details to the pile. There's also a quieter issue. Flagging a domain for sale while it still serves traffic tells everyone its ownership might change soon. If that domain sends mail or hosts something people trust, the next owner inherits that trust.
Finally, your own zones. If a _for-sale record appears on a domain or subdomain you run and nobody on your team added it, look into it. Maybe it's left over from a parked domain, maybe a wildcard is answering where it shouldn't, maybe someone with zone access is doing something they shouldn't. Most of the time it'll be boring, but it's the kind of change you want to hear about.
How to check a _for-sale TXT record
One dig query does it:
dig TXT _for-sale.example.com +shortThen read the answer with the RFC in mind:
- At least one record has to start with exactly
v=FORSALE1;. If none do, ignore the lot. - Each record should be a single quoted string. Several quoted chunks in one record make it invalid.
- One tag=value pair per record, no more.
- If there's a
furi=, look at where it goes before clicking. Check the scheme too, http and mailto have no transport security. - Look at the TTL. Anything over 3600 is above what the RFC recommends.
- If the zone might have a wildcard TXT, query a random label as well (
dig TXT _nothing-here.example.com) and compare, or run the domain through our wildcard DNS detector. Same answer for both labels means you're probably looking at the wildcard.
If you'd rather not read raw TXT output, there are online checkers too. The lookup tool on https://rfc10023.nl shows what a domain publishes, and forsale.bitfire.nl points out syntax errors.
How to add a _for-sale TXT record to your domain
If you're selling a domain and want to try it:
_for-sale.example.com. 3600 IN TXT "v=FORSALE1;furi=https://example.com/contact"A furi= is the most useful tag for third parties, since any tool can act on it without knowing a registry-specific code. If you'd rather not get spam, leave the email and phone number out. And remember to delete the record once it's sold.
How DNSAudit.io detects _for-sale records
Every DNSAudit.io scan now looks for a _for-sale TXT record on the domain. That includes anonymous scans and free accounts, with nothing locked. If one shows up, you'll see it in the DNS tab under Issues. If there's no record, nothing changes.
It's always Informational and never touches the score. A domain being up for sale says something about the owner's plans, not about how the DNS is configured.
We follow the RFC on the version tag: v=FORSALE1; exactly, uppercase, semicolon included, with the trailing space from section 3.6 allowed. That gives two possible results:
- Domain listed for sale. At least one record is valid. We list the sales link, the asking price, any text and the broker or registry code, plus a note if the TTL is above 3600 seconds.
- Malformed _for-sale record. Something is published at
_for-salebut it doesn't match the format. Think lowercase tags, a missing semicolon, or a record your DNS provider split into several strings. Tools that follow the standard will ignore it, so we tell you why.
Before reporting anything, we query a random sibling label too. If both come back with the same answer, it's a wildcard TXT talking, not a real listing, and we drop it.
Record content is treated as untrusted. Values are escaped before display. The furi link is shown as plain text and we never follow it. If it contains an internationalized domain name, we show the punycode form next to the Unicode one, so a lookalike domain can't pass for the real thing. Prices are labeled as indicative only, the same way the RFC asks.
Want to see if any of your domains publish one? Run a free scan at dnsaudit.io.
RFC 10023 FAQ
Is RFC 10023 an Internet standard?
No. It's an Informational RFC published through the IETF stream in July 2026. The _for-sale label is registered with IANA, but nobody has to publish or read the record.
Does a _for-sale TXT record affect my website or email?
No. It's a separate TXT record under its own label. Your A, MX and other records stay as they are.
Does publishing the record mean I have to sell?
No. The RFC says the record doesn't oblige the holder to sell, mostly so a record published by mistake doesn't turn into a legal dispute. That's not a license to publish one you don't mean, though. The record should only go up when you actually intend to sell or lease the domain, and it should come down when that's no longer true.
Can I put a _for-sale record on a subdomain?
Yes, the label can sit at any level as a leaf. The RFC notes that below the second level there may be no public registry to record who holds the rights, so the parties would need their own agreement.
What TTL should a _for-sale record use?
3600 seconds or less, so buyers don't keep seeing a stale signal or an old price.
How do I check if a domain is for sale with RFC 10023?
Query _for-sale.<domain> for TXT records and look for one that starts with v=FORSALE1;. The steps above go through what to check in the answer.
Wrapping up
RFC 10023 is small and well thought out. It reuses the attrleaf pattern from RFC 8552, needs no changes to existing infrastructure, and it's upfront about how it can be abused. Adoption already passed 340,000 domains by August 2026, according to ForSaleDNS, even if most of that comes from a few large deployments.
For anyone doing DNS security, the record adds three things to keep an eye on:
- Attacker-controlled content. A new place for content you don't control to reach your tools and your users. Validate it and escape it, and never follow its links automatically.
- Public contact data. More contact details sitting in public DNS, ready to be scraped.
- A signal in your own zones. If a
_for-salerecord shows up on a domain you run and nobody added it, find out why.
None of these make the record dangerous by itself. It just belongs on the list of things you check when you audit a zone.
The third one is easy to miss, since nothing tells you when a zone changes. A free DNSAudit.io account lets you track up to 3 domains, rescan anytime and compare against 14 days of history, with advanced mail security checks included. No card required.
