Spam protection and legitimate bulk email in Exchange Online

Case #

You have a Microsoft 365 tenant and you need to be able to send legitimate bulk email via Exchange Online. You receive Non-Delivery Reports (NDR) and/or notifications from Exchange Online Protection (EOP) that some emails cannot be delivered for various reasons. This article discusses spam protection and legitimate bulk email in Exchange Online from an operational point of view.

Solution #

The root cause of this case is multi-factor and you need to carry out detailed investigation of your Exchange Online configuration and the email sending scenario you are trying to accomplish.

First and foremost, as per Microsoft official documentation, it's difficult to strike a balance between customers who want to send a large volume of email vs. protecting the service from compromised accounts and bulk email senders with poor recipient acquisition practices. The cost of a Microsoft 365 email source landing on a third-party IP block list is greater than blocking a user who's sending too much email.As described in the Exchange Online Service Description, using EOP to send bulk email is not a supported use of the service, and is only permitted on a "best-effort" basis. For customers who do want to send bulk email, we recommend the following solutions:

• Send bulk email through on-premises email servers: Customers maintain their own email infrastructure for mass mailings.
• Use a third-party bulk email provider: There are several third-party bulk email solution providers that you can use to send mass mailings. These companies have a vested interest in working with customers to ensure good email sending practices.

The Messaging, Mobile, Malware Anti-Abuse Working Group (MAAWG) publishes its membership roster at https://www.maawg.org/about/roster. Several bulk email providers are on the list, and are known to be responsible internet citizens.

An email blacklist more known as DNSBL (Domain Name System-based Blackhole List) or RBL Real-time Blackhole List is large a list of public domains and IP addresses that are marked to be suspicious for sending spam emails over the internet. Organizations like Email Service Providers (ESP), Internet Service Providers (ISP), and Anti-spam agencies (ASA) refer to this list to detect and block any spam emails entering their network. DNSBL or email blacklist list is not a single centralized list on the internet. However, many anti-spam organizations are maintaining their independent DNSBL list. Some of these lists are free to use while few require commercial licenses. To find out more about DNSBL/RBL and the ways to protect your domain/IP from being blacklisted, you can read the following thorough article: https://netcorecloud.com/tutorials/email-blacklist/.

If you receive NDR with following message:

"Your message couldn't be delivered because you weren't recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it's no longer allowed to send email. Contact your email admin for assistance. Remote Server returned '550 5.1.8 Access denied, bad outbound sender."

you should follow instructions in the following article to remove your user(s) from the Restricted Users section: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/removing-user-from-restricted-users-portal-after-spam?view=o365-worldwide.

In spite of the above general rule which applies in all cases, in general you should also run through the following anti-spam checklist, to ensure error-free sending of your business newletter or other legitimate bulk email sending. Check the the email security configuration of your DNS domain and your Microsoft 365 tenant. This includes checking the following configuration parameters in particular:

• Validate your SMTP domain against email reputation services and RBL checkers (SMTP blacklists) which are available online, the most notable of which are the following:
  • https://dmarcly.com/tools/blacklist-checker
  • https://mxtoolbox.com/blacklists.aspx
  • https://senderscore.org/
  • https://sitelookup.mcafee.com/
  • https://talosintelligence.com/
  • https://www.proofpoint.com/us/products/email-protection/open-source-email-solution
• DNS SPF record. SPF records list all of the IP addresses and domain names that are authorized to send emails on behalf of the domain.
• DKIM record. DKIM records provide a digital signature to authenticate whether or not the sender actually authorized the email. This digital signature also helps prevent on-path attacks, in which attackers intercept communications and alter messages for nefarious purposes. You should consults your SMTP provider for instructions on how to setup DKIM. In the case of Exchange Online, step-by-step instructions on how to configure DKIM for Microsoft 365 SMTP domains can be found at: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email?view=o365-worldwide and https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email. In essence you need to first navigate to https://security.microsoft.com/dkimv2 and generate the DKIM keys for the custom domain in question. The wizard on that page will first prompt you to create two (2) CNAME records for DKIM for each custom domain, as in the following example for contoso.com.
  • Host Name : selector1._domainkey Points to address or value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com
  • Host Name : selector2._domainkey Points to address or value: selector2-contoso-com._domainkey.contoso.onmicrosoft.com.
  • Then in the details flyout which appears, change the Sign messages for this domain with DKIM signatures setting to Enabled (Toggle on). When you're finished, click Rotate DKIM keys.

• DMARC record. DMARC records hold a domain’s DMARC policy. DMARC is a system for authenticating emails by checking a domain’s SPF and DKIM records. The DMARC policy states whether emails that fail SPF or DKIM checks should be marked as spam, blocked, or allowed to go through. DMARC requires one TXT DNS record for each custom domain you wish to protect in Exchange Online. One example for domain contoso.com is the following DMARC record:
  • _dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none"
• For SPF, DKIM and DMARC configuration you should make use of https://dmarcly.com/tools/ for generating and validating the required records. Also this article clarifies in detail all aspects of these DNS records which add layers of security to your SMTP domain operations. Another how-to article on using DMARC for outbound email is https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email.
• If you have a Content Delivery Network (CDN) in place, such as CloudFlare, ensure that its services are configured to allow the scenario you are trying to accomplish.
• If you are using a third party bulk email sending service, such as Mailchimp, you have to follow instructions to configure SPF/DKIM/DMARC on this service as well. An example step-by-step guidance for Mailchimp can be found at https://dmarcly.com/blog/how-to-set-up-spf-and-dkim-for-mailchimp.

• If you use a CMS or other dynamic website which sends emails to end users via the Exchane Online SMTP servers, you should properly configure your site to do so, so as to avoid your email getting characterized as spam. In the case of WordPress sites, you can configure Exchange Online as the outgoing SMTP server by utilizing a WordPress plugin. One great example is the WP Mail SMTP plugin.
• MTA-STS record. The MTA-STS DNS record is a DNS record of type TXT that indicates that the domain supports MTA-STS. Mail Transport Agent Strict Transport Security (MTA-STS) is a new internet standard whih allows you to enable strict force-TLS for email sent between supported email providers. It is similar to HTTP Strict Transport Security (HSTS), where a force-TLS policy is set and then cached for a specified amount of time, reducing the risk of man-in-the-middle or downgrade attacks. MTA-STS is complemented by SMTP TLS Reporting (TLSRPT), which gives you insight into which emails are successfully delivered over TLS, and which aren’t. TLSRPT is similar to DMARC reporting, but for TLS. Exchane Online fully supports MTA-STS. Microsoft 365 tenants can decide if they want to enable MTA-STS for their domain by publishing a DNS record and an MTA-STS policy.
• DANE security standard. Today, DANE supports outbound email from Exchange Online with inbound support scheduled for December 2022. DANE and MTA-STS can be used together, Exchange Online tenants canimplement MTA-STS while waiting for inbound DANE support to arrive.
• BIMI record (optional, if you need your brand logo to accompany your email address). BIMI is a specification allowing for the display of brand logos next to authenticated e-mails. There are two parts to BIMI: a method for domain owners to publish the location of their indicators, and a means for Mail Transfer Agents (MTAs) to verify the authenticity of the indicator. To implement BIMI, companies need a valid DMARC DNS record with a policy of either quarantine or reject, an exact square logo for the brand in SVG Tiny P/S format and a DNS TXT record for the domain indicating the URI location of the SVG file. The only supported transport for the SVG URI is HTTPS. The BIMI DNS record is in the following format: default._bimi TXT "v=BIMI1; l=https://example.com/image.svg;"
• Check the Exchange Online message trace by taking timestamps of the emails being bounced/rejected and try to discover more verbose information: https://admin.exchange.microsoft.com/#/messagetrace. It is important to understand the status of the rejected messages, ie whether are marked as "failed" or "spam". In either case, examining the message trace will help you understand if your are being blocked with an NDR message or not. If not, it may be that you are blocked due to activity classifed as spam. If you do receive NDRs, you should contanct your recipients' SMTP admin and read the details of the NDR to determine best solution.

• Check that your SMTP domain, public IP addresses and/or individual SMTP addresses are not listed in an RBL/DNSBL. You can make use of free RBL checkers, such as https://mxtoolbox.com/blacklists.aspx and https://grademyemail.co/email-blocklist-checker.
• Check your EOP anti-spam policies with focus on the outbound anti-spam policies: https://security.microsoft.com/securitypoliciesandrules.

• Consult with a service which validates the credibility of SMTP domains, such as one of the following. NeverBounce, Emailable, ZeroBounce, BriteVerify, Kickbox, bounceless.io, DeBounce, Bouncer, MailerLite. By running any of these services, you will get a more detailed analysis of why some outbound emails get bounced or rejected.
• Speak with the firewall and/or SMTP server administrators of the email recipients which are bouncing or rejecting your emails. Maybe the root cause is a firewall or SMTP server anti-spam policy against your SMTP domain. If after resolving a possible SPF/DKIM/DMARC misconfiguration, you continue to receive NDR, you should speak again with the firewall/SMTP admins of your recipients to check if you are being blocked due to another policy/rule they have on their end.

Evaluating your SMTP receive and send capability scores #

After you have applied some or all of the above recommendations (as per your scenario) you should test incoming and outgoing SMTP flow from your SMTP domain by utilizing a free service such as Checktls.com, as shown in the below examples.