Protecting Your Email Infrastructure with DMARC for Office 365
Domain owners implement DMARC to prevent email spoofing and phishing by instructing recipients’ mail servers on what actions to take against emails that are sent from your domain but don’t pass the DMARC authentication test.
DMARC authentication is based on SPF and DKIM results. So, if an email fails SPF and/or DKIM checks, the DMARC record tells if it should get placed in the spam folder or rejected. In the initial phase of DMARC implementation, you can also set your record to monitoring, which means no action will be taken against illegitimate messages dispatched from your domain.
DMARC ensures the destination mailboxes trust messages sent on your organization’s behalf and don’t highlight them as suspicious, which could otherwise lead to email deliverability issues and degradation of domain quality.
How SPF and DKIM Protect Email Spoofing and Phishing in Microsoft Office 365?
An email can have multiple originator or sender addresses that serve various purposes. Here’s what is included-
Image sourced from admindroid.com
‘Mail From’ Address
This address locates the sender and indicates where to send notices for non-delivery. The Mail From address is in the email’s envelope (not shown in your email app) and is also called the 5321. Mail From or reverse-path address.
‘From’ Address
This is the address displayed in your email app as the sender. It shows who wrote the email and the person or system responsible for it. The From address is sometimes called the 5322. From address.
An SPF TXT record helps confirm if a specific IP address is authorized to send emails for a given domain. Generally, SPF checks are conducted against the 5321.MailFrom address. However, hackers can spoof the 5322. From sender address and pass the authentication checks.
Setting DMARC for Outbound Mails from Microsoft 365
Users hooked with Microsoft 365 but not using a custom domain don’t have to worry about SPF as it’s already set for you. In this case, Microsoft 365 will autonomously develop a DKIM signature for your outgoing email.
To start with your custom domain’s DMARC journey, you need to create a DMARC record for the onmicrosoft.com domain and update it to the DNS using the Office 365 Admin Center.
Here’s what you need to do-
Go to ‘settings’ and choose ‘domains.’ then click on onmicrosoft.com domain and add the record.
However, if you are a custom domain or on-premises Exchange server user, the job of creating a DMARC record has to be done by following these steps-
Step 1: Enlist All Valid Senders for your Domain
Start by gathering all the IP addresses and mail servers that officially belong to your company’s employees, CXOs, and departments.
If you have outsourced some tasks to an outside agency that also has to send emails to complete the processes, then add their sending sources to the list. It’s suggested to include only specific email addresses they will use to send emails instead of allowing their domain-wide senders. This mistake will jeopardize your cybersecurity.
Step 2: Set Up SPF for your Domain
Now that all the internal and external sending sources are collected in a single file use an online SPF record generator to set the SPF protocol. Make sure you follow the best practices like-
- Using the ‘include’ tag to add external sending sources.
- Avoiding +all or ?all tags.
- Using SPF type as TXT.
- Beginning with v=spf1.
- Creating only one consolidated SPF record for a single domain.
Step 3: Set Up DKIM for Custom Domains
After SPF, set DKIM to verify the authenticities of senders’ dispatching messages from your domain. DKIM is based on the concept of matching public and private keys corresponding to your domain.
It’s suggested to set your own DKIM settings instead of letting Microsoft use its default configurations; otherwise, DMARC might not work properly. This happens because the default DKIM signature will take into consideration the original onmicrosoft.com domain as the 5321.MailFrom address and not your custom domain. This mix-up will create issues.
If third-party senders have different 5321.MailFrom and 5322.From addresses, DMARC authentication would fail. Chances of these mishaps can be eliminated by setting up DKIM with third-party senders. It also lets other email services, like Yahoo and Gmail, know that those emails are really from you. This is good because it helps people trust your emails, no matter where they check their mail. Plus, Microsoft 365 won’t mark your emails as spam.
Step 4: Generate a DMARC Record for Your Domain
You can use an online DMARC record generator to create something like this-
_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100"
Where,
- Domain is the domain for which you are creating the DMARC record.
- TTL should always be equivalent to an hour. So, it’s always either hours (1 hour), minutes (60 minutes), or seconds (3600 seconds). This choice varies based on the domain registrar.
- pct=100 indicates the percentage of deployment of the DMARC policy.
- Policy indicates the DMARC policy you used. You can set your record to none, quarantine, or reject.
Step 5: Update and Monitor
Once your DMARC record is generated, update it to your domain’s DNS so that recipients’ servers can retrieve and refer them to process the authentication.
What’s the Final Take?
When you set a DMARC reject policy (p=reject), it stops others in Microsoft 365 from faking your domain because their messages won’t pass SPF or DKIM for your domain when they send emails through the service. However, if you have a DMARC reject policy, but not all your emails are verified through Microsoft 365, some may be marked as spam for incoming emails (as explained earlier).
Alternatively, they might get rejected if you don’t include all the necessary IP addresses for servers and apps sending emails on behalf of your domain when setting up your DMARC TXT record.
