Initial situation:

Mails between two SEPPmail Managed Domains cannot be read on the recipient side. The mails have "*** SEPPmail Domain Encrypted Message **" in the subject and Microsoft Outlook reports:

 

Your digital ID name cannot be found by the underlying security system.

 

The mail cannot be read by the recipient.

 

Possible reasons:

a)The incoming mail was not routed via the SEPPmail Secure E-Mail Gateway.

b)The rules for an ExO connection do not exist, are faulty or outdated or have been adapted so that certain mails are no longer routed to the SEPPmail Secure E-Mail Gateway.

c)The private key of the corresponding domain certificate is not (any longer) on the SEPPmail Secure E-Mail Gateway that processes the incoming mail. This can be the case after importing an (older) backup or after a migration if the key was not transferred, or the private key belongs to a different domain. This happens mainly when old mail domains are to be replaced, but mails are still to be received for a certain time. Within the mail server, the recipient addresses of the old domains are then rewritten to the new address, even before they pass through the SEPPmail Secure E-Mail Gateway. As a result, the certificate no longer matches the domain and decryption fails.

 

Possible tests:

to a) The mail cannot be found in the log of the SEPPmail Secure E-Mail Gateway or in the message search of the cloud.

to b) The message trace in ExO shows that a rule applies which does not forward the mail to the SEPPmail Secure E-Mail Gateway.

to c) The log of the mail is available, but the mail could not be decrypted (Log: "S/MIME encrypted, but could not decrypt with domain certificate"). The rewriting of the addresses can be recognised by the addresses in the Envelope and in the From Header. In such a case, these are different (my-domain-old.com --> my-domain-new.com).

INFO 14:29:00 Mail from: abcd@google.com to: some.name@my-domain-old.com

INFO 14:29:00 Message To is some.name@my-domain-new.com

 

Solution:

a)Check and adjust the routing so that all incoming mails go through the SEPPmail Secure E-Mail Gateway. Should the SEPPmail Secure E-Mail Gateway no longer have regular mail flow, the domain must be deregistered with us (see also this warning).

b)Check the setup of the rules and their exceptions, eliminate causes (e.g. faulty SPF, recognisable in the header of a mail as spf=fail)

c)If the private key of the domain still exists, it is imported into the domain. The same can happen in the case of a transfer. The domain key of the old domain can be imported within the new domain.
If it is a deliberate change of domains, it is recommended to completely deactivate the old domain and to reject the incoming mails with reference to the new domain.
If it is an alias domain, this procedure may help.