Spam protection and legitimate bulk email in Exchange Online


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.


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 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:

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:

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:
    • 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. Ste-by-step instructions on how to configure DKIM for Microsoft 365 SMTP domains can be found at:
    • 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.
    • 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.
    • For SPF, DKIM and DMARC configuration you should make use of 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.
    • If you are using a third party bulk email sending service, such as Mailchimp, you have to follow insstructions to configure SPF/DKIM/DMARC on this service as well. An example step-by-step guidance for Mailchimp can be found at
  • Check the Exchange Online message trace by taking timestamps of the emails being bounced/rejected and try to discover more verbose information: 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.
  • Consult with a service which validates the credibility of SMTP domains, such as one of the following. NeverBounce, Emailable, ZeroBounce, BriteVerify, Kickbox,, 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.

Was this article helpful?

Related Articles