Who is this article for?

Users who want to know more about email sending.

Admin access will be required to complete one of these steps.

In this article, we address common email sending issues, providing troubleshooting tips and solutions to help resolve your concerns.

For more in depth details on email sending, see Email sending FAQs for more information.

1. What address are emails sent from?

While not exhaustive, the following list outlines some common scenarios:

• Password reset emails (for native authentication) originate from the System email address.
• Daily digests, if enabled, are dispatched from the System email address.
• New user (welcome) emails are typically sent by the person adding the user, as per default settings.
• Invitations for reviews are usually dispatched by the owner of the review.

These settings are typically located within the Root workgroup management settings by default.

2. What steps should we take if invitations or welcome emails are not received?

2.1 SPF record

Those responsible for managing the company's domain (e.g., company.com) DNS records, which determine how domain names correspond to IP addresses, can configure the SPF record to specify the IP address through which mail is relayed (typically 50.31.46.70 if hosted). Without this configuration, emails sent from the domain may trigger mail header rules, potentially leading to them being marked as spam or junk by receiving mail servers. The SPF record ensures that the sending server is recognized as a legitimate sender of mail for your company, thereby preventing such issues.

Note: For our hosted servers, SPF records for the system address, used for functions like password resets and daily digests, are already in place and do not require additional configuration.

2.2 Whitelist

Administrators responsible for mail servers can whitelist the IP address (e.g., 50.31.46.70 if hosted) through which mail is relayed on the receiving servers. This ensures that emails relayed from this IP are not classified as spam or junk and are delivered successfully. Although the IP is owned by SendGrid, it is dedicated solely to Ideagen products, with reverse DNS values preventing it from being grouped with other SendGrid addresses on spam blockers.

2.3 Stop Please Review sending mail from our users

1. Navigate to the Root Workgroup Management setting named Emails From System Suffixes.
2. Input the relevant domain (e.g., company.com) into the designated field.
3. List multiple domains separated by a semi-colon if necessary.
4. Use the "*" wildcard to restrict all emails not sent directly by individual users.
5. System-generated emails include default text advising recipients not to reply.
6. Altering the setting carries the risk of losing email replies.
7. Emails originating from integration systems may require separate configuration within those systems.

If you've completed these steps and are still not receiving emails, it's advisable to verify whether they are being automatically filtered to safeguard mail server reputations. If your email is hosted by us, please reach out to Support for assistance.

3. What if emails are delayed?

3.1 Potential reasons for email delays

1. TaraService not running: Emails are dispatched by the background service on the server. If this service is inactive, emails will queue up until it's restarted.
2. TaraService overloaded: The background service handles tasks sequentially. Complex document processing can prolong email dispatch, causing delays.
3. Email server rules: Emails traverse multiple servers for spam and antivirus checks. Each server adds processing time, potentially causing delays.
4. Resent emails: Emails may be resent due to server issues during the initial send, creating the appearance of delay. For instance, a 7-day review reminder might seem delayed if resent.

3.2 Methods to investigate

1. Examine email headers: Review the email headers to track its journey and identify delays at each server along the route.
2. Query PR database: Use the following SQL query on the PR database, replacing '123' with the review ID:

SELECT * FROM T_QueueEntry WHERE QueueEntryType = 'SendEmail' AND ReviewId=123;

This query reveals raw email details, including the DueDate (scheduled send) and EndDate (processing completion), indicating any delays or requeues.

4. Errors in logs

Below are some errors you may find in the TaraService.log relating to email sending:

• "LogEvent: Failed to send email :System.Net.Mail.SmtpFailedRecipientException: Insufficient system storage. The server response was: Too many recipients received this hour
    at System.Net.Mail.SmtpTransport.SendMail("

This is a message received from the mail sending server. This would need to be investigated on the mail sending server.