A few short items that don’t quite warrant their own blog post…

@ in DNS records

Whilst working with a customer on their Office 365 integration recently, we had a requirement to add various DNS records, including the TXT record for domain verification which included an @ symbol. The DNS provider’s systems didn’t allow us to do this, or to use a space instead to denote the origin of the domain. Try googling for @ and you’ll have some challenges too…

One support call later and we had the answer… use a *.  It seemed to do the trick as soon after that the Microsoft servers were able to recognise our record and we continues with the domain configuration.

Are ‘ and & “legal” in an email address?

Another interesting item that came up was from running the IDfix domain synchronisation error remediation tool to check the on-premises directory before synchronisation.  Some of the objects it flagged as requiring remediation were distribution groups with apostrophes (‘) or ampersands (&) in their SMTP addresses. Fair enough, but that got me wondering how/why those addresses ever worked at all (I once had an argument with someone who alleged that the hyphen in my wife’s domain name was an “illegal” character). Well, it seems that, technically, they are allowable in SMTP (I struggled reading the RFCs, but Wikipedia makes it clearer) but certainly not good practice… and definitely not for synchronisation with Azure AD.

Changing the search base for IDfix

I mentioned the IDfix tool above and, sometimes, running it against a whole domain can be difficult to cope with the results.  As we planned to filter directory synchronisation on certain organizational units (OUs), it made sense to query the domain for issues on those same OUs. This is possible in the settings for IDfix, where the LDAP query for the search base can be changed.