Welcome to Microsoft 365 Mail Flow Basics. In this lesson, we're just going to touch on some key terms and concepts that you should be familiar with before diving into mail flow architectures. Domain names like bluewidgetcorp.com are used by Microsoft 365 to route email messages. When you first set up email services in Microsoft 365, one of the first steps you usually complete is the setup of your email domain. More specifically, you change your default on microsoft.com domain that comes with Microsoft 365 to your actual email domain. For example, you change your domain name from bluewidgetcorp.microsoft.com to bluewidgetcorp.com. Now, domain names are managed by domain registrars like GoDaddy or HostGator. Name resolution for domains is handled by DNS or the domain name system, which maps human readable host names to the underlying IP addresses for the hardware hosting those domains. When it comes to email routing, there are a few DNS pieces that you need to be familiar with.

Some of those DNS components facilitate email authentication and some facilitate email delivery. These include MX records, SPF Records, DKIM and DMARC. Over the next few minutes, we'll define each of these. So, let's start with MX records. MX records are used to tell mail servers where to send mail. So, for example, if you want all mail for bluewidgetcorp.com to be delivered to Microsoft 365, you'd have to configure the MX record for bluewidgetcorp.com, so that it points to Microsoft 365. The way you do this depends on the registrar that's hosting DNS for the domain, but it's usually done via the registrar's DNS control panel. It's no surprise that Microsoft recommends that all organizations point their MX records to Microsoft 365, so that they can leverage Microsoft 365 spam protection. That said, there's lots of legit reasons for pointing your Mx record to somewhere other than Microsoft 365. For example, you might want inbound emails to your domain to maybe first be delivered to a third-party archiving solution or to a third-party spam filter. Obviously, your business requirements will determine where your MX record should point.

Now, let's talk a little bit about sender policy framework records, which are usually referred to as SPF records. An SPF record is a DNS record that helps facilitate secure email delivery. It's a specially formatted text record that's used to verify that email sent from another email domain are being sent only by the organization that owns that domain. In other words, what an SPF record does is ensure that someone isn't Impersonating another organization through spoofing. To use an SPF record, the email domain owner specifies the list of IP addresses or subnets that are authorized to send email on its behalf within the SPF record itself. This allows the organization to send email from multiple servers or services that have different IP addresses. It's important to note that you can only use one SPF record per domain. If you create multiple SPF records for an email domain, you'll start seeing mail flow problems. I should also mention that while an SPF record is optional, most email servers nowadays will attempt to check a sending domain's SPF record before accepting any email from it.

This means that if you don't have a valid SPF record setup, you may have problems delivering emails to many other domains. DKIM, which is an acronym for DomainKeys Identified Mail, is used to attach a digital signature to the message header of emails that are sent. The receiving email system uses the digital signature to determine if the incoming email is legit or not. Used in parallel with SPF and DMARC, DKIM helps prevent hackers from sending emails that look like they came from your domain. The way DKIM works is pretty straightforward. It uses a private key to encrypt the header into domain's outgoing email. The public key, which is published in the sending domain's DNS records, is used by the receiving systems to decode the signature, which in turn allows the receiving systems to confirm that the incoming mail is really coming from your domain and not someone who is spoofing your domain. And then the last term I want to touch on before we wrap up this lesson is DMARC, which is another acronym. DMARC stands for Domain-based Message Authentication, Reporting and Conformance.

It's a DNS record that's used to help a receiving mail systems determine what they should do with messages that fail SPF or DKIM checks. For example, if the DMARC policy of ascending server is set to p=reject, Exchange Online Protection, or EOP, for the receiving party will mark emails from that sending server as "spoofed" instead of rejecting it outright. Microsoft 365 is configured like this because some legitimate email may fail DMARC and outright rejecting these DMARC failures could cause legit emails to not be delivered. I should point out that these emails that get tagged as "spoofed" can still be retrieved by the recipients if necessary by adding the senders as safe senders individually via their email client. Admins can also use spoof intelligence insights and Tenant Allow/Block List to allow these kinds of emails from the "spoofed" sender. They can also create Exchange transport rules for all users that allow emails for these particular senders. You don't have to do a thing to set up DMARC for mail that you receive in Microsoft 365, it's all taken care of automatically by Microsoft 365.

Likewise, if you're using Microsoft 365 to send email without a custom domain, meaning you're using the on microsoft.com domain name, SPF is already set up for you because Microsoft 365 automatically generates a DKIM signature for your outgoing mail. However, if you have a custom domain or you're using on-prem Exchange servers along with Microsoft 365, you'll need to manually set up DMARC for your outbound mail. To read more about using DMARC with Microsoft 365, visit the URL that you see on your screen. So, now that we've covered the main players; being MX records, SPF records, DKIM and DMARC, let's start taking a look at specific mail flow scenarios in Microsoft 365.