Bypass VPS SMTP Port Restrictions with Postfix and Resend API — Keep Using Outlook Without Changing Its Settings

Some VPS providers restrict outbound SMTP traffic. OVH is one example: depending on the server and provider policy, outgoing connections on SMTP ports such as 25, 465, or 587 may be blocked.

This creates a frustrating situation: you can receive email on your own mail server, access your mailboxes through IMAP, and connect to Postfix using Outlook or another desktop email client — but sending messages directly from the VPS is impossible.

One solution is to stop using an external SMTP server as the outbound relay and instead send messages through an email delivery API over HTTPS.

In this tutorial, we’ll combine:

• Postfix — the existing mail server, responsible for SMTP connections from email clients.
• Resend — an email delivery service with an HTTPS API.
• A lightweight SMTP-to-HTTPS gateway — a small Go application that accepts SMTP messages locally and forwards them to Resend using its API.

The most important benefit is that you can bypass outbound SMTP port restrictions without changing the configuration of external email clients such as Microsoft Outlook, Apple Mail, or Thunderbird.

Your clients continue using your VPS as their normal SMTP server, with the same hostname, port, username, password, and TLS configuration.

Only the server’s internal outbound delivery path changes.

1. How the solution works

The architecture looks like this:

       Outlook / Apple Mail / Thunderbird
                       |
                       | SMTP Submission
                       | Port 587 + STARTTLS
                       |
                       v
              Your VPS (Postfix)
                       |
                       | SMTP
                       | 127.0.0.1:2525
                       |
                       v
             SMTP-to-HTTPS Gateway
                       |
                       | HTTPS API
                       | Port 443
                       |
                       v
                  Resend API
                       |
                       v
                 Recipient's
                  mail server

The important detail is that the SMTP-to-HTTPS gateway listens only on 127.0.0.1.

It is not exposed to the Internet and does not require opening another firewall port.

Postfix communicates with the gateway over the local loopback interface. The gateway then uses HTTPS to submit the message to Resend.

This means that even if your VPS provider blocks outbound SMTP connections, the solution can still work as long as outbound HTTPS traffic on port 443 is permitted.

What stays unchanged?

Component	What happens
Incoming email	Remains on your existing mail server
IMAP access	Unchanged
Postfix SMTP submission	Unchanged
Outlook configuration	Unchanged
SMTP authentication	Still handled by Postfix
TLS between client and Postfix	Unchanged
Outbound email delivery	Forwarded through Resend API

This is not a replacement for your mail server. It is an alternative outbound delivery mechanism.

2. Prerequisites

This tutorial uses the following example environment:

Component	Example
Operating system	AlmaLinux 10
Mail server	Postfix
Mail domain	example.com
Mail server hostname	mail.example.com
SMTP submission port	587
Local gateway SMTP port	2525
Gateway health endpoint	127.0.0.1:8080
Delivery provider	Resend

You need:

• A working Postfix installation.
• A working SMTP submission service (typically port 587).
• SMTP authentication already configured.
• A domain you control.
• A Resend account and API key.
• Outbound HTTPS connectivity from your VPS.

Docker is not required.

First, verify that your server can reach the Resend API:

curl -Iv --connect-timeout 10 https://api.resend.com

An HTTP response, even an authentication-related response, confirms that the HTTPS connection works.

The SMTP ports may be blocked while HTTPS remains available.

3. Configure your domain in Resend

Before configuring the gateway, add your domain to Resend.

1. Log in to your Resend account.
2. Open the Domains section.
3. Add example.com.
4. Copy the DNS records provided by Resend.
5. Add the records to your DNS provider.
6. Wait for DNS propagation and verify the domain.

Resend typically requires DKIM and SPF-related DNS configuration.

Important: Do not blindly replace your existing SPF record. A domain should have a single SPF TXT record, so merge the required mechanisms if one already exists.

Also, preserve your existing MX records if your VPS is responsible for receiving incoming mail. Follow Resend’s instructions carefully and use a separate sending subdomain for return-path records if necessary.

Once Resend verifies the domain, you can use addresses such as:

• info@example.com
• support@example.com
• admin@example.com

The gateway will also be configured to restrict which sender domains it accepts.

4. Install the SMTP-to-HTTPS gateway

We’ll use the open-source project:

resend-railway-gateway

It provides a lightweight SMTP server that accepts messages and submits them to Resend through its HTTPS API.

First, install the required packages:

sudo dnf install -y golang git

Create a directory for the application:

sudo mkdir -p /opt/resend-gateway
sudo chown "$USER":"$USER" /opt/resend-gateway

Clone the repository:

cd /opt/resend-gateway

git clone https://github.com/igorrius/resend-railway-gateway.git src

Build the application:

cd /opt/resend-gateway/src

go build -o bin/resend-railway-gateway ./cmd/gateway

Install the compiled binary:

sudo install -m 755 \
  bin/resend-railway-gateway \
  /usr/local/bin/resend-gateway

We now have the gateway executable installed.

5. Create a dedicated system user

The gateway should run as an unprivileged system user.

sudo useradd \
  --system \
  --no-create-home \
  --shell /sbin/nologin \
  resend-gateway

Create its configuration directory:

sudo mkdir -p /etc/resend-gateway
sudo chmod 700 /etc/resend-gateway

6. Configure the gateway

Create the environment configuration file:

sudo nano /etc/resend-gateway/gateway.env

Add the following configuration:

RESEND_API_KEY=re_xxxxxxxxxxxxxxxxxxxxxxxxx

SMTP_USER=postfix
SMTP_PASS=CHANGE_THIS_TO_A_LONG_RANDOM_PASSWORD

SMTP_LISTEN_ADDR=127.0.0.1:2525
HEALTH_ADDR=127.0.0.1:8080

SMTP_REQUIRE_AUTH=true

ALLOWED_FROM_DOMAINS=example.com

SEND_TIMEOUT_SECONDS=15
SEND_MAX_RETRIES=3

LOG_LEVEL=INFO

Replace:

• RESEND_API_KEY with your actual Resend API key.
• SMTP_PASS with a strong, randomly generated password.
• example.com with your verified sending domain.

For multiple domains, separate them with commas:

ALLOWED_FROM_DOMAINS=example.com,example.net,another-domain.com

The SMTP_USER and SMTP_PASS values are credentials used by Postfix when connecting to the local gateway. They are not the credentials used by Outlook.

Secure the file:

sudo chown root:root /etc/resend-gateway/gateway.env
sudo chmod 600 /etc/resend-gateway/gateway.env

The gateway listens only on localhost:

• SMTP: 127.0.0.1:2525
• Health check: 127.0.0.1:8080

Neither endpoint needs to be accessible externally.

7. Create a systemd service

We want the gateway to start automatically after a reboot and restart if it crashes.

Create the service file:

sudo nano /etc/systemd/system/resend-gateway.service

Use this configuration:

[Unit]
Description=Resend SMTP to HTTPS Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple

User=resend-gateway
Group=resend-gateway

EnvironmentFile=/etc/resend-gateway/gateway.env

ExecStart=/usr/local/bin/resend-gateway

Restart=always
RestartSec=5

NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Reload systemd and start the service:

sudo systemctl daemon-reload

sudo systemctl enable --now resend-gateway

Check its status:

sudo systemctl status resend-gateway

Check the gateway health:

sudo /usr/local/bin/resend-gateway healthcheck

Expected output:

healthcheck_ok

You can also inspect its logs:

sudo journalctl -u resend-gateway -f

At this point, the gateway should be running locally.

8. Configure Postfix to use the local gateway

This is the most important part of the configuration.

Postfix will continue accepting SMTP connections from external clients. We only change where Postfix forwards outgoing messages.

Before making changes, back up the configuration:

sudo cp /etc/postfix/main.cf \
  /etc/postfix/main.cf.backup

sudo cp /etc/postfix/sasl_passwd \
  /etc/postfix/sasl_passwd.backup

If the SASL password file does not exist yet, create it instead of backing it up.

8.1. Configure local gateway authentication

Edit:

sudo nano /etc/postfix/sasl_passwd

Add:

[127.0.0.1]:2525 postfix:CHANGE_THIS_TO_A_LONG_RANDOM_PASSWORD

Use exactly the same password as SMTP_PASS in gateway.env.

Generate the Postfix lookup database:

sudo postmap lmdb:/etc/postfix/sasl_passwd

Protect the credentials:

sudo chmod 600 /etc/postfix/sasl_passwd

The lookup database should also be protected from unauthorized access.

8.2. Change the Postfix relay configuration

Configure Postfix:

sudo postconf -e 'relayhost = [127.0.0.1]:2525'

sudo postconf -e 'smtp_tls_security_level = none'

sudo postconf -e 'smtp_sasl_auth_enable = yes'

sudo postconf -e 'smtp_sasl_password_maps = lmdb:/etc/postfix/sasl_passwd'

sudo postconf -e 'smtp_sasl_security_options = noanonymous'

sudo postconf -e 'smtp_sasl_mechanism_filter = plain'

A few important details:

• relayhost points to the local gateway instead of an external SMTP server.
• SMTP authentication is enabled because the gateway requires authentication.
• smtp_tls_security_level = none applies to Postfix’s outbound SMTP client connection to the local gateway only.
• It does not disable TLS for incoming SMTP submission connections from Outlook or other clients.

Your existing smtpd_tls_* settings remain responsible for TLS on the client-facing SMTP service.

8.3. Validate and reload Postfix

Run:

sudo postfix check

If there are no configuration errors:

sudo systemctl reload postfix

Check the resulting relay configuration:

postconf relayhost
postconf smtp_tls_security_level
postconf smtp_sasl_auth_enable

Postfix should now deliver outgoing messages to the local gateway.

9. Test the complete delivery path

First, check that both services are running:

sudo systemctl status postfix
sudo systemctl status resend-gateway

You can inspect the gateway logs:

sudo journalctl -u resend-gateway -f

And Postfix logs:

sudo journalctl -u postfix -f

Now send a test email using your existing SMTP account.

For example:

From: test@example.com
To: your-personal-mailbox@gmail.com
Subject: SMTP gateway test

The expected delivery path is:

1. Outlook connects to Postfix.
2. Postfix authenticates the user.
3. Postfix queues the message.
4. Postfix forwards it to 127.0.0.1:2525.
5. The gateway authenticates the Postfix connection.
6. The gateway submits the message to Resend over HTTPS.
7. Resend accepts the message for delivery.

A successful Postfix log entry looks similar to:

postfix/smtp: relay=127.0.0.1[127.0.0.1]:2525,
dsn=2.0.0, status=sent (250 2.0.0 OK: queued)

The gateway should also log a successful submission, for example:

send_ok outcome=ok
from=test@example.com
to_domains=[gmail.com]
resend_id=...

status=sent means the gateway accepted the message. Check Resend’s dashboard and the recipient’s mailbox to confirm final delivery.

10. Keep using Outlook with the original SMTP settings

This is where the solution becomes particularly useful.

You do not need to change Outlook, Apple Mail, Thunderbird, or another external email client.

Your existing configuration remains:

Setting	Value
SMTP server	mail.example.com
SMTP port	587
Encryption	STARTTLS
Authentication	Normal SMTP authentication
Username	Your existing mailbox username
Password	Your existing mailbox password

For example, if Outlook was already configured to send through:

mail.example.com:587

it will continue to do exactly that.

The difference is entirely on the server side.

Postfix receives the message as usual but forwards it to the local gateway, which uses the Resend API instead of opening an outbound SMTP connection.

There is no need to configure an API key in Outlook or expose Resend credentials to email clients.

11. Why this bypasses OVH and other VPS SMTP restrictions

Many VPS providers restrict outbound SMTP traffic to reduce spam and abuse.

Depending on the provider, restrictions can include:

• Outbound port 25.
• Outbound port 465.
• Outbound port 587.
• Other SMTP submission ports.

Traditional SMTP relaying requires a working outbound SMTP connection. If the provider blocks those connections, configuring another SMTP relay will not necessarily help.

The approach described here changes the transport mechanism:

Postfix → Local SMTP gateway → HTTPS API → Resend

The gateway does not connect to Resend using SMTP. It sends an HTTPS request to the Resend API over port 443.

HTTPS is normally permitted on VPS networks because it is required for regular web traffic and API communication.

As a result, the solution can work even when the provider blocks outbound SMTP connections.

There is one important qualification: outbound HTTPS to the API must be allowed. If a provider blocks all outbound connectivity or specifically blocks the API endpoint, this approach will not solve that restriction.

12. Security considerations

A few things are worth keeping in mind.

Keep the gateway local.

Do not bind the gateway to 0.0.0.0. It should listen on:

127.0.0.1:2525

There is no reason to expose it publicly.

Protect the API key.

Keep the Resend API key in the root-owned environment file. Never put it in Postfix’s public-facing SMTP configuration or in an email client.

Use SMTP authentication.

The gateway should require authentication, and Postfix should authenticate using the dedicated gateway credentials.

Restrict allowed sender domains.

Use ALLOWED_FROM_DOMAINS to prevent unauthorized domains from being used as senders.

Keep your existing mail-server security.

Your existing Postfix and Dovecot configuration, TLS certificates, authentication, firewall rules, and anti-abuse protections remain important.

Monitor delivery.

Check Postfix logs, gateway logs, and Resend’s dashboard. A successful API submission does not guarantee that the recipient’s mail server has accepted or displayed the message.

13. Updating the gateway

When updating the gateway, rebuild the application from its source directory:

cd /opt/resend-gateway/src

git pull

go build -o bin/resend-railway-gateway ./cmd/gateway

Install the updated binary:

sudo install -m 755 \
  bin/resend-railway-gateway \
  /usr/local/bin/resend-gateway

Restart the service:

sudo systemctl restart resend-gateway

Check its status:

sudo systemctl status resend-gateway

Your Postfix configuration and email client settings do not need to change when updating the gateway.

Conclusion

You do not necessarily need to move your entire mail infrastructure to another VPS provider just because outbound SMTP is blocked.

By keeping Postfix as the public-facing SMTP server and introducing a small local SMTP-to-HTTPS gateway, you can continue using your existing mail setup while outsourcing only outbound message delivery to an email API provider.

The advantages are straightforward:

• No need to open outbound SMTP ports.
• Works with VPS providers that block traditional SMTP traffic, provided HTTPS is available.
• No Docker requirement.
• No need to replace Postfix or Dovecot.
• Incoming email remains on your existing server.
• Existing SMTP authentication and TLS configuration remain in place.
• Outlook, Apple Mail, Thunderbird, and other external clients continue using their normal SMTP settings.
• No API credentials need to be stored in desktop email clients.

The key idea is simple: keep SMTP where your users expect it, but use HTTPS where your VPS provider allows it.