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
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
In my previous blog post I explained how to manage your Email attributes in Office 365 by directly editing the Exchange attributes in your on-premises Active Directory. This works fine, but it is not recommended nor is it supported by Microsoft.
In this blogpost I’ll discuss how to add an Exchange server on-premises (or keep the last Exchange server when you’ve moved all Mailboxes to Office 365 for that matter) and manage your Exchange Online environment properly.
Exchange Server on-premises
So, what options do you have? Add an Exchange server on-premises, or keep one of the existing (hybrid) Exchange servers for management purposes. Since this is a green field Active Directory, and there’s no Exchange server on-premises you can use the free Microsoft Hybrid License to for this management server. For additional details on this free Exchange license you can check the Microsoft knowledgebase article KB2939261: https://support.microsoft.com/en-us/kb/2939261.
Continue reading Office 365 Directory Synchronization without Exchange server Part III
When you want to change an email address on a Mailbox in Office 365 you get the following error message:
The operation on mailbox “<mailbox>” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’, ‘EmailAddresses’, can’t be performed on the object ‘Stacey Brown’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
This issue is caused by the fact you’re synchronizing user objects from a local Active Directory using DirSync or WAADSync, and you want to change properties in Office 365. This is not possible since the Source of Authority is your local Active Directory, and not Windows Azure Active Directory. This means you have to change all the user’s properties in Active Directory, including his email address.
Continue reading The operation on mailbox failed because it’s out of the current user’s write scope