Sending from a VPS

Owlat's built-in MTA delivers directly to each recipient's mail server. That gives you control, but it also makes the public IP address of your VPS part of your sending identity. A correct DNS record cannot erase a recycled IP's history or a provider-wide SMTP block.

This guide helps you decide whether direct delivery is appropriate, prepare the server, and understand what Owlat will do during the first four warming weeks. For the DNS records themselves, keep DNS & Email Setup open alongside this page.

Choose direct, relay, or hybrid delivery

There is no universal monthly-volume number where a dedicated VPS becomes more deliverable or cheaper than a relay. List quality, traffic shape, operational time, IP history, provider fees, and the cost of delayed mail matter more than a single threshold.

DigitalOcean's current Droplet policy makes the choice especially simple: its official documentation says SMTP ports 25, 465, and 587 are blocked on all Droplets, including traffic through a Reserved IP. Use a relay there rather than planning direct-to-MX delivery.

See Providers for relay configuration and domain verification. Relay credentials alone do not make a domain eligible: complete the DNS proof shown by Owlat before enabling fallback.

VPS provider comparison

Provider policies can change. This table was verified against official provider documentation on July 26, 2026; recheck the linked source before buying a server.

Sources: Hetzner Cloud mail-port policy, Hetzner Cloud rDNS, DigitalOcean SMTP policy, DigitalOcean PTR records, DigitalOcean IPv6 limits, OVHcloud VPS FAQ, and OVHcloud VPS reverse DNS.

The Deliverability Center renders these same canonical provider instructions inline:

Those product guides do not document reverse-zone delegation to your own name servers. Use the provider-managed PTR workflow they document. If your chosen product or IPv6 address does not appear in that workflow, get written confirmation from the provider before treating the address as send-capable.

Preflight the server before setup

Do these checks before enabling the built-in MTA:

1. Confirm the exact VPS product permits outbound TCP/25. Submission ports 465 and 587 do not replace port 25 for direct delivery to recipient MX servers.
2. Allocate a stable public IPv4 address and choose a dedicated hostname such as mail.example.com. Do not share the hostname with the web application.
3. Publish an A record from that hostname to the sending IPv4 address.
4. Set the address's PTR to exactly the same hostname in the VPS provider's control panel.
5. Put the address in the appropriate IP_POOLS_* value and set EHLO_HOSTNAME (or its per-IP EHLO_HOSTNAMES entry) to the same hostname.
6. Complete SPF, DKIM, DMARC, and return-path setup in DNS & Email Setup.
7. Run owlat doctor. Do not interpret “containers are running” as “the IP is ready to send.”

The outbound-IP readiness checklist

Owlat treats readiness as live state, not a setup checkbox. A new address starts inactive, the MTA verifies it before workers begin, and the check repeats hourly. A hard failure quarantines the address and invalidates its pooled SMTP sockets. If no eligible address remains, mail stays queued instead of leaking through an unverified source.

For every IPv4 sending address, owlat doctor must report:

• PTR exists — the address resolves to a hostname.
• PTR is a valid FQDN — not an IP literal or malformed local name.
• Forward confirmation passes — that hostname's A records contain the exact sending address.
• EHLO matches — the MTA announces the same hostname.
• The PTR is meaningful — a provider-default or address-shaped PTR is eligible only with a warning; replace it before building reputation.
• No critical DNSBL block is active — a critical listing independently removes the address from rotation.

The live details are available in Delivery health → Outbound IPs and in the authenticated MTA GET /ip-reputation endpoint. For every verdict field and pool rule, see MTA System. If a DNSBL check fails, use the DNSBL recovery runbook, not an override.

MTA_ALLOW_UNVERIFIED_FCRDNS=true exists only for private IPv4 lab experiments. It is not a production bypass and cannot admit IPv6.

Add outbound IPv6 only after IPv4 is green

IPv6 is optional and disabled by default. It does not automatically improve placement. Every IPv6-containing pool must retain an IPv4 fallback, and all configured IPv4 identities must remain ready.

Before setting MTA_IPV6_ENABLED=true, Owlat requires:

1. A stable public IPv6 address that passes the MTA's source-bound TCP/25 probe.
2. A PTR to the same EHLO hostname.
3. An AAAA record from that hostname back to the exact IPv6 address.
4. One SPF record on RETURN_PATH_DOMAIN containing the exact positive ip6: mechanism for that address.
5. No critical DNSBL block.

The same hourly readiness pass quarantines IPv6 if one of those confirmed facts regresses; eligible IPv4 continues. Follow the detailed, ordered procedure in Optional outbound IPv6.

What warming weeks 1–4 look like

The table below is Owlat's checked-in base schedule per IP. “Warming day” is state, not a guaranteed calendar date: a day with no sends does not advance it, and delivery signals can accelerate, slow, or pause the ramp. Each cap remains in force until the next listed checkpoint.

Send first to recent, explicit opt-ins who expect the message. Keep volume steady rather than exhausting the cap in a burst.

These are control thresholds, not targets. Keep bounces and complaints far below them. Watch Delivery health and the receiver dashboards described in External reputation feedback.

Know the mailbox-provider floor

Warm-up does not waive receiver requirements. Gmail and Yahoo expect valid forward and reverse DNS for all senders. Gmail's operational guidance is to keep its Postmaster Tools spam rate below 0.10% and avoid ever reaching 0.30% or higher. Yahoo requires its own complaint rate below 0.3% and calculates that rate from messages delivered to the inbox. Those denominators are different, so Owlat's rolling internal rate is an early warning rather than a reproduction of either provider's private calculation.

Bulk marketing mail also needs aligned authentication and working unsubscribe. See the current mailbox-provider requirement table before increasing volume.

Operate the ramp

During the first month:

• Check Delivery health each day for warm-up state, deferrals, breaker state, identity regressions, and DNSBL results.
• Check Google Postmaster Tools, Yahoo Sender Hub/CFL, and Microsoft SNDS where the provider exposes data. Owlat cannot infer a provider's private reputation verdict from its own counters.
• Stop importing or mailing old lists. One complaint at low volume is a strong signal even when a minimum-sample guard prevents automatic enforcement.
• Treat sustained deferrals as a request to reduce rate. Do not retry rapidly or move the same unwanted traffic to another IP.
• Keep transactional and campaign streams separate where you have multiple addresses; do not sacrifice password-reset delivery to warm a marketing list.

For production networking, backups, and monitoring outside the MTA, continue with Production Deployment.