Tag Archives: DNS

SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I

August 19, 2016 jaapwesselius 4 Comments

SenderID has been used in Exchange as a means for anti-spam for quite some time, as far as I can remember this was first used in Exchange 2010. Related to SenderID is SPF (Sender Policy Framework). SPF looks like SenderID functionality, but it differs in the way how it checks email messages.

Both use public DNS records with TXT records where information is stored regarding the sending SMTP server, and this information is used by the receiving (Exchange) server to validate if the sending server is allowed to send email on behalf of the sender.

Getting more popular for fighting spam are DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance). Just like SenderID and SPF, these solutions use public DNS for additional information as well, but since encryption is used most Exchange admin have some doubts about the complexity of DKIM and DMARC.

In the upcoming blogpost I’ll discuss SPF, DKIM and DMARC as implemented in my lab environment which looks like this:

There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes. The server is accessible via webmail.exchangelabs.nl and autodiscover.exchangelabs.nl (same IP address, behind a Kemp LM3600 load balancer) and configured with a Digicert UC certificate.

In addition to this there’s an Exchange 2016 CU2 Edge Transport server with FQDN smtphost.exchangelabs.nl. Besides the regular A and MX record, the IP address is also configured in Reverse DNS. The Edge Transport server is also behind a Kemp LM3600 load balancer, and it has a Digicert SSL Certificate with the same domain name. There’s an Edge Synchronization configured between the Mailbox server and the Edge Transport server, and all inbound and outbound mail is handled by the Edge Transport server. Continue reading SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I →

Exchange, Office365

Change SMTP mail flow in hybrid scenario

November 24, 2015 jaapwesselius 5 Comments

After building a hybrid Exchange environment as outlined in a couple of previous blog posts we have an Exchange 2013/2016 environment where some Mailboxes exist on-premises and some Mailboxes exist in Exchange Online. Autodiscover is still pointing to the on-premises environment, and so are the MX records. Inbound SMTP mail flow from the Internet is still accessing the on-premises Exchange 2016 Edge Transport servers before being delivered to the intended recipients.

Figure 1. The Exchange hybrid environment with Mailboxes on-premises and in Exchange online.

Continue reading Change SMTP mail flow in hybrid scenario →

Office365

Manage Domains in Office 365 step-by-step

April 30, 2015 jaapwesselius 4 Comments

In a previous blog post I explained how to create a new organization (tenant) in Office 365. After the initial creation there’s one (administrative) account and you can start working with that account almost immediately. For example, when you logon to https://outlook.office365.com/owa and use the credentials you entered when creating the new tenant you logon to OWA and you can start sending email, there’s not much to see though at this point 🙂

When you send an email your email address will be admin@inframan.onmicrosoft.com, not nice but it works. Continue reading Manage Domains in Office 365 step-by-step →

Uncategorized

Lync Phone Support and PIN login

February 20, 2012 jaapwesselius Leave a comment

When using a Lync server infrastructure it is possible to use Lync Phones without connecting them to a PC using the USB cable. Devices like the Polycom CX500, CX3000, Snom UC600 or Aastra 6725ip are just a few examples. Since these clients are not connected to the PC they have to get their configuration information somewhere else.

This information is retrieved by the clients using DHCP. In DHCP the following options are used:

001 UCIdentifier;
002 URLScheme;
003 WebServerFqdn;
004 WebServerPort;
005 CertProvRelPath;
120 UCSipServer;
042 NTP Server (Optional);

While it is possible to configure these options manually there’s a tool in Lync that will retrieve the appropriate information and configure DHCP for you!

Continue reading Lync Phone Support and PIN login →

Exchange

Autodiscover Redirect & SRV Record

August 28, 2011 jaapwesselius 5 Comments

When you have multiple primary SMTP domains in your Exchange 2010 environment you have to come up with a solution for autodiscover. Suppose we have an Exchange 2010 environment called exchange14.nl. The external URL would be something like webmail.exchange14.nl and the autodiscover FQDN would be autodiscover.exchange14.nl. In this you would need a UC certificate with both these names in it.

When there’s another (primary) SMTP domain in use in this Exchange 2010 environment we have to come up with something for the corresponding autodiscover record. When the SMTP domain called inframan.nl is also hosted in this environment, Outlook would look for a DNS record autodiscover.inframan.nl when Active Directory is not available, like on the Internet. Since this FQDN is not available in the SAN field of the certificate this would generate a client side certificate error, like “The name of the security certificate is invalid or does not match the name of the site.”

To avoid this there are two options that let Outlook redirect its autodiscover traffic. The first option is to use an HTTP redirection method; the second option is to use SRV records in the public DNS.

HTTP Redirection

When Outlook cannot find its corresponding autodiscover record, like autodiscover.inframan.nl in this example, Outlook will start looking for a redirection option. You can create an additional website in the Client Access Server that listens on port 80, intercepts redirection traffic and sends it to the original autodiscover URL. This 2^nd website has an additional FQDN, using an additional IP address. For example, for autodiscover.exchange14.nl and webmail.exchange14.nl the IP address 178.251.192.9 is used. The 2^nd website will be autodiscoverredirect.exchange14.nl and its IP address will be 178.251.192.12. Do not forget to add this FQDN and IP address to the public DNS!

On the Client Access Server open the Internet Information Server (IIS) Manager and create an additional website called autodiscoverredirect. Use a physical directory like c:\inetpub\autodiscoverredirect for this website and bind the website to the additional IP address.

In this website create a new Virtual Directory called autodiscover. Use Autodiscover for the alias and use a physical directory like c:\inetpub\autodiscoverredirect\autodiscover for this Virtual Directory.

Open the properties of the new Vdir and configure HTTP Redirect. Select the Redirect requests to this destination and enter https://autodiscover.exchange14.nl/autodiscover as the destination of the redirect.

The last step is to configure external DNS. Create a DNS entry for autodiscover.inframan.nl, but instead of assigning it an IP address create a CNAME record and point it to autodiscoverredirect.exchange14.nl

When testing with the Remote Connectivity Analyzer (http://www.testexchangeconnectivity.com) with a username called John Doe (john@inframan.nl) you’ll see the the autodiscover request originally destined for autodiscover.inframan.nl is redirected to autodiscover.exchange14.nl and the correct results are returned.

SRV Records in DNS

Instead of using the HTTP redirect option as described earlier it is also possible to use service records (SRV records) in the public DNS to access the autodiscover virtual directory when using another primary SMTP address.

Looking at the test environment there’s still a UC certificate on the Client Access Server with the FQDN’s webmail.exchange14.nl and autodiscover.exchange14.nl.

But instead of using an additional autodiscover entry in the SAN field of the certificate or creating an additional autodiscover redirect website it is also possible to use a service record. In this scenario, a service record in for inframan.nl needs to be created, pointing to the autodiscover FQDN for the original domain. This service record will be _autodiscover._tcp.inframan.nl and it points to autodiscover.exchange14.nl on port 443.

Entering the SRV record in public DNS can be a bit difficult, depending on the hosting provider you are using. In my case it is something like this:

When using NSLOOKUP (on the client) to check the SRV entry you’ll see that it looks good:

Now when checking with the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) you’ll see that the autodiscover redirect options fails, but that the SRV option succeeds:

It is even more interesting, instead of using the autodiscover.exchange14.nl it is now possible to use the webmail.exchange14.nl FQDN in the SRV record. This way autodiscover no longer uses the autodiscover.exchange14.nl entry and it is now possible to use a standard SSL certificate and NOT a Unified Communications certificate. This standard certificate only contains the name webmail.exchange14.nl.

And testing with the Remote Connectivity Analyzer:

More information regarding the SRV option with autodiscover can be found on the Microsoft website: http://support.microsoft.com/kb/940881

Jaap Wesselius