Set up a sending server for Outreach

A sending server is a server you rent that Outreach sends through. Magpie signs in to it once as root, sets it up as a mail relay for your domain, tests it, then removes its key from the server and destroys its own copy. After that, nothing in Magpie can sign in to it. A team admin sets one up from Outreach → Settings → Sending server.

What the server needs

• Ubuntu 24.04 or newer, a public IPv4 address, and root access.
• Nothing else on it: no mail software, and nothing listening on ports 25, 80 or 587. A server Magpie set up before is fine; Magpie sets it up again in place.
• At least 2 GB free on disk and 512 MB of memory.
• Outgoing port 25 open. Some providers block it on new accounts; ask them to open it before you start.
• A domain with an active Mail address on it. Magpie hosts the domain's DNS, because it publishes the server's records.

Name the domain

Type the domain campaigns will send from and choose Use this domain. If the domain is not in Mail yet, Magpie adds it. The page says where the domain's DNS is today and where its email goes; moving the domain to Magpie's nameservers stops that email unless you import the domain's records first (Host and manage DNS for a domain). Set the two nameservers the page shows at your registrar. The page moves on by itself once they are in use.

Name the server

Enter the Server address, the server's public IPv4 address, and the Relay name, the name the server will answer to: mail. followed by your domain unless you change it. Magpie publishes the relay name's A record and adds the address to the domain's SPF record.

Add Magpie's key

The page shows one line. As root on the server, add it to /root/.ssh/authorized_keys. The line works only from Magpie's address, allows no forwarding, and stops working 24 hours after it was made. Magpie keeps the other half of the key sealed, and no one can read it.

At your provider, set the Reverse DNS of the address to the relay name.

The checks and Start

Before the setup starts lists what must be true: the nameservers in use, the relay name resolving to the address, the reverse DNS set, a mailbox on the domain, and Magpie's key not yet expired. The page checks them every minute. Start the setup appears once every check passes and confirms what Magpie will do as root.

A team can start 3 setups in 24 hours, one at a time.

What the setup does

The page shows each step as it runs, with a line saying what was done.

1. Magpie signs in as root and checks the server: root, the Ubuntu version, no mail software it did not install, the ports, disk and memory, outgoing port 25, and the relay name resolving to the server. Anything unexpected stops the setup with nothing changed.
2. It sets the server's name; installs Postfix as a relay on port 587 with STARTTLS and one login; gets a Let's Encrypt certificate for the relay name, renewed by the server itself; opens ports 22, 80 and 587 in the firewall and closes the rest; and turns on security updates. Port 25 does not listen.
3. From Magpie's side it signs in to the relay over TLS, sends a test message through it to the domain's mailbox, waits up to 10 minutes for it to arrive from the server's address with its signature unchanged, and checks what public DNS says about the relay name, the reverse DNS, SPF, DKIM and DMARC.
4. It writes the sending route, removes its line from authorized_keys, closes the connection and destroys its own copy of the key.

A setup that takes longer than 40 minutes stops. You will get one email when the setup ends. Let's Encrypt will email the admin who started it if the certificate cannot renew.

Could not sign in

Magpie tries 6 times, 5 minutes apart, without email. Then the page says Could not sign in. Check that the line is in /root/.ssh/authorized_keys on the server at that address, then choose Try again. The same key works until it expires.

If the setup stops

The page and the email show one line: what was found, what to do next, and that Magpie's key is destroyed. Whatever had been done on the server stays as it is. Fix what the line names, then choose Start again: a new key, a new line to add, and Magpie sets the server up again in place.

If Magpie could not remove its line because the connection was lost, the line says so: remove the Magpie line from /root/.ssh/authorized_keys yourself. Magpie's half of the key is destroyed either way.

Cancel the setup before Magpie signs in ends it at once. While the setup is running, Magpie finishes the command in progress, removes its line, destroys the key, and says what had been done on the server.

Once it is ready

The Sending route on Outreach settings names the server, and campaigns send through it. The login's password is stored sealed with the route and is never shown. Saving Your SMTP server by hand replaces the server as the route; the server itself is unchanged.

Set up again runs the whole setup again with a new key: after a rebuilt server, a certificate that did not renew, or to replace the login. The current route keeps working until the new setup is ready.

Removing the server

Remove the server, in the server's More menu, stops campaigns sending until the team has a sending route again, removes the relay's A record and SPF entry from the domain, and destroys any key. The domain stays in Mail. Nothing on the server itself changes.

If the setup does something this page does not explain, Contact support.