Email signatures without your own mail server — mailboxes at STRATO, IONOS & co.

Almost every guide to central signature management assumes something many companies simply don't have: their own mail server, or a Microsoft 365 subscription. If your mailboxes live at STRATO, IONOS, Hetzner or All-Inkl, there is no transport rule and no main.cf to put a smarthost into. It works anyway — no Postfix, no M365. The mail client points straight at the gateway.

What changes, and what doesn't

Only the sending path changes. Instead of your host's outgoing server, the mail client hands the message to mx.signaturehub.de on port 2587 with STARTTLS. The rule engine runs, the signature is injected, and SignatureHub delivers the mail to the recipient itself.

Incoming mail stays entirely with your current provider. IMAP settings, folders, webmail, filters — untouched. Instead of one shared connector password, every employee gets their own credentials, optionally one per device. A lost iPhone then costs exactly one disabled credential.

Step 1: connector in direct-MX mode

Under "Connectors", create a connector of type SMTP relay. Two fields decide everything: leave the relay host empty (direct-MX mode, SignatureHub delivers itself) and set the DKIM mode to sign at hub — your host's DKIM key no longer applies on this path, because its outgoing server is out of the picture.

Step 2: mail users and credentials

Create mail users, manually or via CSV import. Two routes to credentials: as admin via mail users page → key icon → enter a label ("iPhone") → Generate. Or by the employee in the self-service portal under "SMTP credentials" — the better route, because the password never travels through chat or a sticky note. The password is shown once, at generation time, and cannot be looked up.

Step 3: values in the mail client

Outgoing server   mx.signaturehub.de
Port              2587
Encryption        STARTTLS   (iOS: turn on "Use SSL")
Username          shown at generation (usually the mail address)
Password          shown once, at generation

This works in Outlook for Windows and Mac, Apple Mail, iPhone, Android and Thunderbird. Switch one device and test before rolling out.

Step 4: SPF and DKIM

Two DNS records have to follow, or mail lands in spam. SPF must include the hub IP — take the exact value from the connector page or GET /api/v1/connectors/spf/check, don't copy it from a guide, IPs change. The DKIM TXT record for sign-at-hub is shown during connector setup and belongs in the sender domain's DNS zone.

Verification: test mail to an external address or to mail-tester.com, then check the header for Authentication-Results: dkim=pass, spf=pass, dmarc=pass. In parallel, mail.processed should appear in the audit log.

The three limits

1. The sent folder carries no signature. The client files the IMAP copy before the mail reaches the gateway. The recipient sees the signature, the sender in their own sent folder does not. True of any server-side solution — with one exception, see below.
2. No relay back to your host. The smarthost path has no SMTP AUTH, but STRATO and co. require it. Direct-MX is therefore the only viable mode: your host's outgoing server is out, and so is its DKIM.
3. Internal mail passes through too. Unlike M365 or Exchange, where mailbox-to-mailbox bypasses the connector, every mail takes the same path here. If colleagues shouldn't get a signature, set the rule to recipient_is_external.

Why queue and retry still work

With the host's outgoing server gone, who retries on greylisting? In direct-MX mode the gateway hands off to the local Postfix queue, with retry and backoff. Recipient-side greylisting is therefore harmless and the user sees no send error. The client only gets a 4xx if the hub itself refuses — rate limit or auth lockout.

Sender binding and brute-force protection

A session authenticated with a device password may send only as its employee's addresses, primary plus aliases. Both MAIL FROM and the From: header are checked; if either mismatches, the gateway answers 550 5.7.1. A connector credential for a customer MTA deliberately has no such binding.

Failed attempts are counted per user and IP: 10 failures in 5 minutes lock that one credential for 15 minutes. An IP-wide threshold of 50 catches credential spraying on top. A single device with an outdated password therefore does not lock out the whole office NAT. Revoking means disabling the credential; the gateway picks that up at the next cache refresh, within 30 seconds.

Exception Thunderbird: signature in the sent folder too

There is a way around the first limit if you run Thunderbird 128 or newer. The SignatureHub add-on sets the signature in the compose window already, so the IMAP copy in the sent folder contains it. Template and rules still come from the backend. A marker prevents duplicate signatures: when the gateway finds it, it skips its own injection. Install straight from Thunderbird via addons.thunderbird.net/addon/signaturehub.

One detail: if Thunderbird's account settings still hold a signature text of their own, both stack up — clear that field. This does not apply to Outlook with IMAP or POP mailboxes: Office add-ins require an Exchange mailbox. Outlook with a STRATO, IONOS or All-Inkl account stays on the server path. So does Apple Mail — MailKit offers no API for the compose body.

Bottom line

Central signatures are not a privilege of companies with their own mail infrastructure. What it takes is one setting in the mail client, two DNS records, and accepting a sent folder without a signature — or running Thunderbird. Budget half an hour, plus the rollout to devices.