Knowledgebase : Technical, Configuration and Devices > Email

Sending emails through Office365 sometimes causes message send failure with an error of 550 5.7.64 TenantAttribution; Relay Access Denied.

  1. In Office Admin go to Exchange
  2. In 'Mail Flow' go to  Connectors
  3. Use the wizard to complete the Connector process.

Make sure the external IP is recorded as an allowed address on the Inbound Connector in Office 365:

InboundConnector2

 

 

 

 

 

 

 

 

 

Also, add the IP address to the SPF record in Public DNS like this:

v=spf1 ip4:, include:spf.protection.outlook.com ~all

One other possible cause of this issue is if the application, when it composes the email, uses a domain other than what is on the accepted domains list. For example, if your tenant has 3 defined domains – BobsGarage.Com, TimsGarage.Com andJohnsGarage.Com and the application sending the email uses a domain like GaragePower.Com, then the connector in Office 365 will reject the email. If you receive the relay error, here is the order I would take for troubleshooting:

  • Verify Sender address is using an accepted Domain (in the application, or message header)
  • Send the email to an internal recipient – check headers for IPs to match in the connector
  • Check your SPF record to make sure all IP addresses are listed as well

 

If emails are not being received by the intended recipient there are a number of items to consider.  Usually, if there is a problem with sending the email out of your mail server, you would receive quite a detailed error message which will include, somewhere in the text, the reason that the emails are not going out of your server.

Check the following:

1. Are the settings for your outgoing mail server correct.
    Use http://mxtoolbox.com/diagnostic.asp to check that your SMTP (outgoing) mail server details are correct.

 

Some emails are being rejected by receiving email servers because the email is not using the TLS encryption protocol.  @gmail.com email addresses are often affected as the Gmail servers aggressively reject non-encrypted emails.

in Setup > Provider > Email  check that your email settings are set to send using the TLS encryption.  Contact Incisive for the security code to edit the settings

You can also use the https://checktls.com website to check your Sending settings and also whether the receiving email server will accept emails from you.

Test your Sending settings https://www.checktls.com/Testsend 

Test the receiving email server  https://www.checktls.com/TestReceiver 

If you are getting the above message when trying to email (using Office 365), please refer to to the following link to have your IT people resolve the issue:

https://docs.microsoft.com/en-nz/exchange/troubleshoot/connectors/office-365-notice

Office 365 by default can only send emails from one email account (the account name).  Errors will occur if you try and send using the operator email address etc.

This may be able to be addressed by configuring Mailbox permissions.  Refer to the article below.  This should be carried out by the hardware technician or client.

https://docs.microsoft.com/en-us/office365/admin/add-users/give-mailbox-permissions-to-another-user?view=o365-worldwide#send-email-on-behalf-of-another-user

  • Try to use the same domain name for your 'From' address, 'Reply-To' address and also the 'SMTP Server Name' (Setup > Provider > Email).  Some email servers will compare the domain names used in the out-going email and if they differ they rank the email for spam accordingly.
  • Add the relevant SPF and DKIM settings to your domain host (talk to your IT provider)
  • Create a free account at Google Postmaster Tools. This will give you the ability to see various metrics that Google/Gmail keeps for your domain name and will let you see if there is a problem. Note: it will take a few days for any stats to appear after you create an account with them.
  • Check that your domain name isn't on a domain blacklist.  You can search for your domain name at MXToolbox. Also search for your domain name at URLVoid.
  • Search for your domain name at BorderWare Watchguard. This will show BorderWare's assessment of the reputation of all IP addresses that are sending emails from your domain name. Any servers that have a bad reputation may have become compromised, or may be sending out emails that have generated spam complaints in the past, and should be investigated. You can do a similar search for your domain name at SenderScore.org.
  • If you're sending from a free email service such as Hotmail, Yahoo, etc. your emails are often treated more suspiciously by recipient spam filters. It is always better - and more professional - to send emails from your own (or your business') domain name. You should never send emails from a Yahoo or AOL email address (as of April 2014) as these domains are now restricted by their DMARC policies. You should also not send from a Gmail email address as of June 2016 due to Gmail's new DMARC policy.
  • If you place links in an HTML email, it is best to not display the actual link (http://www.etc...) in your email. Many email programs now have anti-phishing technology which treats such links suspiciously. If the underlying URL of your link is different from the URL displayed, then your email will be marked as spam by email clients such as Thunderbird. And never use an IP address in a link.
  • Never use URL shorteners in an email.

You can test the likelihood of your email being regarded as Spam by using email checking sites such as https://www.mail-tester.com/   You will be provided with a unique email address like test-ilg76rjn5@srv1.mail-tester.com  that you can put as the patient's email address and then try sending emails from different locations in the Incisive application.  You will be provided with a score.  Anything with a score of -5 or less is likely to be marked as Spam.  Scores of -1 or -2 should see the emails successfully delivered to the recipient's Inbox.

Socket Error: WSAEWOULDBLOCK

NOTE: If this error occurred while trying to establish an FTP data connection, also see this: http://cknotes.com/?p=282

A WSAEWOULDBLOCK error when trying to establish a TCP/IP socket connection indicates one of the following conditions:

  1. A firewall at either the client or server side is blocking the connection.
  2. There is no server listening at the remote host:port to accept the connection
  3. Some other software, such as an anti-virus or anti-spyware program is blocking the connection.
  4. The server was too slow in accepting the connection.  Increase the value of the ConnectTimeout property.

You may open a DOS prompt and try to telnet to the remote host:port to test connectivity. This page provides more information: WSAEWOULDBLOCK

Note: It is impossible for the client to distinguish between any of the cases described above.  It’s similar to if you were knocking on a door and nobody answers — you have no information — you don’t know if the person simply chose not to answer the door, if the person is not home, or if the person simply cannot hear the knocking.  In all cases, the client’s knowledge is the same: there is no response and you have to decide how long you’re willing to wait…

If you are using Apple's icloud.com or me.com SMTP service to send emails from Incisive applications, you will need to create an 'App-Specific' password to use for the Authentication password.

In Apple's words "App-specific passwords are passwords for your Apple ID that let you sign in to your account and securely access the information you store in iCloud from a third-party app. For example, use app-specific passwords with mail, contacts, and calendar services not provided by Apple."

https://support.apple.com/en-us/HT204397

If you follow the links in the above page and log into your apple account you can find the option to Generate Password...  for App-Specific Passwords.

5Y9znGE2uBwAAAAASUVORK5CYII=

You can have up to 25 App-Specific passwords.

The SMTP settings you need to use are available for your icloud.com or me.com email address from the following URL

https://support.apple.com/mail-settings-lookup

Emails can be sent through Office365 email servers using either:

  • Authenticated Client SMTP, or
  • SMTP Relay (using an Outlook connector)

In the new 409.6 release of SPM & PHM Incisive have made some changes to allow the SMTP Relay correctly communicate with Exchange Online (Office365).

If you are using 409.4 or earlier you will need to use the Authenticated Client SMTP option. 

SMTP Relay

In SPM/PHM (release 409.6 or newer) configure the options in Setup > Provider > Email   (for each Provider)

SMTP Server Settings

SMTP Server Name:    <your-domain>.mail.protection.outlook.com
SMTP Encryption:       TLS
SMTP Server Port:      25  (needs to be an open Outgoing port)

Account Authentication

SMTP Authentication NOT required

Authenticated SMTP

Authenticated SMTP requires authentication to be enabled at the Tenant and the Mailbox level.  It is disabled by default.
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission

In SPM/PHM configure the options in Setup > Provider > Email   (for each Provider)

SMTP Server Settings

SMTP Server Name:    smtp.office365.com
SMTP Encryption:       TLS
SMTP Server Port:      587  (needs to be an open Outgoing port)

Account Authentication

SMTP Authentication required
Authentication Method:     AUTO or LOGIN
Account Username:          The email address of a user account
Account Password:           The password for the user account

Troubleshooting

  • Use the Check Connection and Send Test Email.
    Look at the log as it will explain the problem.  Scroll to the bottom of the log for the most recent entry.
  • Check port 25 or 587 are open  (Use Telnet if you are not sure)
  • Check .NET Framework 4.8 or newer is installed.
  • Get your Office365 administrator to go to the Azure Active Directory and check the Sign-In logs to view the connection attempts.

Setting up Gmail as an SMTP account for a Provider

 

To setup Email for a Provider using a Gmail account, go into;

-Setup   -Provider   -Email    (as below).

 

When you try to Test Connection it will fail and the Gmail account will receive a Security alert.

 

You will need to get the client to login to the Gmail account to do the next steps.

  1. There will be a security alert email in the inbox.

2.   Click on “Yes it was me” and you will go to the Less secure app blocked Click on “Learn more”

3.    From the Less secure apps page, click on “Less secure app access” link.

4.   Change the setting to ON.

5.    If you retry Test Connection, it should now allow emails through.

  • With upcoming security changes by Google, new application connections will not be able to be made after July 2020.
  • Existing connections will stop after Feb 2021.

This is the link for reference on how to setup SMTP Relaying with Office 365
How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Docs

If they are using “Direct Send” option, it should not work for sending emails to external addresses like Gmail. Direct Send should only be used to send emails to your own Office 365 tenant. These are the direct send SMTP Settings:

Graphical user interface, text, application  Description automatically generated

If you want to send emails from Office 365 to External Domains, then they must use either “Authenticated SMTP” or “SMTP Relay”. If you use “Authenticated SMTP”, then they need to make sure the account they use is not blocked to use this protocol. Places to check are:

  1. Azure AD Conditional Access or Azure Security Defaults (Azure Active Directory security defaults | Microsoft Docs)
  2. Authenticated SMTP on the Mailbox Level via Exchange Admin Centre or Microsoft 365 Admin Centre.

 

We recommend to use “SMTP Relay” method if they want to email outside of Office 365 and these are the steps they should look into get this working properly and be trusted by external email servers:

  1. Add the IP Address to Exchange Connector
  2. Add the IP Address to SPF record
  3. Enable Dkim in Office 365
  4. Have a Dmarc record (Preferably the policy is set to either quarantine or reject)

 

 

If the Test Email or Test Connection functions are not working or emails can't be sent and an error appears "ActiveX component not creating instance of object", it is possible that the Chilkat files are not correctly installed or registered.

Using RegisterBatch.exe may not help.

Use ChilkatSetup.exe (which is in the \spmwin directory) to install the necessary files and register them.

Make sure the virus checker and UAC are turned off first and you are using a login with Administrator rights

Go to this site and use the SMTP test option.  It has a very good set of diagnostic tools.

https://mxtoolbox.com/NetworkTools.aspx?abt_id=AB-402&abt_var=Control

It will report information regarding the connection and transaction time.

 
The MX  test is also good for diagnosing email problems.