This article details technical questions and answers regarding the Templafy Email Signature Server (ESS).
Templafy relies on a Kubernetes architecture, and the native cloud service of Microsoft Azure Kubernetes service also known as AKS for the Email Signature Server. AKS allows for having orchestration layers on the server, load balancing emails between the servers, and offers a highly available environment. Templafy Email Signature Server solution supports the cluster auto-scaler in AKS to automatically create additional servers in the event of a high load.
If the messages are encrypted before they reach the Email Signature Server, the emails will not be processed by the Email Signature Server and will be sent on to the final recipient without a signature being appended by the Email Signature Server.
If the email is encrypted by a mail flow rule configured in Exchange Online Admin Center, and Templafy Email Signature Server is the prioritized above it, the email signature will be attached before the email is encrypted by a subsequent mail flow rule processing.
NoteThis also applies for AIP and MIP labels as they rely on the email encryption mechanism. |
Exchange Online is configured with Outbound and Inbound connectors directing emails from and to your specific Email Signature Server.
- The Outbound connector is configured for Mandatory TLS negotiation. Emails will always be sent to the Email Signature Server after a secure TLS connection is negotiated using the certificates configured during the implementation.
- The Inbound connector is configured, by Microsoft default and as used by the Email Signature Server, to use Opportunistic TLS negotiation. The Email Signature Server will endeavor to establish a secure TLS connection to Exchange Online with this connector to send the processed emails back using the certificates configured during the implementation.
Templafy Signature Server doesn't have any size limit for messages, but it is recommended to set an exception rule to omit message size >150MB to comply with the size limit of Exchange Online.
If users can send large attachments while bypassing Templafy Email Signature Server but cannot otherwise, then it is likely that there is a connector limit in place.
NoteFor any message size limit, the value needs to be 33% larger than the actual size enforced because of the Base64 encoding usage for sending e-mail attachments.
|
If your emails were routed through Templafy ESS, they will appear twice on the Message trace search results list. This happens because a message is first sent to the Templafy ESS via the outbound connector (this is indicated by the first entry in the report). Then, after being processed by ESS, the message is sent back to Exchange Online via the inbound connector and finally sent to the recipient (this is indicated by the second entry in the report).
The Email Signature Server is optimized for high load. If incidents occur and the connection to the Email Signature Server is not available or the server is unable to process requests, emails will defer in the Exchange Online queue. Exchange Online retries sending these queued emails starting at 15 minutes, for up to 24 hours. The emails will be sent as soon as the service is restored to the Email Signature Server, alternatively the sender will receive a Non-Delivery Receipt after 24 hours.
You are encouraged to review the Microsoft Service Health for any reported incidents for your subscription that involve Exchange Online. These incidents may involve impact to mail flow and delivery not necessarily related to the Templafy Email Signature Server.
Troubleshooting steps:
- Check the message trace for one of the e-mails in the Microsoft 365 Exchange Admin Center.
- Check that the connectors in the Exchange Admin Center are still valid and active.
- Check the Resource Health for the Email Signature Server AKS cluster in the Azure Portal
- Bypass the Email Signature Server by disabling the mail flow rule in the Exchange Admin Center.
When sending an email to a dynamic distribution group, a sender may receive an NDR that looks like this: 550 5.4.1 Recipient address rejected: Access denied
Dynamic distribution groups do not sync to Azure and are therefore treated as external recipients by Microsoft's default DBEB mechanism. This is a Microsoft limitation and is true regardless of Email Signaure Server.
Comments
Article is closed for comments.