As an O365/M365 Administrator you can occasionally make a mistake. It may not seem apparent but later down the line it can cause you problems. Or maybe there is a setting within the Microsoft environment that is enabled / disabled by default that should be changed, you just need to know about it. Whether it is either of these situations knowing the 5 Things you should not do with M365 Admin will help you out in the long run.

Do Not Use the Global Admin Account

Don’t make every user who performs some form of Admin in your tenant a Global Administrator.  There are several types of Admins and using the principle of least privilege you only need to give enough access required for the user to perform their job.

Not Having a Backup Admin Account With no MFA

In the unfortunate incident of your Global Administrator account being compromised it is good to have a backup Administrator account. If you do not it will take Microsoft a long time to get your access to your Tenant again. This way you can get back in and disable the Global Admin account and mitigate any damaged that might have been caused. Do this by creating another Global Administrator Account. Do not call it Admin!! Call it something else. Make the password long and complicated and DO NOT enable MFA. Doing so would just complicate things. Store the information for this account offline (like in a safe). The technical term for this type of an account is a “break glass account”.

Having a Second Domain With no DNS TXT Record

So, you decide to add a second domain to your tenant. Great. To do so you need to add a DNS TXT record to your Domain registration records to prove you own this domain through the add domain wizard in the Admin portal. You are successful. You may be tempted to delete the domain TXT record afterwards but DON’T. If you do you have set your self up for a possible DNS Poisoning attack. Leave it.

Not Understanding Shared Mailbox Behavior

This falls under a mistake that is not apparent until later. Creating a shared mailbox is easy. You go under the shared mail tab in O365 Admin and create a shared mailbox. Then you add users to the mailbox. If you want to be more granular you can also administer it through the Exchange Admin Center in your portal. The problem exists when you take a standard mailbox (single user) and convert it to shared. This is usually done when a user leaves the organization and other users need to access their mail. You may be doing a user audit some months later and decide that this user can be deleted.

If you forget that this user is a shared mailbox, and the delegates still need access to it they will lose the mailbox!! A better way to do this is block the defunct user account sign in. You can also report on blocked users and see which ones have a shared mailbox. Find out who the delegates are and see if the still need access. If they don’t, you can at least delete the account safe in the knowledge you won’t be cutting of anyone’s mailbox access.

Not Understanding Guest User Access

Giving users guest access to your organization I fine but O365 has guest access setup by default:

This is a most inclusive / least restrictive access for guest in your tenant. You may not want this type of access granted to your guests. Adjust to whatever makes yur organization compfortable.

Making sure the 5 Things you should not do with M365 Admin are addressed will ensure that your have not only security hardened your environment, you will have spared yourself some unexpected surprises along the way!

Happy IT’ing

Dan

You have made some changes to your SPF record in DNS (or not) and your SPF record is broken. One day resources that depend on it in your organization stop working? What happened? There are generally two ways this record can become problematic but first, What is an SPF record anyways…..

An SPF Record is a TXT DNS Entry

For those of you familiar with DNS it is just one of many types of DNS entries you put in your records for your domain. For example, an “A’ record is for hosts and “MX” is for mail exchangers, etc. SPF stands for “Sender Policy Framework”. It allows other domains to send on behalf of your domain without being marked as spam. You see, way back when the Internet was on the honor system (LOL), people wouldn’t dare spoof other domains when sending email. That would be wrong as it is spamming. That was sarcasm.  If you have services that use other domains to send on behalf of your domain, a broken SPF record will likely cause an NDR of the email being sent by a non-trusted domain. Microsoft has a great explanation in the NDR on how to fix such errors.

Format of an SPF record

In its simplest form it is this:

v=spf1 include:spf.protection.outlook.com ~all

This would be in the case that you use M365 as you email provider but obviously it would vary depending on your email service. A great explanation on how to build your SPF record is located here.

Here are the 2 ways this error might occur.

The Statement in the SPF record was formatted wrong

This record is quite finicky. If you do so much as add an extra space or misplace a tilde your email service will throw errors. If you are unsure, use a service like MXTool Box to generate the SPF record for you. That way all you must do is copy and paste the info into a new or already existing TXT record in your company’s DNS. Save and test!

One of the Resources Specified in the SPF record no Longer Exists

This is more likely if one of the services that send on behalf of your domain no longer exists or stops functioning. One day it works and the next day it doesn’t. It is likely on of the IP Address for server that specifically send on your behalf or one of the domains you specified in your include statements no longer exist or is not functioning. Find out from the company that provides you with this service what the new information is so you can replace it in the SPF record or if you need to remove it from the record. Either way, until it is fixed the record will stop working and your email flow will be adversely affected. If you need to gather some information before you reach out user an online SPF analyzer. It will tell you where the breakdown in the record has occurred.

These two issues when resolved will get your mail flowing again for the service that depends on it. That is all we really want, right, to the mail keep flowing!

Happy IT’ing

Dan