Error Message: 535 5.3.2 Relaying denied, no client certificate

If the error message “535 5.3.2 Relaying denied, no client certificate” appears when sending via IncaMail MGI, this usually indicates a configuration issue on the outbound or send connector – not that an incorrect certificate was installed, an additional certificate is needed, or that a separate client certificate is required for each individual user.

Note: This error can also occur in certain cases if the certificate is correctly presented but does not contain the clientAuth EKU. If this applies to your situation, please read the following article: Certificate Renewal and clientAuth EKU – Impact on IncaMail MGI

What does this error mean?

The error message means that the IncaMail server did not receive a valid client certificate during the connection setup. Possible causes include:

• The certificate cannot be found on the outbound connector.
• The certificate is not presented correctly.
• The Common Name (CN) of the certificate on the outbound connector does not match the CN on the inbound connector.

What should be checked?

Go through the following points step-by-step to narrow down the cause:

1. STARTTLS and Mutual Authentication

Make sure the following is enabled on your mail server:

• STARTTLS for SMTP communication over port 25
• Mutual Authentication (also called “TwoWay-Authentication”) for TLS encryption – for both incoming (inbound) and outgoing (outbound) connections

2. SwissSign Root Certificate in the Truststore

The SwissSign root certificate of the IncaMail server certificate must be stored in the truststore of your mail server or mail gateway so that the trust chain to IncaMail can be established.

3. Valid Certificate on the Outbound Connector

Check whether the correct and valid certificate is installed and active on the outbound or send connector.

4. Certificate in the “Client Role”

The certificate must be explicitly presented in the client role on the outbound connector. Make sure that “Client Certificate Authentication” is enabled on the connector.

5. Order of the Certificate Chain

The certificate chain must be presented in the correct order:

Client Certificate → Intermediate Certificate → Root Certificate

An incorrect order can cause the IncaMail server to fail to validate the chain.

6. Matching CN on Inbound and Outbound Connector

The Common Name (CN) of the certificate on the outbound connector (sending) must match the CN registered for the sending direction in the IncaMail MGI management portal. Also verify that the CN of the inbound connector (receiving) is correctly entered.

The CNs can be viewed and adjusted in the MGI management portal: 👉 Mail Gateway Integration – Administrator Portal

7. Default Certificate of the Exchange Server

If you are using Microsoft Exchange: Check whether the default certificate of the Exchange server is still active and not disabled. An active default certificate can cause Exchange to use the wrong certificate for SMTP communication instead of the certificate configured for IncaMail.

Summary of the Checklist