Rules to Better Exchange Server - 6 Rules
Email is a critical communication tool for businesses and individuals worldwide. However, it’s also a common vector for cyber threats like phishing and spoofing.
Three ways these threats are combatted are Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC).
SPF is an email authentication method designed to prevent spammers from sending emails on behalf of your domain. By creating an SPF record in your Domain Name System (DNS), you can specify which mail servers are authorized to send email from your domain.
- Identify the mail servers that are authorized to send email on behalf of your domain.
- Create an SPF record in the DNS for your domain. The record might look something like:
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all
DKIM provides an encryption key and digital signature that verifies that an email message was not faked or altered.
- Generate a pair of cryptographic keys - one private and one public.
- The private key is kept secure on your mail server.
- The public key is added to the DNS records for your domain.
- When an email is sent, it is signed with the private key.
See Microsoft's documentation for more details on how to set this up in Exchange Online.
DMARC unifies the SPF and DKIM authentication mechanisms into a common framework and allows domain owners to declare how they would like email from that domain to be handled if it fails authentication tests.
- Ensure SPF and DKIM are in place.
- Create a DMARC policy record, which will look something like:
v=DMARC1; p=none; rua=mailto:email@example.com
By implementing these three protocols in Exchange Online, you can significantly enhance the security of your email communications, protect your brand reputation, and increase email deliverability rates.
Some companies will ask you to add their domain to an allow list, to avoid their emails getting marked as spam. Similarly, you might have internal emails that are sent from a 3rd party service, such as a contact form on your website - and to stop these emails getting marked as spam, it can be tempting to add your own domain to an allow list.
This is a bad idea, as it allows emails to bypass your spam filters. This means emails that are spoofing your domain name (or another domain in your allow list) will get through.
If SPF, DKIM and DMARC are set up correctly, there's no need to add domains to an allow list.
To send from a 3rd party, there are many ways to make sure your emails are authorized. For example, for a WordPress website you can use FluentSMTP to send emails through Microsoft 365 (or another SMTP server).
Do you configure redirection from HTTP to https for Outlook Web App (OWA)? To simplify OWA access for your users, you want to configure the Outlook Web App page to automatically redirect users to https. The HTTP redirect procedure in IIS Manager simplifies OWA URL and forces to SSL connection from mail.domain.com to mail.domain.com/owa .
- Start IIS Manager.
- Expand the local computer, expand Sites, and then click Default website
- At the bottom of the Default website Home pane, click Features View if this option isn't already selected
- In the IIS section, double-click HTTP Redirect
- Select the Redirect requests to this destination check box
- Type the absolute path of the /owa virtual directory. For example, type mail.domain.com/owa
- Under Redirect Behavior , select the Only redirect requests to content in this directory (not subdirectories) check box
- In the Status code list, click Found (302)
- In the Actions pane, click Apply
- Click Default website
- In the Default website Home pane, double-click SSL Settings
- In SSL Settings, clear Require SSL
- Open a Command Prompt window.
- Navigate to:
- Run the following commands:
appcmd set config "Default Web Site/autodiscover" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/ecp" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/ews" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/owa" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/oab" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/powershell" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/rpc" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/rpcwithcert" /section:httpredirect /enabled:false -commit:apphost appcmd set config "Default Web Site/Microsoft-Server-ActiveSync" /section:httpredirect /enabled:false -commit:apphost
- Finish by running the command:
- Open Internet Explorer and type in mail.domain.com
- Done - You are then redirected to mail.domain.com/owa
If email is the property of the employer, then it makes sense to monitor the health of your emails and email server.
If you are using Exchange Online as your mail server, you can see a whole dashboard of your current email situation at Office 365 Security & Compliance, including:
- Mail Flow Map - Where are your emails coming from and going to
- Outbound and inbound email count
- Alerts - Is anything wrong happening with my emails?
- Queues - Are any emails pending on a queue (not being delivered)?
Always keep on top of your email health!
Microsoft 365 groups - When anyone sends an email to a Microsoft 365 group (Office365 groups) e.g: SysAdmins@Northwind.com they don’t receive a copy of their own email, which is different from normal distribution groups.
To change the behavior the user can use the checkbox Outlook | Settings | Additional Settings | Groups | ‘Send me a copy of the email I send to a group’.
Note: This can be enabled on the server side by doing a PowerShell script. This feature is turned on by default. Users can turn it off manually using the above steps to not receive a copy of a email sent to a Microsoft 365 group.
# Connect to Exchange Online Connect-ExchangeOnline -UserPrincipalName firstname.lastname@example.org # Get the mailbox message configuration for a specific mailbox Get-Mailbox email@example.com | Get-MailboxMessageConfiguration | Select EchoGroupMessageBackToSubscribedSender # Enable the option to send a copy of the sent message to the sender's mailbox $mailbox = Get-Mailbox -Identity "firstname.lastname@example.org" | Set-MailboxMessageConfiguration -EchoGroupMessageBackToSubscribedSender $true
It is not a good idea to have Windows Update automatically updating your servers. There are a few reasons.
- The hotfix could bring down a production environment. (This issue previously happened)
- In fact, even in a development environment, this could be hours of lost work as the development team struggles to understand why only some of the developers' servers magically and mysteriously broke overnight.
- Windows Update could restart your server, or put your server in a state where it requires restarting - preventing any urgent MSI installs without bringing down the server.
Windows Update remains the best thing for end-users to protect their systems. But in a server, especially a production server environment - Windows Update patches are just like any new versions of the software that's built internally. It should be tested and then deployed in a controlled manner.
So recommendations for managing updates are as follows:
- Use WSUS to approve/deny updates for your servers.
- Update Staging/Development servers first to see if any issues arise from the updates.
- Roll these updates out to Production once confident there are no issues.
- Windows Updates may be critical and should be kept relatively up to date.
- Do all of this on a schedule - have an email sent to your SysAdmins to remind them to review and reboot needed machines:
- Do you enable automatic Windows Update Installations? [for PCs]
- Do you use Group Policy to manage your Windows Update Policy? [for both PCs and Servers]
The default message size limit in Exchange Online is 25MB. Even though email attachments are not the best way to share a large file, sometimes it is the only option - and these days, 25MB is quite small. This default limit should be increased; it is easy to do so from the Exchange admin center or Exchange Management Shell.
It is important to remember that the maximum email attachment size will also depend on the person receiving the email - their email service will need to accept the larger size. For example, Gmail's default limit is also 25MB.
- Go to Exchange admin center | Recipients | Mailboxes | Set default message size restrictions
- Enter the maximum size you would like to set in KB for both sending and receiving, and click Save. We have it set to 35MB (35,840KB).
Note that this will only apply to new mailboxes. To change the restrictions for existing mailboxes, from the same page you can select one, several or all existing mailboxes, and click Message size restrictions. As above, enter the desired maximums and click Save.
Of course, this can also be done with the Exchange Management Shell, for example:
Set-Mailbox -Identity "Adam Cogan" -MaxSendSize 35mb -MaxReceiveSize 35mb