Oracle Cloud Port 25

hisdarkmaterials23

Hi everyone,

I am currently running Mailcow on Oracle Cloud (Ubuntu VM). As you probably know, Oracle restricts outbound SMTP traffic on port 25 by default, and their official solution relies on using their Email Delivery service or customizing Postfix as described here:
https://blogs.oracle.com/cloud-infrastructure/post/why-shared-ips-are-the-right-place-to-start-with-oci-email-delivery

The problem is that Mailcow is an out-of-the-box Docker-based solution and doesn’t provide an easy way to apply the kind of Postfix customizations Oracle requires.

I’d like to ask:

Has anyone successfully integrated Mailcow with Oracle’s Email Delivery service?
Alternatively, have you found a way to make Mailcow send emails using a different port (other than 25) that works on OCI?
Or maybe there are other workarounds you are using to bypass this limitation?

Any advice or shared experience would be greatly appreciated.

Thanks a lot!

sistemistaitaliano

hisdarkmaterials23
Hello same problem here, having a ampere a1 istance. PTR record obtained without problemtrought service request but the port 25 outgoing is a very difficult to obtain. I have integrated Mail Delivery but the prtoblem for mailbox rule remain because mailcow doesnt use mail delivery for these

esackbauer

Why it is not possible?
Its actually quite easy to configure relayhosts, you can do it in the mailcow admin UI:
https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-relayhost/
And I think you are not bound to use Oracles Relay services, you can use others with free tiers like smtp2go as well.

friendsfan

Hope a late reply is ok, but just in case other ppl stumble on that problem as well….

You can just open a ticket with Oracle support “Request a limit increase” and ask them to open Port 25 outbound. Worked for me without any problems and no need to setup a relay host.

You have to contact them anyway most likely for setting up PTR Record for IPv4/6.

hisdarkmaterials23

friendsfan

the support replied to me that cannot open 25 port, what about PTR?

friendsfan

hisdarkmaterials23

Strange, they did it for me without any question. Did you “start” with the dedicated option “Request a limit increase” in your help Section (upper right corner questionmark symbol when you logged in)? Didi they gave an explanation why they didnt do it?

Regarding PTR: You need to set the PTR (rDNS) so your IP points to your mail Domain, otherwise your sent mails will get rejected most likely by many servers. And AFAIK only Oracle support can do this, no option to set this up yourself.

mlcwuser

hisdarkmaterials23 he support replied to me that cannot open 25 port, what about PTR?

If they won’t open port 25, then you don’t need a PTR from them either.

You have a few options:

Switch to another VPS provider and set up Mailcow there. This very likely costs money.
Set up a relay on another VPS. This usually costs less, because the relay host doesn’t need as many resources as running Mailcow directly.
Use a service like Mailgun. These services can be free up to a certain volume, but costs money once you exceed the limits.

In any case, the PTR record has to be set up for the host that actually sends the emails to other mail servers. That means Oracle would be out of the picture — they wouldn’t need to open port 25 or set the PTR record.

hisdarkmaterials23

friendsfan

i cannot setup PTR in my DNS?

thanks

friendsfan

hisdarkmaterials23

It may be possible with Oracle, i am not sure. The Network setup possibility there are way above my pay grade frankly….
So i just wrote a support ticket.

But there is a difference for sure, if you just setup a PTR Record were you manage your DNS settings for your Domain Name (which for me would be Cloudflare).

PTR needs to be set by your hoster, ISP etc., either via some Settings Option or manually with a ticket.

Maybe someone with more technical insight can explain it better…

EDIT:

From the Oracle Help Sites: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/reverse_dns.htm

esackbauer

sistemistaitaliano
Use a relay service like smtp2go
In general you should select a proper provider for mailcow. Mail services are usually not stable or possible on free tiers of VPS providers.

sistemistaitaliano

esackbauer hello thx
I already use Oracle mail delivery, but the problem Is that without Port 25 directory opened the mailbix rule (lime foreste) doesnt works

esackbauer

What kind of rule? Can you tell us more specific and in detail?

sistemistaitaliano

esackbauer
To be more specific, the issue arises when you deploy Mailcow on a VPS where outbound port 25 is completely blocked, forcing you to route all outbound traffic through an external relay like Oracle Cloud Infrastructure (OCI) Email Delivery via a Sender-Dependent Transport or a global transport map.
The setup works perfectly for standard inbound and outbound mail, but it completely breaks automatic forwarding, Sieve rules (SOGo filters), and BCC maps whenever an external email (e.g., from a @gmail.com sender) hits a local mailbox and triggers an automated forward to another external address.
Here is the technical breakdown of the failure modes:

The BCC Map / Postfix Alias Failure
When a Recipient map or alias is triggered, Postfix duplicates the incoming message to the forwarding destination but keeps the original envelope sender intact (e.g., from=external-user@gmail.com).
Because the sender domain is @gmail.com and not your local authenticated domain, Postfix bypasses the Sender-Dependent Transport map.
It attempts to connect directly to the destination MX server using port 25, which immediately drops into a Connection timed out due to the VPS port block.
The SOGo / Sieve Filter Forwarding Failure (The 535 OCI Block)
If you switch to SOGo’s “Forward message to” Sieve rule, Postfix handles the routing correctly because SOGo changes the Envelope From to your local domain (e.g., info@yourdomain.com). This forces Postfix to route the mail through the Oracle SMTP relay over port 587.
However, it fails at the very end of the SMTP transaction because Oracle Cloud enforces an extremely strict anti-spoofing policy. At the end of the DATA command, OCI inspects the Body From (Header From) inside the message payload.
Since the visible header is still From: external-user@gmail.com, Oracle rejects the email with the following hard bounce:
535 Authorization failed: Body From address external-user@gmail.com not authorized (in reply to end of DATA command)
The Root Cause
Essentially, without SRS (Sender Rewriting Scheme) enabled globally to rewrite both the envelope and mask the header headers, any native mail forwarding mechanism in Mailcow becomes unusable when paired with a strict third-party relay like Oracle Email Delivery.
Since setting up SRS globally in Mailcow via the UI isn’t exposed out-of-the-box in the main routing panels, and strict relays reject original headers, this specific combination prevents standard mailbox rules from operating out of the box.
Hope this clarifies the scenario!

esackbauer

Have you tried a different relay service like smtp2go? It seems Oracles relay is too picky.
What you are telling us is a general problem with forwarding rules, which is not specific to mailcow. Avoid forwarding rules at all costs! Try to use imapsync if possible. Or use a proper VPS provider…

sistemistaitaliano

esackbauer
Hello i Will try smtp2go but forwarding rules are the base of a. Email service and Is necessary to provider these fetures to the users.
Impasync Is not encrypted

esackbauer
hello account smtp2go created same problem,:
1) i have a mailbox foo@mydomain.com where is configred a forward rule to a mailbox @gmail.com
2) Sent an email from gmail account to foo@mydomain.com (mailcow)
3) mail received but not forwardwed to gmail account, response is:

host mail-eu.smtp2go.com[172.233.58.206] said: 550-From
header sender domain not verified (gmail.com) 550-On your Sending >
Verified Senders page 550 verify the sender domain or email to be allowed
to send. (in reply to end of DATA command)

esackbauer

sistemistaitaliano Impasync Is not encrypted

Why do you think that? imapsync supports STARTTLS and TLS.

It seems you will always get problems with forwarding, as relay services will block them, so better to have a proper mail server being able to send from its own IP. However then still depending on the receiving server it may be that forwarded mails will be rejected.
You could investigate further in this issue about SRS:
mailcow/mailcow-dockerized2418

sistemistaitaliano

esackbauer I was referring to the fact that impasync saves passwords in clear text, not traffic. If you have a traditional tax server with outgoing port 25 and it’s properly configured with SPF, DKIM, and DMARC records, you can create forwarding rules without any problems.

esackbauer

How would you then include your mailserver in googles SPF record? If you are forwarding Gmail mails?
The only way is SRS, and as the github issue shows that requires a lot of work.

sistemistaitaliano

esackbauer
Hello i have modoboa mail server on another ampere a1 instance on Oralce Cloud Amsterdam where the port 25 in outgoing is opened.
A mailbox is configured for forward messages that contain some words in Subject
the record spf is: “v=spf1 ip4:<PUBLIC IP OF ORACLE INSTANZE> mx a _all”
the dmarc is: v=DMARC1; p=none; rua=mailto:dmarc@mydomain.it,mailto:04d2386f@mxtoolbox.dmarc-report.com; ruf=mailto:04d2386f@forensics.dmarc-report.com

The rule works perfectly as you can see on screenshot

esackbauer

sistemistaitaliano Hello i have modoboa mail server on another ampere a1 instance on Oralce Cloud Amsterdam where the port 25 in outgoing is opened.

As I said, this is what you need, a proper VPS that has port 25 open, so you are not relying on a relay service which may block it (for good reason).

sistemistaitaliano

esackbauer exactly.

sistemistaitaliano

esackbauer
Hello,
for your info i have found a way to working with rules:

Confirming, I hit and fixed this exact same issue. If you’re running mailcow (or Postfix in general) behind an SMTP relay that requires verified senders — this happens with Oracle Email Delivery, SMTP2GO, Amazon SES, SendGrid, Mailgun, and basically every modern relay service — redirect/forward rules set up in webmail always fail with something like:
550 From header sender domain not verified (external.domain.com)

Root cause: when a user forwards mail (e.g. from info@yourdomain.com to Gmail), the message keeps the original external sender’s address in the From: header (whoever originally wrote the email). That domain obviously can’t be verified with your relay because you don’t own it. The relay rejects it as an anti-spoofing measure.

Fix: rewrite the From: header on outgoing mail using Postfix’s smtp_header_checks, but only when the sender isn’t one of your own domains — so regular mail from your users is left untouched, and only forwarded mail gets rewritten.
File to create: data/conf/postfix/header_checks_forward.pcre
/^From:\s(?!.@(?:yourdomain1.com|yourdomain2.com))(?:“?([^”<])“?\s)?<?([\w.+-]+@[\w.-]+)>?\s*$/i REPLACE From: ”$1 (fwd)" noreply@yourdomain1.com
Replace yourdomain1.com|yourdomain2.com with all the domains you host in mailcow, separated by |, with dots escaped (.). The final address (noreply@yourdomain1.com) needs to be an approved/verified sender with your relay.

File to edit: data/conf/postfix/extra.cf (just add the line, don’t touch anything already there)
smtp_header_checks = pcre:/opt/postfix/conf/header_checks_forward.pcre
Steps:

Create the .pcre file with your domains
Add the line to extra.cf
Test the regex before restarting:

docker exec -it <postfix_container_name> postmap -q “From: External Name user@external.com” pcre:/opt/postfix/conf/header_checks_forward.pcre
Should return a REPLACE From: … line. Test again with a sender from one of your own domains — it should return nothing (no rewrite).

Restart Postfix only:
docker compose restart postfix-mailcow

Users can now freely set up redirect/forward rules in webmail to any external address (Gmail, Outlook, etc.): the sender gets rewritten automatically and the relay will stop rejecting them.

Note: the recipient will see your domain as the sender (with the original name in parentheses, like “External Name (fwd)”) instead of the true original sender — that’s the necessary trade-off to comply with the SPF/DMARC alignment rules any modern relay enforces. There’s no way around it if you’re using a verified relay instead of direct port 25.

UPDATE 05/07/2026 17.52
Using this in /opt/postfix/conf/header_checks_forward.pcre is better because you can see real sender in Name (see screenshot)

/^From:\s(?!.@(?:domain1.eu|domain2.net|domain3.it|domain4.it))(?:“?([^”<])“?\s)?<?([\w.+-]+@[\w.-]+)>?\s*$/i REPLACE From: ”$1 ($2) (fwd)" noreply@domain1.it

Jamesthepeach

esackbauer I am new to all this…. self learner. What would be the good reason?