Between parent and alias domain name spaces, the validation routines for recipient email addresses obtain the operating domain, and all other domains it can find, to subsequently examine whether the parent domain name space of the recipient email domain name space holds the desired recipient email domain name space in one of the values for the domain name attribute.
This functions for a domain name space like so:
```
dn: associateddomain=example.org,cn=kolab,cn=config
associateddomain: example.org
associateddomain: example.com
```
Where operating against either the `example.org` or `example.com` (factually the `example.org` domain name space) domain name space will allow recipient addresses in both the `example.org` and `example.com` domain name spaces.
In a hosted scenario however, a provider will need to be able to allow the customer to verify ownership of additional domain name spaces. This builds the use-case for child domain name spaces:
```
dn: associateddomain=example.org,cn=kolab,cn=config
associateddomain: example.org
inetdomainbasedn: ou=example.org,dc=hosted,dc=domain
dn: associateddomain=example.com,cn=kolab,cn=config
associateddomain: example.com
inetdomainbasedn: ou=example.org,dc=hosted,dc=domain
```
Validation therefore requires the association of the `example.com` domain name space with the (original parent) domain name space of `example.org`, so that both domain name spaces can be used for recipient email addresses without having to specifically select an operating domain first. Note that a single user `doe@example.org` may in fact also hold aliases in `example.com`, and as such choosing an operating domain first is an invalid path.