Microsoft has implemented DKIM, DMARC and SPF in Exchange Online, the only thing you have to do is enable it. The only thing for DKIM you have to do is create two CNAME records in DNS and enable DKIM in the Exchange Admin Center.
DKIM CNAME records
The CNAME records you have to create for DKIM look like this:
Selector1 and selector 2 are the 2 selector tags (in Office 365 these will always be selector1 and selector2), the _domainkey is a default tag that will be added. Of course you have to replace the contoso.com with your own domain.
The CNAME records have to point to the following locations:
Continue reading DKIM in Office 365
Autodiscover can be a lengthy process, especially if you are in a hosted environment or if your mailbox is in Office 365.
The autodiscover process consists of five different steps, it depends on your environment where autodiscover stops and returns the information. Autodiscover is using the following mechanisms:
- Service Connection Point (SCP) in Active Directory. This is used by domain clients.
- Root domain discovery, used by non domain joined clients or clients not being able to access Active Directory. All other steps are used by these clients as well.
- Autodiscover.contoso.com (standard autodiscover mechanism)
- Autodiscover redirect to autodiscover site (often used by hosting companies)
- Autodiscover SRV records in DNS (sometimes used by hosting companies)
- Autodiscover redirect to Office 365 (outlook.com)
If your mailbox is in Office 365, outlook will go through all these steps until it finds the information in Office 365. All steps will fail with the accompanying time-out and this will take quite some time. This can be seen in the Outlook Test Email AutoConfiguration option:
Continue reading Improve autodiscover performance
This blogpost is more a note to self, but sigh, I hate it when it does this…. show the 412 Cookies are Disabled error message when trying to open the Exchange Admin Center (EAC) in Exchange Online:
I’m not sure if this issue shows up every time, but at least it shows up when you want to configure an Exchange Hybrid Configuration and you select Hybrid in the On-Premises EAC and select Sign In to Office 365.
To solve this, select the Tools menu in Internet Explorer, select Internet Options and click the Privacy tab.
Lower the slider just one click to Low and click Apply or OK.
Now when you refresh the page in Internet Explorer it should continue with the Hybrid Configuration page:
In the previous two blog posts I have discussed SPF and DKIM as a way of validating the authenticity of email messages. SPF is using an SPF record in public DNS where all legitimate outbound SMTP servers for a domain are listed. A receiving SMTP server can check this DNS record to make sure the sending mail server is allowed to send email messages on behalf of the user or his organization.
DKIM is about signing and verifying header information in email messages. A sending mail server can digitally sign messages, using a private key that’s only available to the sending mail server. The receiving mail server checks the public key in DNS to verify the signed information in the email message. Since the private key is only available to the sending organization’s mail servers, the receiving mail server knows that it’s a legitimate mail server, and thus a legitimate email message.
As a reminder, my test environment is configured as follows:
There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes, and there’s an Exchange 2016 CU2 Edge Transport server. Using Edge Synchronization all inbound and outbound SMTP traffic is handled by the Edge Transport server.
In the previous two blog posts an SPF record was created and implemented, and DKIM including a DKIM signing module on the Edge Transport server was implemented and functioning correctly.
This last blog in a series of three discusses DMARC, which is built on top of SPF and DKIM. Continue reading SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III
In the previous blogpost I have been discussing how SPF works and how it uses public DNS to validate the authenticity of the sending SMTP servers. When SPF is implemented correctly a receiving mail server can validate is the sending mail server is allowed to send email on behalf of the sender or his organization.
In this blogpost I will discuss DKIM signing as an additional (and more complicated, and more difficult to spoof) step in email validation.
As a quick reminder, here’s how my lab environment looks like:
There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes, and there’s an Exchange 2016 CU2 Edge Transport server. An Edge synchronization will make sure that all inbound and outbound SMTP traffic is handled by the Edge Transport server.
In my previous blogpost an SPF record was created and implemented with the following value:
v=spf1 a:smtphost.exchangelabs.nl ~all
so receiving mail servers can validate that my Edge Transport server is allowed to send email on my behalf, and when mail is originating from another mail server it might well be a spoofed message.
But for now let’s continue with DKIM. Continue reading SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II