Introduction

This post will revolve around increasing your email security/reputation, and using Valimail to monitor this.
The first section will cover the various areas involved in making this more “secure” by leveraging SPF,DKIM and DMARC.
In the second section we will cover the use of Valimail as a tool to monitor your mail flow and status of emails failing SPF/DKIM/DMARC.

Valimail can also be integrated for SSO to Azure AD, and we will cover that as well.
If you are already familiar with the concepts of SPF/DKIM/DMARC – feel free to jump to the Valimail part.
So, lets begin walking through this – its a long one.

Table Of Contents

Introduction
SPF
DKIM
DMARC
Valimail DMARC Monitor for Microsoft 365
Summary
Reference material

SPF

Set up SPF to help prevent spoofing – Office 365 | Microsoft Docs
How Sender Policy Framework (SPF) prevents spoofing – Office 365 | Microsoft Docs

What is SPF?

SPF or Sender Policy Framework is an email authentication protocol that helps to prevent email spoofing and phishing attacks. It allows email systems to check whether the incoming mail from a particular domain is coming from a legitimate source or not. SPF works by allowing domain owners to specify which IP addresses are authorized to send emails on behalf of their domain.

SPF helps validate outbound email sent from your custom domain (is coming from who it says it is).
It’s a first step in setting up the full recommended email authentication methods of SPF, DKIM, and DMARC.

How does SPF work?

When an email is sent, it contains a “From” address that specifies the sender’s email address. However, it is possible for someone to forge the “From” address and make it appear as if the email is coming from a different domain. This is known as email spoofing.

SPF helps to prevent email spoofing by allowing domain owners to publish a list of IP addresses that are authorized to send emails on behalf of their domain. This list is published in the DNS record of the domain. When an email is received, the recipient’s email system checks the SPF record of the sender’s domain to see if the IP address of the sending server is authorized to send emails on behalf of that domain. If it is not authorized, the email can be marked as spam or rejected altogether.

Why is SPF Important?

Email spoofing and phishing attacks are a common tactic used by cybercriminals to trick users into providing sensitive information such as login credentials, credit card numbers, and more. SPF helps to prevent these types of attacks by verifying the sender of an email message. By implementing SPF, domain owners can protect their domain reputation and prevent their domain from being used for malicious purposes.

In addition to SPF, there are other email authentication protocols such as DKIM and DMARC that can be used to further enhance email security. By implementing these protocols, domain owners can provide a more secure email environment for their users.

Implementing SPF for email provides major benefits:

Increases domain reputation and email deliverability.
Fights domain impersonation and email spoofing to protect brand reputation.
One of the foundational methods of email authentication for DMARC.

How SPF works to prevent spoofing and phishing in Microsoft 365

According to Microsoft, SPF is used in combination with other technologies supported by Microsoft 365, such as DKIM and DMARC, to help prevent spoofing and phishing. SPF identifies which mail servers are allowed to send mail on behalf of a domain, and it is added as a TXT record that is used by DNS to identify which mail servers can send mail on behalf of a custom domain. When an email is received, the recipient’s email system checks the SPF record of the sender’s domain to see if the IP address of the sending server is authorized to send emails on behalf of that domain. If it is not authorized, the email can be marked as spam or rejected altogether [1].

In addition to SPF, Microsoft 365 also offers a feature called spoof intelligence, which is enabled by default and is available for Exchange Online Protection and Microsoft Defender for Office 365. Spoof intelligence filters email from senders who are spoofing domains. Whenever spoofing is detected, action is taken based on the anti-phishing policy [2].

Overall, SPF is an important email authentication protocol that helps to prevent email spoofing and phishing attacks, and it works in conjunction with other technologies to provide a more secure email environment in Microsoft 365.

Formating your SPF DNS record

For details on how to form your SPF record for 365, your can reference Microsoft’s documentation here.

An example for a cloud only (no on prem sources sending email, only Microsoft), the record would look like this:
v=spf1 include:spf.protection.outlook.com -all

If you also have a source on prem sending e-mail it may look like this:
v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

It is important for SPF, that you add all your sources for outgoing email, to avoid emails not getting delivered to your recipients.

This gets even more important when you get to the step where you are going to implement DMARC.
As mentioned around DMARC later, consider implement a tool, like VALIMAIL mentioned later, to monitor the effects of SPF, DKIM and DMARC. So you can see if email is getting blocked, not delivered etc.

Sources

DKIM

DKIM email authentication’s goal is to prove the contents of the mail haven’t been tampered with.

What is DKIM?

DKIM or DomainKeys Identified Mail is an email authentication protocol that helps to prevent email spoofing and phishing attacks. It allows email systems to verify that the message was not altered during transit and that it was indeed sent by the domain owner. DKIM works by adding a digital signature to the header of the email message.

Intro to DKIM from Microsoft KB

A quick intro to DKIM, from Microsoft’s KB article as follows:

How to use DKIM for email in your custom domain – Office 365 | Microsoft Docs

DKIM is one of the trios of Authentication methods (SPF, DKIM and DMARC) that help prevent attackers from sending messages that look like they come from your domain.

DKIM lets you add a digital signature to outbound email messages in the message header. When you configure DKIM, you authorize your domain to associate, or sign, its name to an email message using cryptographic authentication. Email systems that get email from your domain can use this digital signature to help verify whether incoming email is legitimate.

In basic, a private key encrypts the header in a domain’s outgoing email. The public key is published in the domain’s DNS records, and receiving servers can use that key to decode the signature. DKIM verification helps the receiving servers confirm the mail is really coming from your domain and not someone spoofing your domain.

Microsoft-365’s built-in DKIM configuration is sufficient coverage for most customers. However, you should manually configure DKIM for your custom domain in the following circumstances:

You have more than one custom domain in Microsoft 365
You’re going to set up DMARC too (recommended)
You want control over your private key
You want to customize your CNAME records
You want to set up DKIM keys for email originating out of a third-party domain, for example, if you use a third-party bulk mailer.

How does DKIM work?

When an email is sent, a digital signature is added to the header of the message. This signature is created using a private key that is unique to the domain owner. The public key is then published in the DNS record of the domain. When an email is received, the recipient’s email system checks the DKIM signature to see if it is valid. If the signature is valid, it means that the message was not altered during transit and that it was indeed sent by the domain owner.

DKIM also allows domain owners to specify which email messages should be signed. This is done by adding a policy to the DNS record of the domain. The policy specifies which email messages should be signed and which should be rejected.

Why is DKIM important?

Email spoofing and phishing attacks are a common tactic used by cybercriminals to trick users into providing sensitive information such as login credentials, credit card numbers, and more. DKIM helps to prevent these types of attacks by verifying the sender of an email message and ensuring that the message was not altered during transit.

In addition to DKIM, there are other email authentication protocols such as SPF and DMARC that can be used to further enhance email security. By implementing these protocols, domain owners can provide a more secure email environment for their users.

Adding DKIM for custom domains – adding the “selector(s)” public DNS records

For each domain for which you want to add a DKIM signature in DNS, you need to publish two CNAME records.
If you have provisioned custom domains in addition to the initial domain in Microsoft 365, you must publish two CNAME records for each additional domain. So, if you have two domains, you must publish two additional CNAME records, and so on.

Where:
For Microsoft 365, the selectors will always be “selector1” or “selector2“.

customDomainIdentifier is the same as the customDomainIdentifier in the customized MX record for your custom domain that appears before mail.protection.outlook.com. For example, in the following MX record for the domain contoso.com, the customDomainIdentifier is contoso-com:

contoso.com. 3600 IN MX 5 contoso-com.mail.protection.outlook.com
“initialDomain” or “root domain” is the domain that you used when you signed up for Microsoft 365. Initial domains always end in onmicrosoft.com.

The “customDomainIdentifier” is also referred to as “domainGUID” by Microsoft.
This is normally translated as custom domain: domain.com = domain-com when made to a customDomainIdentifier. If you want to make sure, just run a cmd, hit nslookup, then type set type=mx hit enter, then input the custom domain. You will then get the mx record for your domain. Look for the part before “.mail.protection.outlook.com”

The part highlighted in yellow is your customDomainIdentifier.

You will need to create 2 records in public DNS for each custom domain for DKIM.
It may be wise to create a list for reference before you begin the changes to keep track.
Every custom domain, will for DKIM have 2 CNAME records pointing back to your “initialdomain/rootdomain”. (selector 1 and selector 2).

Example:
365 root domain: acmecompany.onmicrosoft.com
Custom domains to add: customdomain1.com and Customdomain2.com

DNS records and values to add in DNS:

For “customdomain1.com”
Hostname: selector1._domainkey.customdomain1.com
Value: selector1-customdomain1-com._domainkey.acmecompany.onmicrosoft.com

Hostname: selector2._domainkey.customdomain1.com
Value: selector2-customdomain1-com._domainkey.acmecompany.onmicrosoft.com

For “customdomain2.com”
Hostname: selector1._domainkey.customdomain2.com
Value: selector1-customdomain2-com._domainkey.acmecompany.onmicrosoft.com
TTL Value: 3600

Hostname: selector2._domainkey.customdomain2.com
Value: selector2-customdomain2-com._domainkey.acmecompany.onmicrosoft.com
TTL Value: 3600

Example from domeneshop.no:

Enable DKIM signing for your custom domain in 365

After you have added the needed DNS records for your custom domain(s) in public DNS. You can move on to enable DKIM signing for the domain in 365. This can easily be done in the admin portal, found here: https://security.microsoft.com/dkimv2?rfr=scc_dkimv2

Select your domain, click the slider to enable signing.
Repeat for every domain where you have added DNS records, and want to enable DKIM signing.

DKIM test page

When DKIM have been configured, you can test the config inside 365 via the following link: https://admin.microsoft.com/AdminPortal/?searchSolutions=DKIM#/homepage

Input the domain you want to test, click run to test the config.

wait for the test to finish

If the test is successful, it will show in the result

If there is no DKIM configured, the test will also tell you

Scrolling down, you will also get a knowledge article guiding you on how to set up DKIM

DKIM Summary

DKIM is an important email authentication protocol that helps to prevent email spoofing and phishing attacks. It works by adding a digital signature to the header of the email message, which allows email systems to verify that the message was not altered during transit and that it was indeed sent by the domain owner. By implementing DKIM, domain owners can protect their domain reputation and prevent their domain from being used for malicious purposes.

DMARC

Use DMARC to validate email, setup steps – Office 365 | Microsoft Docs

RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC) (ietf.org)

What is DMARC?

DMARC or Domain-based Message Authentication, Reporting, and Conformance is an email authentication protocol that helps to prevent email spoofing and phishing attacks. It allows domain owners to specify which email messages should be accepted or rejected based on the results of SPF and DKIM checks. DMARC works by providing a policy to the recipient’s email system that tells it how to handle email messages that fail SPF and DKIM checks.

DMARC email authentication’s goal is to make sure that SPF and DKIM information matches the from address.

How does DMARC work?

When an email is sent, the recipient’s email system checks the SPF and DKIM records of the sender’s domain to verify that the message was sent by the domain owner and that it was not altered during transit. If the SPF and DKIM checks fail, the recipient’s email system can either mark the message as spam or reject it altogether.

DMARC provides a policy to the recipient’s email system that tells it how to handle email messages that fail SPF and DKIM checks. The policy can be set to one of three levels: none, quarantine, or reject. If the policy is set to “none”, the recipient’s email system will not take any action. If the policy is set to “quarantine”, the recipient’s email system will mark the message as spam. If the policy is set to “reject”, the recipient’s email system will reject the message altogether.

DMARC also provides reporting capabilities that allow domain owners to monitor how their domain is being used for email. The reports provide information on how many email messages were sent using the domain, how many were rejected, and how many were marked as spam

Why is DMARC important?

Email spoofing and phishing attacks are a common tactic used by cybercriminals to trick users into providing sensitive information such as login credentials, credit card numbers, and more. DMARC helps to prevent these types of attacks by providing a policy to the recipient’s email system that tells it how to handle email messages that fail SPF and DKIM checks. By implementing DMARC, domain owners can protect their domain reputation and prevent their domain from being used for malicious purposes.

In addition to DMARC, there are other email authentication protocols such as SPF and DKIM that can be used to further enhance email security. By implementing these protocols, domain owners can provide a more secure email environment for their users.

Consideration before implementing

IMPORTANT: When you implement DMARC care is advised, as it may impact your mail flow.
This means, if you set your DMARC policy to anything other than none (audit only), recipients may get emails delivered in quarantine if policy is set to quarantine, or not at all if set to reject if DMARC validation does not pass according to policy.
It is therefore a good practice to start with a DMARC policy of none (audit) for a period and monitor the potential impact of your current configuration when it comes to status of mail flow.

This can be done via tools like VALIMAIL DMARC monitor that is mentioned in a separate chapter of this document. When you are happy with the results of the configuration, you can then change the DMARC policy over to something more restrictive (quarantine or reject).

How do SPF and DMARC work together to protect email in Microsoft 365

From Microsoft KB article

An email message may contain multiple originator or sender addresses. These addresses are used for different purposes. For example, consider these addresses:

“Mail From” address: Identifies the sender and specifies where to send return notices if any problems occur with the delivery of the message, such as non-delivery notices. This appears in the envelope portion of an email message and is not displayed by your email application.
This is sometimes called the 5321.MailFrom address or the reverse-path address.

“From” address: The address displayed as the From address by your mail application. This address identifies the author of the email. That is, the mailbox of the person or system responsible for writing the message. This is sometimes called the 5322.From address.

SPF uses a DNS TXT record to provide a list of authorized sending IP addresses for a given domain. Normally, SPF checks are only performed against the 5321.MailFrom address. This means that the 5322.From address is not authenticated when you use SPF by itself. This allows for a scenario where a user can receive a message, which passes an SPF check but has a spoofed 5322.From sender address. For example, consider this SMTP transcript:

If you configured SPF, then the receiving server performs a check against the Mail from address phish@phishing.contoso.com. If the message came from a valid source for the domain phishing.contoso.com, then the SPF check passes. Since the email client only displays the From address, the user sees that this message came from security@woodgrovebank.com. With SPF alone, the validity of woodgrovebank.com was never authenticated.

When you use DMARC, the receiving server also performs a check against the From address. In the example above, if there is a DMARC TXT record in place for woodgrovebank.com, then the check against the From address fails.

What is a DMARC TXT record

Like the DNS records for SPF, the record for DMARC is a DNS text (TXT) record that helps prevent spoofing and phishing. You publish DMARC TXT records in DNS. DMARC TXT records validate the origin of email messages by verifying the IP address of an email’s author against the alleged owner of the sending domain. The DMARC TXT record identifies authorized outbound email servers. Destination email systems can then verify that messages they receive originate from authorized outbound email servers.

The most common DMARC TXT record setup is something like this:
_dmarc.domain TTL IN TXT “v=DMARC1; p=policy; pct=100”

Where:

domain is the domain you want to protect. By default, the record protects mail from the domain and all subdomains. For example, if you specify _dmarc.contoso.com, then DMARC protects mail from the domain and all subdomains, such as housewares.contoso.com or plumbing.contoso.com.

TTL should always be the equivalent of one hour. The unit used for TTL, either hours (1 hour), minutes (60 minutes), or seconds (3600 seconds), will vary depending on the registrar for your domain.

pct=100 indicates that this rule should be used for 100% of email.

policy specifies what policy you want the receiving server to follow if DMARC fails. You can set the policy to none, quarantine, or reject. Microsoft has a “Best practice” DMARC implementation guide that has a lot more details, this can be found on their docs pages here

Conclusion for DMARC

DMARC is an important email authentication protocol that helps to prevent email spoofing and phishing attacks. It works by providing a policy to the recipient’s email system that tells it how to handle email messages that fail SPF and DKIM checks. By implementing DMARC, domain owners can protect their domain reputation and prevent their domain from being used for malicious purposes.

Valimail DMARC Monitor for Microsoft 365

Office 365 users: Get DMARC monitoring today, for free – Valimail

Why DMARC is so challenging

While the benefits of DMARC are clear, many organizations have had trouble with the implementation of this open standard. Domain-based Message Authentication, Reporting, & Conformance (DMARC) directs receiving mail servers to send aggregate reports back to domain owners, so they can analyze which services are sending mail on their behalf. This data is valuable for both cloud migration and anti-phishing projects.

But it can be difficult to extract actionable intelligence from these reports, which are typically large XML files containing long lists of IP addresses. Companies need to do extensive “detective work” to figure out which services correspond to those IPs and which people within their organization are responsible for using those services, which includes updating the corresponding DMARC, Sender Policy Framework (SPF), and DomainKeys Identified Mail (DKIM) records to ensure that the services are properly authorized. What’s more, every change requires updating the Domain Name System (DNS), which itself can be an involved process.

Free DMARC monitoring

Valimail Monitor for Office 365 can make this part of the DMARC journey much easier. Instead of manually parsing the massive amount of XML-based IP address data you get in DMARC reports, Valimail Monitor for Office 365 digests DMARC aggregate reports and turns them into an easily readable list of named services. In addition, for each of these services, Valimail shows how many messages are passing authentication and how many are failing. Valimail also provides overall stats on DMARC authentications and authentication failures.

Getting access to the Valimail DMARC service

Registration to the service can be done for free here
https://use.valimail.com/ms-dmarc-monitor.html
Fill in the needed information, and wait for an email with more instructions.

When the welcome email arrives, the account needs to be activated via the link in the e-mail

Upon signup, an e-mail with more detailed instructions on how to setup DNS will follow.
The included links to their KBs are well written.

Setup needed in for records in public DNS

Instructions for Valimail DNS records can be found here.
Visit the Valimail Knowledge Base for step-by-step instructions

Records need to be added for each domain, if there is more than one domain that is to be configured to route DMARC reports to the valimail service.

To continue the setup, you need access to edit the public DNS records for the domain – domeneshop.no in the following example in this document.

For Domeneshop – Norwegian registrar:

v=DMARC1; p=none; rua=mailto:dmarc_agg@vali.email (P=none – for monitoring only)

Added for some domains just to get some data piped to valimail to see what data can be viewed via the service.

After editing DNS, and when DNS gets updated with the new DMARC value, an email confirming the change was picked up pops in the inbox.

Azure AD for SSO to Valimail

Setup for SSO against Azure AD – because you can.
Giving you the added benefit of securing access to the service with one IDP, MFA, controlling and monitoring access from one place. Always a good thing.

Login to Azure AD, go to Enterprise applications, and add a new application.
Give it a name, click create.
https://portal.azure.com/#blade/Microsoft_AAD_IAM/AppGalleryBladeV2

After creation, head over to Single sign-on in the left bar menu, select SAML.

In the Basic SAML Configuration, click Edit

Input the following:
Identified (Entity ID): https://app.valimail.com
Reply URL (Assertion Consumer Service URL): https://app.valimail.com/sso/consume
Sign on URL: <leave blank>
Relay State: <leave blank>
Logout URL: https://app.valimail.com/sso/consume

Next up we need to edit the Attributes & Claims.
We need this to end up like this:

But, our starting point is this:

First step, remove the ones marked red.
Second, edit the names of the ones marked yellow.

1: Hit Edit on the Attributes and Claims box.
Click the three dots on the line for the claim to delete and select delete, then confirm.
Both claims shown in the following image.

2: While still in the edit window, time to edit the name for the other two claims.
We need them to be exactly as follows:

Click the first claim with the value “user.givenname” to open the properties.

Change the name to “FirstName”, remove everything in namespace, click save – Remember, this is Case Sensitive.

Repeat for the “LastName” record.

The results for Attributes and Claims should now look like this:

And like this one step back, on the “Single sign-on” breadcrumb menu.

Scroll down to SAML Signing Certificate, click the download link for Federation Metadata XML and save the file.
Also, change the notification email to a valid recipient to get notification when the certificate is expiring.

Add a user for SSO in Azure

Time to add a user for SSO login via Azure AD

Enable SSO login for a user, by assigning the enterprise app to the user in azure ad.
Go to Users and groups in the breadcrumb menu for the app. Click add user/group.

Click none selected, search for a user/group, select the needed object, hit select, then assign

Setting things up in the Valimail platform

Any user that is to have SSO loin enabled to Valimail, needs to exist in Valimail.
So, they need to be created inside valimail as objects.
SSO testing will fail unless you add your user during this step and ensure the user has already been added as a user in the Valimail Product under Account Settings.

Enable SSO on the Valimail side

Go to Account settings, scroll down to Single Sign-on, click Setup.

Click the “Upload IDP metadata file”

Browse to the Federation Metadata XML file you saved from Azure earlier.

After the file is selected, hit save.
PS: MAKE SURE YOU HAVE AN ACCOUNT SETUP WITH ACCESS BEFORE SAVING!

SSO Login experience

After SSO is enabled, you get the following when you visit the Valimail service to log on.
Login here: https://app.valimail.com/

Upon entering your email, for an SSO enabled account, the password field gets grayed out, and the login button changes to “Log in with SSO”

Upon clicking login, you get redirected to to Microsoft login service for authentication.
You will see your branding if configured.

If MFA is configured on the Azure side, you will get prompted.

After this, you are granted access.

Summary

SPF is designed to help prevent spoofing, but there are spoofing techniques that SPF can’t protect against. To defend against these, once you’ve set up SPF, you should configure DKIM and DMARC for Office 365. SPF when configured, defines who is allowed to send email on behalf of the configured domain(s). if the sender is not defined in the SPC record, spf check will fail, and e-mail is sent to spam or discarded. It is therefore important to have all sources sending e-mail for the organization included as sources in the SPF record to avoid issues.

DKIM email authentication’s goal is to prove the contents of the mail haven’t been tampered with.
DKIM for the initial domain in 365 is enabled by default (the “yourname.onmicrosoft.com” domain).
DKIM in 365 for your added domains (custom domains), is enabled by a switch on each domains. But, before you can do this, you have do add some DNS records to the public dns for each of the custom domain(s), pointing them to the “DKIM selectors” for the initial domain”. After this, you can enable DKIM signing for the domain in 365.

DMARC email authentication’s goal is to make sure that SPF and DKIM information matches the from address. Care should be advised when implementing DMARC, as it has the potential to impact mail flow. It is therefore advisable to start with an audit policy in combination with a monitoring tool, like Valimail, to monitor for potential unwanted effects. By going via audit, you avoid impacting email flow before your have gathered insight to the actual effects the switch to DMARC enforcement will have.

Valimail is a monitoring tool designed to help you monitor the effects of SPF, DKIM and DMARC. This can give you valuable insights when it comes to implementing changes. As well as tracking unwanted effects of said changes before changing policies from audit to enforcement, especially for DMARC. By monitoring this, you can avoid undelivered messages to your recipients. You can also fine tune your environment before making the switch to enforcing more restrictive policies. After implementing, you also have a graphical view of email flow, and the ongoing status of SPF/DKIM and DMARC on your organizations mail-flow in onw dashboard.

Reference material

How to Set Up DMARC, DKIM, and SPF in Office 365 (O365) Exchange Server: the Complete Implementation Guide – DMARCLY

Setting up DKIM in Office 365 – Knowledgebase – Pen Publishing Interactive, Inc. (ppi.net)

Office 365: Enabling DKIM for Custom Domains – TechNet Articles – United States (English) – TechNet Wiki (microsoft.com)

Office 365 DKIM Setup Guide : PowerDMARC

How Sender Policy Framework (SPF) prevents spoofing – Office 365 | Microsoft Docs