TXT records contain, at a minimum, only two pieces of information: the prefix, and the recipient_address. Let's take a look at a typical OpenAlias TXT record:

oa1:xmr recipient_address=46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em; recipient_name=Monero Development;

The record always starts with "oa1:", which indicates it is an OpenAlias Version 1 record. If we don't have that prefix we ignore the record, as it may be an SPF record or something else that we don't care about. For other applications, Bitcoin for example, that prefix would be oa1:btc or whatever the developers choose. OpenAlias does not maintain a repository of prefixes at this stage, but may do so in future.

At a minimum, the recipient_address key-value must exist. OpenAlias exists to alias FQDNs to an "address" of any type, and this is expressed in this value. Future versions of the OpenAlias standard may implement alternative bare-minimums if use-cases are found besides FQDN->Address use.

Key-value pairs are separated by a semi-colon and, optionally, a space for legibility. The value may or may not be wrapped in double-inverted commas, which should be removed from the value if found at the beginning and end of the value. The value should also always be trimmed of spaces, unless the space is escaped with a backslash. Dependent on the DNS library or implementation you use, you may find that the semi-colon at the end of the pair is escaped with a backslash.

In order to not overcomplicate this, a semi-colon is a forbidden character unless it is in a value that is entirely wrapped in double-inverted commas. Similarly, a double-inverted comma can exist anywhere in the value without needing to be escaped, unless it is both at the beginning and the end of the value, which is not allowed. Keys and values are not limited in size, although it is counter-productive to have exceedingly large key-values, as DNS is not designed as a data transfer mechanism.

The other key-value pair in our example is the recipient_name. This is not necessary, but useful for the purpose of confirming the correct recipient with the user, or for providing the user with the option of adding an entry to an address book.

For a discussion about the additional standard (optional) key-value pairs, please see the Extend section below

This is what the same FQDN has, but for Bitcoin: