It is likely that the emails are being treated as spam by the recipient email system and are either in a junk folder or have been blocked altogether.


As a result of stricter spam filtering by some email providers and email servers, some of our ‘system’ type notification emails (which include client portal invitations for client portal access, new user invitations, Query Builder downloads and password reset emails) may start to find their way into junk folders, or be blocked entirely.


This can affect your own firm’s users or your client’s contacts accessing a Client Portal. In most cases, the issue is caused by email filtering at the recipient’s mail server level. 


Please note that this does not affect day-to-day emails which use an alternative system (Microsoft 365/Graph API).


These notification emails are sent via Amazon SES (our secure transactional email provider). If a recipient mail server actively rejects the message during delivery (for example, due to an invalid address), we receive a bounce notification. However, if the recipient server accepts the message and then filters, quarantines, or blocks it internally, we do not receive a bounce notification. If no bounce is recorded, the email was accepted by the recipient server (it may still be held in quarantine or blocked by internal filtering rules).



There are several steps to the solution, any or all of which may help:


1. Check Junk/Spam and quarantine systems: The recipient should check their Junk folder and any email quarantine system used by their organisation.


2. Configure DKIM (recommended for your firm): Set up your firm's DKIM settings on your company website- this provides a level of assurance to email systems that the email is genuine and should not be treated as spam. If you have an IT Team, they will be able to action the changes for you, but if not, it is a fairly simple job for the person who administers your website to do.
 

We have a detailed article here: Setting Up DKIM For Your Email Domain On Ezekia and a short video that explains the whole process too, and naturally you can contact the Ezekia support team if you have any problems.

3. Whitelist the sending domain: Have the recipient company (so it may be your email system or a client's system) whitelist the ezekia.com domain on their Outlook/Exchange email server (or have them whitelist your own email domain if you have successfully set up DKIM in step 1).

4. Whitelist our SES sending IP addresses: The recipient company can whitelist our Amazon IP addresses in their Outlook/Exchange server. Our system emails come via these IP addresses:
54.240.104.160
54.240.104.161
54.240.104.162

5. Request a message trace: If the issue persists, the next step is for you to ask the recipient company's IT team to do a message trace on their mail server to see what happens to the notifications. They may have a rule that blocks it if it comes from Amazon, for example.




Temporary workaround: 

If appropriate under your or your client's organisation’s IT and data policies, you could use a personal email address temporarily for the contact (such as Gmail) as these tend to have less rigorous spam filters. An alternative email address (such as a dedicated Outlook or Gmail address) could also be created specifically for portal access. This is not a GDPR restriction issue, but organisations may have internal policies governing the use of personal email addresses for business systems.

Sending priority for Client Portal invitations:


If both MS 365 Outlook integration and DKIM are enabled, MS 365 will take priority. Client Portal invitations are sent using the following priority logic (from most to least preferred):
1: MS 365 Outlook integration enabled and valid → Sent via Microsoft 365 (Graph API)
2: MS 365 Outlook integration not enabled or expired, but DKIM configured → Sent via your domain (your chosen DKIM email address, delivered through Amazon SES)
3: Neither MS 365 nor DKIM configured → Sent via default no-reply@ezekia.com (Amazon SES fallback email address)