Use CipherMail Appliance as encrypt decrypt gateway with mailserver

No problem :slight_smile: docker sometimes complicates things.

You should add the changes to the mailcow provided postfix config files. You should also add additional configuration to docker-compose to make sure that port 10026 is exposed otherwise CipherMail gateway will not be able to connect to Mailcow (on the reinjection port).

Ok, I will do so and come back to you and keep you informed.
Thank you very much up to this point.

As far as I can tell,
signing and encrypting works fine now.
I am currently in the process of documenting the installation and setup of both Mailcow and Ciphermail.

I would like to thank you very much for your time and help.
Greetings Thomas

Good to hear you got it working.

You should also check whether Mailcow checks SPF and DKIM after the email was decrypted/encrypted by the gateway.

Decrypting an email results in changing the body of the email and therefore invalidating the DKIM signature. SPF is a related issue. Because the IP address of the CipherMail gateway is not on the SPF list of approved IP addresses, SPF might fail (if SPF records are configured by the sender).

You therefore need to tell Mailcow to skip SPF and DKIM checks when the email is received from the CipherMail gateway. It’s best not to completely disable all checks because you might want to scan decrypted email for viruses.

thank you so much, your information is so valuable.
I have not thought about this at all.

And the worst, you are right.
I just looked at the DMARC report and it says ‘SPF pass’ and ‘DKIM failed’.
This is my report

<?xml version="1.0"?>
<feedback xmlns:xsd="" xmlns:xsi="">

The only thing I can do ( and have done )is put the Ciphermail gateway as an ‘exception’ in Mailcow, so that Ciphermail can send to Mailcow without checking for spam etc.

At the moment I have no idea how to disable the ‘DKIM and SPF check’ on the Mailcow server.

At the moment I have no idea how to disable the ‘DKIM and SPF check’ on the Mailcow server.

I guess you need to configure this in rspamd. Perhaps you can configure a different rule-set based on IP address of the sender. I suggest to ask this on the Rspamd Support page.

Hello Martijn,

the rspamd forum seems to be a bit badly frequented.

I tried to dig through the documentation today.
Still I am not much smarter.
That would be a real pity if it would fail now because of such a small thing.
I’ll let you know when I know more.

i am still in discussion with rspamd members, the documentation is just too incomprehensible for me, But, reading again about our discussion…
You said encryption changes the ‘body’ of the mail and thus invalidates DKIM.
There is nothing the mail server can do about that, right? Wouldn’t the ciphermail gateway just have to ‘add’ this DKIM code again?
I’m thinking about this all the time, an exception for the CM gateway won’t prevent the DKIM code from being changed or invalidated, right? Or am I completely wrong here? Maybe this can’t be handled via an exception at all, what do you think?

I am looking into a similar setup myself, so hence I hope you guys don’t mind me chipping in…

I guess technically you could sign inbound emails again, but only with your own private key because you don’t know the private key of the original sender. And if you sign all inbound emails yourself anyway, you may as well just ignore the whole DKIM checking because the check will always be valid no matter if the original one was bogus.

There is no exception possible here, the content of a decrypted email is technically different than the content of the encrypted one, hence the DKIM hash value of the two pieces of text will have to be different.

The options as far as I can think of are:

  1. Ignore DKIM altogether (not good)
  2. Do as Martijn mentioned: DKIM (SPF) checks need to happen on the original email / before decryption.
  3. Add a flag to decrypted emails so you can tell RSPAMD to not do DKIM checks on such such emails
  4. Only encrypted emails get forwarded to CipherMail

Option 2:

  1. Inbound email arrives at mail server
  2. RSPAMD does it’s SPF/DKIM checks = rejects or marks as spam
  3. Email is redirected to CipherMail (breaks SPF)
  4. CipherMail decrypts and sends the email back to mail server
  5. Mail server hands over email to recipients inbox

will have the theoretical downside that RSPAMD can’t look at the actual content of an email to determine the spam level, because the email will still be encrypted when it does it’s assessment. But in my opinion this case can be safely ignored, I haven’t seem spammers using encrypted emails.

Option 3

  1. Inbound email arrives at mail server
  2. Email is redirected to CipherMail (breaks SPF)
  3. If encryption is necessary CipherMail decrypts (breaks DKIM)
  4. CipherMail sends the email back to mail server
  5. RSPAMD ignores email because of flag
  6. Mail server hands over email to recipients inbox

This could be an email header flag added by CipherMail or simply the subject line tag ([DECRYPTED] ?) which CipherMail can be configured to add automatically.
But I don’t know how to set that RSPAMD rule,

Option 4

  1. Inbound email arrives at mail server
  2. if email is encrypted → redirected to CipherMail (breaks SPF)
  3. CipherMail decrypts (breaks DKIM) and sends the email back to mail server
  4. Tell RSPAMD to ignore all emails coming from gateway
  5. Mail server hands over email to recipients inbox

Because of the redirect breaking SPF I’d say option 2 or should be the preferred one.
Option 4 has got the additional benefit to reduce load on the gateway as it only has to deal with encrypted emails.

All of this is fairly straight forward with Office365 and Gmail because they offer a rules engine to pass things back and forth. With postfix we need to do it ourselves.

t’s great that someone is still involved here.
I can hardly understand that there is so little response, from my feeling I would have expected that quite a few come forward and say, look so I have solved it.
I am also in contact with the guys from rspamd.
Disable DKIM / SPF or whitelist network · Discussion #4363 · rspamd/rspamd · GitHub, but either I don’t manage to ask the right questions or they just don’t really want to help, which I can understand, it’s all voluntary.

From what you explain, solution two seems to me to be the best.
Unfortunately I do not understand how to configure rspamd properly, have read through a lot.
But what I always see in my checks is that SPF is not a problem, only DKIM, I do not know if you know this link.

Let’s work together on the problem, I may have less mail server expertise here, but could provide really good documentation from Mailcow + Ciphermail, because it’s done except for that last one point.
What do we want to do?


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


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.


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


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 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.


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.

But the DMARC part at least is under the control of the owner of the mailserver, right?
If @taumeister’s Mailcow setup isn’t looking up the senders DMARC settings nothing would happen.

I have now configured my own postfix/RSPAMD mail server along the way you recommended at the top of this thread and things seem to work.

Outbound looks good, the 3rd party email provider I use for testing is happy with my DKIM and SPF settings.
Inbound is a bit more difficult, I need to look into the RSPAMD header some more to understand if it’s happy with the incoming SPF/DKIM or not. There’s a DMARC module for RSPAMD which I haven’t configured yet. DMARC module

But I like this change already, “hiding” the gateway is a bit more complicated but also a lot cleaner as now only the mail server needs to be exposed to the outside world.

Do you use the Enterprise Version of Ciphermail? If not, I’d say Martijns engagement here is voluntary as well. Mine certainly is…

I am not using Mailcow but rather a native install of postfix/RSPAMD/Dovecot, and so far it looks like things are working.
I have to do some work on the Inbound side, don’t really understand what RSPAMD is telling me in my email headers, and want to install the DMARC module. DMARC module

But back to your issue, is outbound working for you? Including SPF and DKIM?
As far as inbound is concerned, what does the RSPAMD header say? Is it even checking?

By the way, from my experience you need to work with test emails and look at the email headers, the DMARC report you posted higher up is only a summary, you need exact data.

Guys, I have to say this is way beyond my capabilities.
I wouldn’t even know exactly where to look and how.
I can tell you about virtualization, microservices and infrastructure, but not about mail servers.

What I can say is that Mailcow also uses postfix dovecot and rspamd.
For rspamd there is also a web interface.

In my case it is a bit different. Inbound and outbound work absolutely perfect, as long as Ciphermail comes into play (I realize that this is not directly due to Ciphermail), by encrypting, the mail is changed.

If I understand Martijn correctly, I have to make sure that DKIM is attached AFTER the mail has been encrypted or decrypted, or I have to ignore it. Unfortunately I don’t know how to do that yet.
This is really annoying…

Is your config in combination with Ciphermail encryption or standalone postfix?

Email is complicated I am afraid…

I’d recommend to tackle outbound and inbound emails separately, otherwise you will get lost in all the details.
Start with outbound:

  1. Send an unencrypted email to a secondary email account you control, e.g. Office/Exchange365 or Gmail.
  2. Use the associated web client of that service and check the header of the email.

The header will show you which hops the email passed through, and if SPF/DKIM checks were successful.
You will also see what the recipients spam engine thinks of your email, here’s an example of RSPAMD

Once you got outbound all set up start sending emails from external to your main account and review the header again.
You will again see which hops the email went through until it arrives in your inbox, and somewhere will be your RSPAMD report which shows what checks were run and what the result is.

This tool is quite good to check your parameter, Network Tools: DNS,IP,Email
You can also copy and paste your email headers to help with analysis.

Always with CipherMail

That is correct, but before you make changes you first need to get visibility into what the current situation is. Maybe it’s working already?

To check if your outbound email is signed after the email is encrypted send an email to an external account and check the email header at the recipients end.
If the receivers email server flags DKIM=pass you are good.
This is the authentication section of an encrypted email I just sent to one of my test accounts.

If your read it bottom up:

  1. A DKIM signature was applied
  2. The email passed through my gateway on the way out
  3. Hit my mail server
  4. Hit the recipients mail server
  5. Recipients mail server checked DKIM and is happy → DKIM=pass

No way around analyzing email headers when it comes to this…

phew…what a journey…
Ok, i will check this on weekend and see how far I come.

Anywhay, thanks a lot for your input so far and for yours Martijin, too.

Hopefully I will get my 3 Mailserver Ciphermail Combos on the road some day.
If it is ok, I will keep you informed.