SPF and DKIM issues are not CipherMail specific. Any mail server which forwards email for internal and external domains will have to deal with SPF DKIM issues.
Since encrypted email can contain a virus, itās best to scan an email after decryption. This would imply that anti virus/spam scanning should be done after decryption. However scanning for spam is best done before decryption because the email can then be rejected before acceptance. Also SPF checks require the original incoming IP address.
The best setup, in our view, is therefore a setup where the mail server first receives the email and at the same time checks the email, then forwards it to the CipherMail gateway, and then the CipherMail gateway forwards the email back to the mail server (see discussion above).
To discuss the DKIM/SPF issues, itās best to split up the problem into two parts.
Part one discusses email sent to by external senders to internal recipients (lets call this incoming).
Part two discusses email sent by internal senders sent to external recipients (lets call this outgoing)
For the discussion letās assume that every domain, internal and external, configures SPF and signs email with DKIM and that every email is S/MIME encrypted.
Incoming email
DKIM
Decrypting email will break the existing DKIM signature because the body and headers of the email are replaced. Itās therefore important to validate the DKIM signature before applying any changes to the email. After decryption, the CipherMail gateway sends the email back to the anti-spam system. The problem now is that DKIM validation fails because the body was changed. Removing the faulty DKIM signature will not solve the issue because the sender might have configured DMARC (which makes DKIM more or less mandatory). DKIM check should therefore be skipped when the mail sever receives the email back from the CipherMail gateway.
Unfortunately there is no other option. You cannot DKIM re-sign the email because the domain is not under you control and you therefore have no access to the DKIM private key.
The best solution is to use The Authenticated Received Chain (ARC) Protocol (RFC 8617). However this is not yet supported by CipherMail.
Until ARC is widely supported, the only solution is either to not anti-spam scan the email after encryption or scan but skip DKIM.
SPF
Because the email is forwarded by the CipheMail gateway after decryption, the sending IP address if the IP address of the gateway. SPF check therefore fails after forwarding (unless the ant-spam check checks the received headers and not the IP address directly). SPF validation should therefore be done when the email is received for the first time but not when the email is forwarded by the CipherMail gateway.
Outgoing email
DKIM
Outgoing email should be DKIM signed after the email was handled by the CipherMail gateway, i.e., after encryption because encryption changes the email.
It does not matter whether the mail server of the CipherMail gateway DKIM signs the email just as long as DKIM signing is done after encryption. It should also not be an issue if the email is DKIM signed before encryption just as long as DKIM signing is done again after encryption.
Because you own you internal domains, DKIM signing should not be an issue.
SPF
SPF should not be an issue because you can add the IP address of the CipherMail gateway to the SPF records.
Other options?
There are other options if non of the above work but they have their own issues,
One option is to rewrite the sender domain using SRS. This will rewrite the sender to a domain you own. The downside of this is that your inbox now shows that every external sender comes from the same domain.
RSPAMD
I know that you configure RSPAMD to skip DKIM and SPF when the sender IP is on some white-list. Unfortunately I do not have any experience with RSPAMD. Iāll see whether I can find the time to experiment.