Field Notes: DKIM and missing selector records

Reading Time: 3 minutes

During a project with one of my customers, I was tasked to look at a non-delivery report (NDR) for a mail message. The bounce error was pretty confusing, but after reviewing the headers, we noticed that the DKIM check had failed. This was a bit of a surprise, because the message was sent from Microsoft Exchange Online. The root cause was that the selector mentioned in de header wasn’t resolving. Apparently, Microsoft did not provide the answer to validate the record.

The situation

The organization uses Microsoft Exchange Online and has setup DKIM signing with the accepted domains listed in the tenant. This particular organization owns 70+ domains. For every accepted domain, they have created the required CNAME records. During the validation, roughly 20 domains had a failed active selector entry.

I raised a case with Microsoft Office 365 Support, which confirmed that is was a bug and resolved the issue for my customer. They also informed the product team of this error.

How to setup DKIM

By default Exchange Online signs outgoing message with a DKIM signature. More information can be found here. The validation information recorded in the header points to one of the following records:

  • selector1-[tenantname]-onmicrosoft-com._domainkey.[tenantname].onmicrosoft.com
  • selector2-[tenantname]-onmicrosoft-com._domainkey.[tenantname].onmicrosoft.com

image

To enable DKIM you will also need to setup the following CNAME records in the domain:

  • selector1._domainkey
  • selector2._domainkey

Using Windows PowerShell, you can get the full value to use for these DNS records. You can retrieve the information through the Exchange Online PowerShell module. The recommended administrative permission is Security Admin.

Follow these steps:

  1. Connect to Exchange Online using the Exchange Online Powershell module.
  2. Sign in with your cloud administrator credentials.
  3. Give the following command for all existing domains:
    Get-DkimSigningConfig | FL Identity,Selector1CNAME,Selector2CNAME

    image

  4. Give the following command for one specific domain:
    Get-DkimSigningConfig –identity [domainname]| Format-List Identity,Selector1CNAME,Selector2CNAME

    image

  5. Register the new CNAME records with the Selector[1/2]Cname as value.
  6. After succesfully creating the DNS records, you can activate the DKIM signing configuration. This can be done via the following command:
    Set-DkimSigningConfig –identity [domainname] –Enabled:$true

Note: If the domain is missing, you can create the DkimSigningConfig entry through this powershell command:

New-DkimSigningConfig -KeySize 2048 –DomainName [domainname] –Enabled:$false

Only one selector returns data

With the initial creation of your DKIM configuration, Microsoft populates both selectors in their DNS. After a while, though, only the active selector will be resolvable and the other selector is not. This is by Microsoft's design. The record should be visible again when the key rotates.

How to validate the existing records

The challenge for my customer was to validate the records for all 70+ domains. We can do this manually, but where it the fun in that!? We decided to do it through PowerShell.

The below Windows PowerShell script requires an active session to Exchange Online through PowerShell. The recommended administrative permissions is Security Admin.

We ran the following script:

$domains = Get-DkimSigningConfig |Where-Object {$_.Enabled -like "True"}
$Datenow = Get-date
$FailedLookupslog = "C:\Temp\FailedDKIMrecords.log"
$CheckDNS = @()
$failed = @()


ForEach($domain in $domains){

    $activeSelector1 = $domain.SelectorBeforeRotateOnDate
    $activeSelector2 = $domain.SelectorAfterRotateOnDate


    If($($domain.RotateOnDate.ToUniversalTime()) -gt $($datenow.ToUniversalTime()) ){
         $tempattribute = "$($activeSelector1)Cname"
         $CheckDNS += $domain."$tempattribute"
     }
     else{
         $tempattribute = "$($activeSelector2)Cname"
         $CheckDNS += $domain."$tempattribute"
     }
}


foreach($entry in $CheckDNS){
     $works = Resolve-DnsName -Name $entry -Type txt -erroraction 'silentlycontinue'


     If($works){}
     else{
         Write-host "$entry is not working" -ForegroundColor yellow
         $Failed += $entry
     }

     $works = ""
}

"Domain: , selector:" | Out-File -FilePath $FailedLookupslog

Foreach($fail in $failed){

    if($fail -like "selector1*"){
         $temp = $domains | where{$_.selector1Cname -like $fail}
     }
     else{
    $temp = $domains | where{$_.selector2Cname -like $fail}

   }
    "$($temp.Domain) , $fail" | Out-File -FilePath $FailedLookupslog -Append

}

The failed active selector entries were listed in the logfile.

Concluding

Organizations that enable the DKIM feature rely on Microsoft to maintain the information and keep it up-to-date.  As a consumer of this feature you need to trust, but verify that it’s still works as designed.

By using the script in the blog, you can automate, verify and let it report to your ticketing system for review and follow-up actions.

Security Officer: Please block the iOS native mail app (for) now!

Reading Time: 5 minutesLast week an announcement was made: The native mail app in Apple's iOS has zero-day vulnerabilities, deemed critical. No patch is available at this time.

More information about the vulnerability can be found here.

For you as IT admin this means that you probably have work to do. The main questions you may be facing from management or your security officer are:

  1. How many people use the native mail app in our organization?
  2. Can you block access to people using the native mail app?

I'll answer these two questions in this blog post, for the on-premises environment and for Office 365.

How many people use the native iOS mail app?

To gain insights into the current usage of the native mail app, we need to use Windows PowerShell.

Note:
Although the official support for Exchange Server 2010 ends October 2020, I 'm also adding the commands for Exchange Server 2010 to this blogpost. Organizations are (unfortunately) still using it.

To execute the commands you will need to be connected through the Exchange Management Shell. This applies to all versions of Exchange. The minimum permissions needed are Recipient Administrator.

Query Microsoft Exchange Server 2010

For Micrososft Exchange Server 2010, we need the Get-ActiveSyncDevice and Get-ActiveSyncDeviceStatistics Windows PowerShell cmdlets.

Use the below lines of Windows PowerShell to query Microsoft Exchange Server 2010 for usage of the native iOS mail app:

$AlliOSDevices = Get-ActiveSyncDevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-ActiveSyncDeviceStatistics -Identity $_.Identity} | Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesResult.csv -Delimiter ","

$QueryResults | Out-GridView

image

Note: the warning shown in the example, is caused by the fact that for Microsoft Exchange Server 2013 and higher a different command is recommended. See Query Microsoft Exchange Server 2013 or Later for more information.

The results are now available on the C:\temp folder on the server. Load the results in Microsoft Excel and the last successful synchronization is shown on top.

Query Microsoft Exchange Server 2013, or later, and Microsoft Exchange Online

For Microsoft Exchange Server 2013, newer versions of Microsoft Exchange Server and for Microsoft Exchange Online (part of Microsoft Office 365 and Microsoft 365), we need the Get-MobileDevice and Get-MobileDeviceStatistics Windows PowerShell Cmdlets.

Use the below lines of Windows PowerShell to query Microsoft Exchange Server 2013, and later, for usage of the native iOS mail app:

$AlliOSDevices = Get-MobileDevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-MobileDeviceStatistics -Identity $_.Identity} | Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesResult.csv -Delimiter ","

$QueryResults | Out-GridView

image

The results are now available on the C:\temp folder on the server. Load the results in Microsoft Excel and the last successful synchronization is shown on top.

How to block the iOS native mail app

Using the previous scripts, we known who is using the native iOS mail app. The service desk and/or security officer can use direct communications to these employees. Their message should be that use of the native mail app is (about to be) disabled. The employees should configure the Microsoft Outlook app for iOS to regain access to e-mail on their mobile devices.

Block Access

To create the block rules for iPad and iOS, we are using Windows PowerShell with an active management connection to the Microsoft Exchange Server Environment. We recommend to be be logged in as Organization Administrator of the Exchange Server environment.

In Exchange Online you'll need to have the Exchange Administrator role. The Windows PowerShell cmdlet that we are going to use is New-ActiveSyncDeviceAccessRule.

To block access for iPad and iPhones, please use the following lines of Windows PowerShell:

New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "iPhone" -AccessLevel Block

New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "iPad" -AccessLevel Block

image

Remove block rule

To rollback or remove the rules, you can use the following lines of Windows PowerShell from the Exchange Management connection. The Windows PowerShell cmdlet we are going to use is: Remove-ActiveSyncDeviceAccessRule.

Remove-ActiveSyncDeviceAccessRule "iPhone (DeviceType)" -confirm:$false

Remove-ActiveSyncDeviceAccessRule "iPad (DeviceType)" -confirm:$false

image

Is it working?

After applying the policy, it is a recommended practice to review mobile devices. In the past, a device may be manually allowed and will continue to function after activating the block rules.

To gain insight in the block status and the excluded devices, we are going to use the same Windows PowerShell cmdlets as before. This time, we're adding an additional where filter: We are going to filter out the ‘DeviceAccessStateReason’ with the global value. These devices will be automatically blocked. Below, I'll show the example for Microsoft Exchange Server 2010 and for Microsoft Exchange Server 2013 and later.

Is it working on Microsoft Exchange Server 2010?

Use the following lines of Windows PowerShell to figure out if the block rule is working on Microsoft Exchange Server 2010:

$AlliOSDevices = Get-Activesyncdevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-ActivesyncDeviceStatistics -Identity $_.Identity} | where {$_.DeviceAccessStateReason -ne "Global" }| Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesBlockedAllowed.csv -Delimiter ","

$QueryResults | Out-GridView

image

Is it working on Microsoft Exchange Server 2013, or later, and Microsoft Exchange Online?

Use the following lines of Windows PowerShell to figure out if the block rule is working on Microsoft Exchange Server 2013, newer versions of Microsoft Exchange Server and for Microsoft Exchange Online (part of Microsoft Office 365 and Microsoft 365), :

$AlliOSDevices = Get-MobileDevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-MobileDeviceStatistics -Identity $_.Identity} |where {$_.DeviceAccessStateReason -ne "Global" }| Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesBlockedAllowed.csv -Delimiter ","

$QueryResults | Out-GridView

image

Concluding

Don't panic when you get difficult questions from management and\or the security officer. The answer is Yes, thanks to Windows PowerShell.

We can see who is using the native app and we can block access. With a few lines of Windows PowerShell we gain insight and take control.

I hope that the above information is helpful to you in regaining security, until the zero day in the iOS native mail app is fixed.

Valimail Monitor for Office 365: Your Free DMARC Reporting Tool

Reading Time: 3 minutesOn their security blog on the 3rd of June 2019, Microsoft announced that Valimail Monitor for Office 365 is available. This option enables organizations using Exchange Online from Office 365 for their company mail to leverage DMARC.

The Road to securing E-Mail

Cyberattacks are common these days. These attacks can be actively targeting your organization over the internet or through incoming emails.

Reputation of your name and mail on the internet are important these days. Reputation attacks via email are achieved by spoofing; sending e-mail messages on behalf of your domain. To counter this, you can:

  • Enable SPF (Sender Policy Framework) records, and;
  • Enable DKIM (DomainKeys Identified Mail)

This is a common practice. However, after you have enabled this, you don't get any feedback about the attacks or invalid sources. To gain this insight you will need to activate DMARC (Domain-based Message Authentication, Reporting and Conformance). After you’ve enabled DMARC, via a simple DNS TXT record, you will start receiving automated mail messages with an XML file as attachment on the e-mail address listed in the TXT record.

In short: if you want to gain the insight, who is using your domain on the internet, start using DMARC.

Valimail to the rescue!

With Microsoft’s announcement, you get access to Valimail; a free tool to gain these insights.

Stop processing the XML files by hand or scripting tools. We all love (free) automation, right?

Requirements

To gain access to this information, you already need to have setup the following:

    • Existing SPF record containing all the authoritative mail sources
    • Enable DKIM on your mail flow (activated by default in Office 365).
      For outgoing mail, a transport agent can be installed on the on-premises Exchange Server or activated as an option on your anti-spam solution.
    • Activated a basic DMARC record in your DNS domain, for example:
      "v=DMARC1; p=none; rua=mailto:reports@example.com".
      This example shows you’re using DMARC1 and you monitor existing connections. Please report findings to reports@example.com.

How to set it up

Follow these steps to set it up:

  • First go to the following website: https://go.valimail.com/microsoft.html
  • Fill in the required information.
    image
  • Now wait for response from the Office 365 team of Valimail.
    image
  • Update your DNS record with the requested entry and test the record.
    image
  • Wait for your initial invite to create a login account.
    image
  • When the invite is sent, accept the invite and configure a password for your account.
    image

Tip!
Don’t forget to enable 2-factor authentication on your account or configure Azure AD single sign-on as described in Enable Valimail Single Sign-On with Azure Active Directory.

Conclusion

I have discussed DMARC before with customers and it's a valuable option to gain insight who is sending e-mail messages on behalf of your DNS domain. The only problem was, how to translate the XML files.

Yes, other tools are available, but for most, you will need to pay a fee to use.

ValiMail is free for organizations using Office 365, so why not use it? Regain control over your mail domain, today.

Further reading

Below are some articles that explain SPF, DKIM and DMARC in more depth: