I built this SMTP relay appliance for a common homelab and small-environment problem: an application, monitoring platform, printer, or older device needs to send email, but the site does not have a static public IP or an existing SMTP relay. The result is a reusable Ubuntu 24.04 OVA that accepts mail from trusted LAN clients and submits it to Microsoft 365 through authenticated SMTP over TLS.
The appliance is designed for vSphere and exposes deployment properties for the Linux administrator, SSH public key, DHCP or static IPv4 networking, DNS, search domains, NTP, sender address, and sender display name. Microsoft 365 credentials are not built into the image. Each deployment receives its own settings, and the mailbox credential is entered interactively after first boot.
Download the appliance and deployment guide
The public project is available at github.com/raleyj/office365-smtprelay. The version 1.0.0 release contains the deployable OVA.
- Download the SMTP relay OVA — approximately 567 MB.
- Deployment Guide — Word: prerequisites, vCenter import, Microsoft 365 configuration, testing, and troubleshooting.
- Read the deployment notes online.
- OVA SHA-256:
b17eb71c058d0729a2d68a9bcc3cecec4d06fceec172d38d75b86c810458c70b.
How the relay works
LAN applications send ordinary SMTP to the appliance on TCP port 25. Postfix accepts messages only from networks listed as trusted, rewrites the configured sender identity when required, and submits the message to smtp.office365.com on TCP port 587. That outbound connection uses STARTTLS and authenticates as a Microsoft 365 mailbox.
Because Microsoft 365 validates the mailbox credentials, this design does not depend on an IP-based Exchange Online connector and does not require a static public IP. The changing internet address at the site is not used as the relay identity. The visible From address may be different from the authenticating mailbox when that mailbox has Send As permission for the sender address.
What is inside
The OVA uses Ubuntu Server 24.04 LTS with Postfix, SASL support, Chrony, cloud-init, and a small first-boot configuration service. The virtual hardware is intentionally small: 2 vCPU, 2 GiB of memory, a 10 GiB disk, and one VMXNET3 adapter. Thin provisioning is appropriate for most deployments.
At first boot, cloud-init applies the OVF properties, creates the selected administrator, transfers the supplied public SSH key, configures networking and time synchronization, installs the mail components, and writes the Postfix sender mappings. A custom administrator receives passwordless sudo, and the initial Ubuntu account is locked after the key is transferred.
What you need before starting
| Component | Requirement |
|---|---|
| Virtualization | vCenter or a compatible VMware platform that can deploy an OVF template |
| Virtual hardware | 2 vCPU, 2 GiB RAM, 10 GiB disk, one network adapter |
| Guest access | A unique hostname, Linux administrator name, and OpenSSH public key |
| Network | DHCP or an unused static IPv4 address, gateway, DNS, search domain, and reachable NTP server |
| Outbound access | Ubuntu repositories, DNS, NTP over UDP/123, and smtp.office365.com over TCP/587 |
| Client access | Approved LAN clients can reach the appliance on TCP/25 |
| Microsoft 365 | A mailbox permitted to use SMTP AUTH and valid credentials or an app password supported by the tenant |
| Sender identity | Send As permission when the visible From address differs from the authenticating mailbox |
Prepare Microsoft 365 and GoDaddy
For a Microsoft 365 mailbox managed by GoDaddy, sign in to the Email & Office Dashboard as an administrator, select Manage beside the mailbox, open Account information > Advanced Settings, and enable SMTP Authentication. A directly managed Microsoft 365 tenant exposes the equivalent per-user setting under Users > Active users > Mail > Manage email apps > Authenticated SMTP.
Tenant policy still matters. Microsoft documents that Security defaults or an authentication policy can block SMTP AUTH even when the mailbox setting is enabled. GoDaddy also warns that enabling SMTP Authentication while Security defaults are active can disable Security defaults for the organization. Review MFA, app-password, conditional-access, and credential-rotation requirements before enabling the service.
If the appliance should send as a separate address such as a notifications shared mailbox, create or confirm that mailbox and grant the authenticating account Send As permission in Exchange admin center. A missing permission typically causes a 5.7.60 Send As denial.
From OVA import to a working relay
- Download the OVA, calculate its SHA-256 hash, and compare the complete value with the release digest.
- In vSphere Client, choose Deploy OVF Template, upload the OVA, select the cluster and datastore, and map the network adapter to the intended port group.
- Enter a unique instance ID and hostname, the administrator username, and one complete OpenSSH public-key line. Never enter a private key or SMTP password in the OVF fields.
- Select DHCP or static IPv4 and supply the applicable prefix, gateway, DNS servers, search domain, and NTP server. Enter the sender address and display name that Microsoft 365 is permitted to use.
- Power on the VM and wait for
sudo cloud-init status --waitto finish. Confirm Postfix and Chrony are active, DNS resolves, andtimedatectlreports synchronized time. - Run
sudo smtp-appliance-set-credentialsin an interactive SSH session. Enter the full Microsoft 365 mailbox address and password or app password at the prompts. - Review the Postfix
mynetworkssetting. Static mode initially trusts the configured IPv4 subnet; DHCP mode trusts loopback only until an administrator adds the narrowest approved client CIDR. - Send a test message from a trusted client to the appliance on TCP/25. Check
sudo postqueue -pandsudo journalctl -u postfix -n 80 --no-pager. A successful Microsoft 365 handoff showsstatus=sentand a250 2.0.0response.
Security and operational boundaries
The OVA contains no Microsoft 365 password or private SSH key. The setup command stores the SMTP credential in a root-protected Postfix map on the deployed VM. Keep TCP/25 restricted to explicitly trusted LAN networks, and do not publish that listener to the internet. Rotate the mailbox credential according to policy and rerun the setup command when it changes.
Time synchronization is part of mail reliability because TLS and cloud authentication depend on an accurate clock. Confirm that the selected NTP server responds from the actual destination subnet; successful DNS resolution or ping does not prove that UDP/123 is allowed. Monitor the Postfix queue, service logs, disk space, and Chrony status after deployment.
SMTP AUTH lifecycle
This first release uses SMTP AUTH with a mailbox username and password or app password over STARTTLS. Microsoft’s September 2026 timeline keeps that behavior unchanged through December 2026, then disables Basic Authentication for SMTP AUTH by default for existing tenants while still allowing administrators to re-enable it. A final removal date is expected later. Treat this appliance as a practical bridge for current devices and plan a supported OAuth-capable submission path before Basic Authentication is retired.