Skip to content

My E-mail appears as spam – Troubleshooting path | Part 11#17

The current articles and the next three following articles are dedicated to the subject of a troubleshooting scenario of internal/outbound spam in Office 365 and Exchange Online environment. In the current article, the focus is on: “drowning” the path of the troubleshooting processes flow.

The troubleshooting flow includes steps such as:

  • Step 1 – Verifying if our domain name is blacklisted.
  • Step 2 – Verifying if the problem is related to E-mail content.
  • Step 3 – Verifying if the problem is related to particular organization user E-mail address.
  • Step 4 – Moving the troubleshooting process to the “other side.

Additionally, we will briefly review the document that I have created (Outbound spam – Troubleshooting checklist) for simplifying the task of troubleshooting documentation, etc.

The characters of troubleshooting internal/outbound spam scenario

In a scenario of internal/outbound spam, we will need to deal with some challenges that relate to the complexity of such as scenario:

  • Many components and infrastructure that are involved in the mail flow.
  • Many cases that could lead to an “outcome” in which our E-mail is identified as spam mail.
  • No clear indication of the reason in which our E-mail was identified as spam.
  • No clear evidence for the “element” which “decide” to identify our organization E-mail as spam.

Internal spam in Office 365 and Exchange Online environment | Before we start

Before starting the actual Troubleshooting process, it’s important that we will be aware of a couple of elements that relates to internal/outbound spam scenario:

1. Verify that we have evidence

The first “station” on our journey, is the “clear evidence” for the problem.

  1. The “clear evidence” could be an NDR that sent to one of our organization users, who inform him that his E-mail message rejected because his mail considers as spam\Junk mail.
  2. A mail notification from a blacklist monitor service, which informs us that our organization appears as blacklisted.
  3. External receipt that notifies our organization user that he got his E-mail message but, the E-mail saved in his junk mail folder (our E-mail message classified as spam/junk mail).
Verify that we have evidence

2. Point out the responsible side that could cause the problem

The “cause” of the problem, in which E-mail that sent from our organization identified as spam, could be related to “our side” or, to the “other side.”

An example that relates to the “other side” could be a scenario of false positive a scene in which our mail identified by mistake as spam.

Our organization E-mail identified as spam - Our side or their side

Although that the problem could be related to the “other side,” in most of the scenarios the underlying assumption is that the problem is related to “our side.”

In simple words – it is recommended to start the troubleshooting process begging on “our side of the equation.”

Only when we fulfill our “due diligence” and, verify beyond a doubt that “we are OK,” then we can start the troubleshooting steps that will check the “other side.”

Internal outbound spam troubleshooting our and their side

3. Verifying the “scope” of the internal/outbound spam issue

The term: “internal/outbound spam” is a very general term.

To be able to create a clear troubleshooting path, we need to start with: defining the scope of the problem.

The worst-case scenario could be a scene in which our domain name appears as blacklisted. This scenario considers as the “worst-case scenario” because, in this case, the problem will impact all of our organization users.

In case that we verify and find that the “problem scope” is not related to “domain level”, the next level could be:

An issue that refers to a specific E-mail (E-mail content) or, to a particular user from our organization.

From my experience, many of the internal \ outbound spam scenario realities to an E-mail content that the Office 365 users try to send.

In this case, we can very quickly locate if the problem is indeed related to the E-mail content by sending to the “destination recipient,” an empty E-mail message.

In case that we also experience the problem when sending the “empty mail message”, this could be related to an issue with an E-mail address of a particular user organization.

The next step will be: sending an E-mail to the “destination recipient” by using an E-mail address of another organization user.
For example: if the “original sender” was: Alice@o365info.com, send E-mail by using Bob E-mail address: Bob@o365info.com

In case that we have also emoted this scenario, the rest of the “troubleshooting path” could be related to the “other side” meaning, some element\s in the destination recipient mail infrastructure.

Our organization E-mail identified as spam - Domain level or recipient level

The internal/outbound spam Troubleshooting path

Step 1 – Verifying if our domain name is blacklisted

Before we start our “troubleshooting journey”, the most significant operation in a scenario of – internal/outbound spam is to verify if – our domain name appears as blacklisted.

This is the “worst-case scenario” because this situation impacts all of our organization users who use an E-mail address with our organization domain name.

In case that the answer is “yes”, meaning our domain name appears as blacklisted, we need to start with the most important task: De-list our domain name from the blacklist

In a scenario in which our domain name appears as blacklisted, we need to find the blacklist\s in which our domain name appears as blacklisted and, apply a request to removed from the blacklist.

You can read more information about the subject of – de-list our domain name in the article – De-list your organization from a Blacklist | My E-mail appears as spam | Part 16#17

Additional tasks that need to be implemented are:

1. In-house investigation – ROC (Root Cause Analyses)

The second task could describe as “in-house investigation”.
In case that is not a false-positive scenario and, there is a “real reason” for identifying our domain name as a “problematic domain,” we need to put all our effort into finding the “root cause” of the problem.

2. Consider using a blacklist monitor service

This is not a mandatory requirement, but instead, more of a: best practice.
Using this type of service enables us to identify in real time a problem in which our domain name appears as blacklisted and, allows us to be proactive instead of reactive.

The proactive verse the reactive approach for dealing with outbound spam E-mail

You can read more information about the subject of – blacklist monitor service in the article: My E-mail appears as spam | Troubleshooting – Domain name and E-mail content | Part 12#17

Moving on – In case that the answer is: “No”, meaning that our domain name doesn’t appear as blacklisted, this is actually “good news” because we prefer the less critical scenarios that reviewed in the next sections.

The most common reason for the scenario in which mail that sent from our organization user identified as spam/junk mail is – the E-mail content.

To be able to find out if the problem is related to specific E-mail message content that appeared in the E-mail, we will need to send an “empty E-mail” (no content) to the destination receipt.

Send and empty E-mail message to the destination recipient

In case that the empty E-mail message successfully sent to the destination receipt, we can assume that the problem is related to the specific E-mail message content.

Additional recommended tasks in a scenario in which we discover that the problem was relates to the particular E-mail content are:

1. In-house investigation – ROC (Cause Analyses)

Start an “In-house investigation” to find out what part of the content of the E-mail message is the cause of the problem.

Optional, additional operations:

2. Using Exchange Online future – outbound spam.

An additional recommended step that we can implement is – “activating” the Exchange Online option of – outbound spam.
This option will send a notification to the “person that we indicate” each time that the Exchange Online will recognize E-mail message that was sent by Office 365 users as a spam \ Junk mail.

You can read more information about the subject of Exchange Online – outbound spam, in the article: My E-mail appears as spam | Troubleshooting – Domain name and E-mail content | Part 12#17

3. Implementing spam score check

This operation highly recommended because using a “spam score” tool will enable us to understand the exact cause of the problem (the reason to identify the E-mail message as spam/junk mail).

And additionally in the future, it’s also highly recommended to perform the spam score before we send out an E-mail such as commercial E-mail, etc.

You can read more information about how to check the spam score in the article: My E-mail appears as spam | The 7 major reasons | Part 5#17

Moving on – In case that the answer is: “No”, meaning that the external receipt did not get the “Empty E-mail message”, this will lead us to the next troubleshooting step, in which we will need to verify if the problem is related to the specific E-mail address of our organization recipient .

Internal spam troubleshooting flow -01

Just a brief summary: as of the current phase, we know that:

  • Our domain name is not blacklisted.
  • The issue is not related to a specific content that “appear” in the E-mail message because even when we sent an “empty E-mail message”, the E-mail message didn’t reach to the destination receipt and also; we didn’t get a notification from Exchange Online about “outgoing mail” that was identified as spam\Junk mail (assuming that we have activated the outbound spam option of Exchange Online).

The next “parts” that we need to check in “our side,” is a scenario in which a specific user from our organization appears as blacklisted.

To be able to find out if the problem is related to the specific email address of an organization’s recipient, we will need to send an E-mail to destination receipt, by using an E-mail account (other E-mail address) of another organization user.

In case that when using other organization user E-mail address, the E-mail was successfully sent to the destination receipt, we can assume that the problem is related to the particular E-mail address of our organization user.

Note: Another option is a “problem” on the “other side” (the destination recipient or the target recipient mail infrastructure)

Optional, additional operations:

1. In-house investigation – ROC (Root Cause Analyses)

Start an “In-house investigation” for finding out, what is the reason in which a particular E-mail address of the organization user blacklisted.

Optional, additional operations:

2. Exchange Online – Message trace

In case that we suspect the problem caused because a “bulk mail” scenario, in which the organization users “load” external recipients with a lot of E-mail messages, we can use the Exchange Online tool: Message trace, for getting more detailed information about the user organization user “activity.”

3. SPF record

An addition parameter that is important to verify is our organization SPF record. The verification process could include:

Verify that we use SPF record, check the SPF record is configured correctly, etc.

Note: The need to verify the organization SPF record, is not related to a specific “phase” in the troubleshooting process and practically, you can even start by completing this step at the begging of the troubleshooting process.

Moving on – In case that the answer is: “No”, meaning the external receipt did not get an E-mail message that was sent from the “other organization user”, we will need to move on to the next troubleshooting step.

Internal spam troubleshooting flow -02

Moving the troubleshooting process to the “other side

In this phase, we “move” into the territory of the “other side” meaning: the destination receipt realm.
Because we didn’t manage to point out a specific element from “our side”, we assume that the reason in which our E-mail identified as spam is related to the “other side” of the equation.

The term “the other side” can be translated into factors that are related to the specific destination recipient infrastructure or the target recipient mail infrastructure.

Troubleshooting internal - outbound spam the other side

In case that in our scenario the “evidence” for the outbound spam problem is an NDR message that sent from the mail server of the destination receipt, we can “jump” to step 5.

Asking for help from the “other side” | Overcomes possible obstacles

Yes, I know it’s not so simple to get help or, asks for help from the “other side” because we need to overcome a number of obstacles such as – most of the time it’s not so simple to contact the destination recipient, many times the destination recipient is not a “technical person” and so on.

In case that we need to contact the “technical representative” of the destination recipient, it’s even harder.
There no way that we can ensures his cooperation throughout the process because that often, “the other side” has no interest.

Despite all of this “obstacle,” it’s necessary to understand that in a scenario of “mail flow” that is implemented using different mail infrastructure (us and them), it is not always possible to find the causes of the spam problem, only by Investigating and troubleshooting “our side” (our Office 365 and Exchange Online mail infrastructure) of the story.

The main charters of this scenario are – E-mail that sent from our organization is reaching to the destination recipient mailbox but, sent to the junk mail folder.

There could be three primary reasons for this issue:

  1. Inbox rule – inbox rule (or blocked recipient list) that was defined by the destination receipt, which classifies E-mail message that sent from our domain as spam\junk mail.
  2. Antivirus or other mail security application, which identifies our organization user E-mail as spam.
  3. Mail application that includes spam filter and identifies our organization user E-mail as spam.

To be able to verify this option or, to eliminate this option, we will need to contact the destination recipient and ask for his help.
The destination recipient will need to check this option and update us regarding the results.

In case that we could not find the “element” or in case that we got an NDR message from the destination mail server, we will need to move to the next troubleshooting step.

Internal spam troubleshooting flow -03

In this step, we will need the assistance of a technical person that manages the mail infrastructure of the “destination receipt”.

We will need to ask the “technical contact,” to look over the mail server log or, into his mail security gateway log and try to locate information about the “event” in which mail that sent from our organization identified as spam and if possible, the reason for this “identification.”

Summary and Recap

In case you read all the previous articles in this article series, there were additional troubleshooting steps and actions that could have been performed such as:

Using online web services that will help us to get our spam score for a specific E-mail message that we are going to send.

We can combine this steps, as a “preventive action” or as a part of the troubleshooting flow. This decision about what are the specific steps that will include in the internal \ outbound spam troubleshooting flow is for you to decide, based on the specific scenario charters, your organization’s business needs and so on.

Using Outbound spam – Troubleshooting checklist document

For your convenience, I have created a document that includes a short troubleshooting checklist for a scenario of internal \ outbound spam.

The purpose of this document is to facilitate the documentation process and to enable you to get a quick list of the troubleshooting steps that need to implemented.

The Outbound spam - Troubleshooting check list

In the following screenshot, we can see the first part in which we document the general charters of the scenario.

Despite the fact that it seems obvious, it is very important that we will have a very accurate and precise scope of the problem. We will need to answer questions such as – who is our organization user who reports about the problem, who is the “destination recipient”, does the problem reported by many of our organization users or only one and so on.

Outbound spam - Troubleshooting check list -01

The next part is troubleshooting cubes” that includes:

  • A brief description of the task
  • A brief description of the purpose of the task
  • The documentation of the troubleshooting step’s results
Outbound spam - Troubleshooting check list -02

Download the: Outbound spam – Troubleshooting checklist document

o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *