Skip Navigation
Identifying and breaking email loops
Answer ID 5476   |   Last Review Date 11/10/2021

How do I identify and break an existing email loop?


Incoming Email
Oracle B2C Service (OSvC), All versions


Most email loops can be identified by either many duplicate incidents or incidents that have many duplicate threads.  The type of loop depends on the auto-responder.  If the responder sends enough of the original message to contain the tracking string, then incidents are updated with many threads.  If the responder does not send the tracking string then duplicate incidents may be created.  If a site has one type of loop, the other will usually also exist.  For more information on email tracking strings please refer to  Answer ID 5331: Incident Update by Email

1. To search for the current loops you need to create two reports. Refer to the following answers for instructions.

Answer ID 5392: Creating a report that counts threads in incidents

Answer ID 5475: Creating a report that counts recent incidents with the same subject

2. Inspect the incidents identified by the 2 reports and decide which are appropriate.  Often times there are multiple appropriate incidents with duplicate subjects and/or incidents with many threads due to processes or external integrations (such as forms that create incidents).

3. Gather email addresses from the incidents which appear to be loops.  

4. Add these addresses temporarily to the Spam filter email blocklist to break the loops.  Refer to Answer ID 11713: Managing the new Spam Quarantine for information on logging in to the spam filter and configuring the blocklist.

5. Edit or disable the contacts that have invalid email addresses.

6. Wait for a few hours for the all emails created by the loops to be filtered. Remove the active customer addresses from the Spam filter blocklist. 

7. Evaluate your site for the causes of loops and make changes.


There are multiple causes for email loops.  Most unhandled loops include rules and configuration settings and usually all go un-noticed due to agent reports that filter the loop incidents.

  • All loops require an automatic response from CX.  Evaluate the business case for sending automatic responses carefully. If loops are a problem find some other functionality to satisfy your business case.
  • When configuring business rules to send auto-responses, take into consideration the case when a message cannot be delivered to its destination. If the message cannot be delivered and the bounced email message does not invalidate the contact, a loop can occur if the business rule that sends the auto-response is hit every time the bounce message updates the incident. For more details, please see Bounced E-mail message handling.
  • Never send more than one auto-response per incoming email.  Add multiple responses through rules and only include one "send response" action.  Disable automatic Contact Emails in Configuration -> Interfaces.
  • In all rules that send auto-responses, move the "send response" action to a state that is only active once.  Ensure that there are catch-all rules so that all incidents follow the path that sends only one response.
  • Chose the correct level for the mailbox Discard Automatic Responses setting.  Evaluate the common autoresponders and add a REGEX for common response subjects to the EGW_AR_CONS/MODR/AGGR_BODY_FLTR configuration.
  • There is an automatic anti-loop filter that filters any messages above 23 per 12 hour period (EGW_MAX_PER_ADDRESS per EGW_MAX_MSG_DURATION) from the same address.  Do not disturb these configuration settings.  Ensure that external processes that send email to OSvC use the sender's address instead of a single email address. (See Configurations EGW_MAX_PER_ADDRESS and EGW_MAX_MSG_DURATION explained for more information.)