We are going to take a step out of the Lync Department for a post (and add a new category on the blog) and chat about DNS/Reverse DNS/PTR records in Microsoft Azure.
Windows Virtual Machine running Microsoft Exchange (or another e-mail product) you want to ensure that when sending e-mail you don’t get bounce backs due to reverse DNS lookup issue. I found my process through what felt like several hundred Bing searches (and that other search engine also) so I thought I would post my entire process in a single location. If for nothing else, so I remember what the process is next time I need to configure and set this up.
The first thing I need to do is get the public IP Address of my virtual machine. (NOTE: As far as I can tell, as long as I never shutdown my virtual machine, it will keep the public/private IP assigned to it forever.) Logging into the Azure Portal and navigating to Virtual Machines you should find the public/private IP.
My domain is registered through GoDaddy and as such I’ve been using their DNS Manager for all record keeping. Next, we go to the GoDaddy DNS Manager and set the following items:
|A||@||Public IP From Azure|
|TXT||mail.domain.com||v=spf1 a mx ptr ~all|
The resulting DNS should look a lot like this:
The WWW is obviously optional and I have no good reason to set it other than I set WWW all the time.
At this point in time, we have covered configuration of DNS. We have our MX record working and a PTR record in place as well. What is missing however, is the reverse DNS lookup.
Microsoft Azure Configuration
If you are like me, and have never connected to Microsoft Azure via PowerShell the first go round is a bit confusing. It gets even more complicated when you deal with the difference between an Azure AD and a Microsoft ID login to Azure. So let’s step through the process.
1. Install Microsoft Azure PowerShell. The easiest way to accomplish this is through the Web Platform Installer. You can use that link to download and install.
2. Login to Microsoft Azure. There are two methods to login. Using Azure AD and Certificate. I thought that launching Azure PowerShell and connecting via the
Add-AzureAccount PowerShell cmdlet would work. It prompts you for credentials and it will failed for me. This is because I had numerous other IE windows opened and logged into the Azure Portal, Office 365 or something else outside this subscription. Additionally, I’ve found that using a Microsoft ID alone isn’t enough. You need to make sure that the user is also an Azure AD Administrator. So I like to login with certificate instead.
To login via certificate do the following:
A. Login to the Azure Portal with your default browser.
B. Launch the Azure PowerShell and type:
This will open your default browser and download a certificate file. You should save this to your local computer.
NOTE: If you have more than a single Azure Subscription, you will want to make sure that before you run the Get-AzurePublishSettingsFile that you switch to the Azure Subscription you want to manage.
C. Import Azure Certificate into PowerShell
D. You can use the Get-AzureSubscription and Select-AzureSubscription to switch between subscriptions. You no longer have any need for a password to get into your Azure Account. Make sure to protect your certificate file.
3. Get your list of Azure Services
Get-AzureService | fl ServiceName
Here you can see I have two services, both of which are virtual machines. One is a DC and the second is a mail server.
4. Verify you see the service you want and run this command:
Set-AzureService –ServiceName "gcmrelay" –Description "Reverse DNS" –ReverseDnsFqdn "mail.golfclubmgmt.net."
In this command, I am specifying the service name, giving it a description and setting the Reverse DNS settings. It is important to note a few things about the Reverse DNS FQDN. It can ONLY be a vanity name (i.e. my domain and not cloudapp.net) if you have a CNAME record pointing to the vanity name. If you recall my DNS settings, mail.golfclubmgmt.net points to gcmrelay.cloudapp.net. Lastly, your Reverse DNS record should have a trailing . in the name. That isn’t a typo above.
5. Test your deployment. After you have given DNS some time to replicate and do it’s thing you can check your PTR/Reverse DNS settings. There are many different MX/PTR lookup tools available however I have to say I prefer the University of MN’s page. It does a great job of checking all sorts of errors in a single request.
That is it. Your e-mail server should pass any PTR/Reverse DNS requirements and you should be safe to send e-mail from Azure.