Support & documentation

Yes — this is one of the most common use cases. Microsoft has officially marked the IIS 6.0 SMTP service as deprecated. It is still bundled with Windows Server 2025, but slated for removal in future releases. On top of that, it can't do OAuth2: forwarding mail through Exchange Online requires Basic Auth — which Microsoft is shutting down for good by December 2026.

SMTPly is the modern answer for that exact scenario: same role (local SMTP relay for printers, ERP systems, scanners and line-of-business software), but with OAuth2 translation to Microsoft Graph, a GUI, a mail tracker, retry logic, and an actively maintained codebase. Migration is straightforward: stop the IIS SMTP service, install SMTPly, keep the bind port at 25 (or 587), and your devices keep their existing target IP — done.

Yes. Ctrl+1 to Ctrl+5 jump straight to Dashboard, System Log, Settings, License and About; Ctrl+, opens the settings. F6 moves focus between the navigation pane and the content area. Within a page, Tab moves focus, Space/Enter activates, and the main buttons (Save, start/stop service, activate license) have Alt access keys. The keyboard focus is clearly highlighted so you always see where you are without a mouse. (from version 1.7.26)

Yes — the entire file is encrypted, for the manual export just as for the scheduled one. Protection is your backup passphrase via PBKDF2-SHA256 (600,000 iterations) and AES-256-GCM. All that stays readable is a short envelope with a format marker and creation date, so you can tell what a file is even without the passphrase:

{
  "format": "smtply-encrypted-backup",
  "version": 1,
  "createdAt": "2026-07-30T23:51:45+02:00",
  "payload": "portable:v1:600000:…"
}

Everything else — tenant and client IDs, client secrets, sender addresses, domain and IP allowlists, ports, SMTP users and paths — sits inside the encrypted block. On top of that, the credentials within it are individually encrypted again, so they are not exposed even after unpacking. The backup passphrase itself is never included.

AES-GCM detects any later modification: a corrupted or tampered backup is rejected on import rather than half-applied. Without the passphrase the file cannot be restored — store it separately from the backups, otherwise the best backup is worthless when you need it.

Permissions on UNC/SMB paths. The SMTPly service runs as LocalSystem by default. That account is not your signed-in user: when accessing a network share, the server authenticates with its computer account, i.e. DOMAIN\SERVERNAME$. A path you can happily write to in Explorer may therefore still be denied to the service.

For the scheduled export to work, grant the computer account write access — in both places:

• Share permissions of the SMB share: DOMAIN\SERVERNAME$ → Change
• NTFS permissions of the target folder: DOMAIN\SERVERNAME$ → Modify

You can verify this upfront from an administrative PowerShell on the SMTPly server:

# Test in the computer account's context (requires PsExec from Sysinternals)
psexec -s -accepteula powershell -Command "New-Item '\\nas\backup\smtply\test.txt' -ItemType File; Remove-Item '\\nas\backup\smtply\test.txt'"

Alternatively, run the service under a domain user account or a group Managed Service Account (gMSA) — then its permissions apply. Change this in the Services console under Properties → Log On.

If access fails, the reason appears in the system log and in Settings under "Last backup", including a pointer to the computer account. An unreachable share does not block email delivery: both destinations are attempted independently.

As an SMTP relay to Microsoft 365: yes. Many installations run hMailServer purely as a local smart host — devices submit over SMTP, hMailServer forwards to Exchange Online. SMTPly takes over exactly that role, with the difference that forwarding runs over OAuth2 and Microsoft Graph instead of a username and password.

The trigger is usually the same: hMailServer has not been developed for years, the last release has no OAuth2 support and ships an outdated OpenSSL. Once Microsoft turns off SMTP Basic Auth, forwarding stops — and it cannot be retrofitted.

What SMTPly is not: a full mail server. There are no mailboxes, no POP3/IMAP retrieval, no local delivery and no distribution lists — those live in Microsoft 365. If you run hMailServer as a standalone mail server with local mailboxes, you still need a different solution for that part.

Migration: stop the hMailServer service, install SMTPly, bind the same port (usually 25) — your devices keep their target IP and never have to be touched. Sender allowlists and IP restrictions are recreated in the SMTPly settings.

Yes. SMTPly hands every message to Microsoft Graph via sendMail, and Microsoft automatically files a copy in the sender address's mailbox under Sent Items. You get the same trail as for a message sent from Outlook, attachments included.

For many setups this is precisely why SMTPly gets chosen: a classic SMTP relay delivers the message and then forgets it. Through Microsoft Graph it stays traceable in the mailbox, and colleagues with access to a shared mailbox can see what a line-of-business application has sent out.

The behaviour comes from Microsoft and cannot be switched off when sending in MIME format. If you would rather not keep the copies, a retention policy on that mailbox is the way to handle it.

No. Whatever your device hands over via SMTP is passed on to Microsoft Graph byte for byte — headers, encodings, multipart boundaries, embedded images and attachments all stay untouched. SMTPly only reads along to show sender, recipients, subject and size in the mail tracker; the original bytes are never altered. No extra Received header is added either.

There are exactly two narrowly scoped exceptions, each touching a single header line:

Sender override: if all mail goes out under one fixed address, the From: line is replaced — Microsoft Graph rejects any message whose sender differs from the sending mailbox. Without the override this never applies.

Journal BCC (Business/Enterprise): if an archive mailbox is configured, SMTPly adds a Bcc: line with that address so the blind copy gets delivered. As with any BCC, Microsoft strips the line before delivery to the recipients — nothing of it is visible. Without a configured journal mailbox this never applies either.

In both cases only the affected line is swapped or inserted; body, attachments and all remaining headers stay byte-identical.

As of version 1.7.16, SMTPly can send an HTTP POST to an address of your choice when operational events occur (Business/Enterprise). That puts incidents where you are already looking instead of burying them in a mailbox: a message in a Teams or Slack channel, a ticket in your PSA system, or a trigger in n8n, Node-RED or Power Automate.

Setup

In Settings under Webhooks: tick the box, enter the target URL, optionally set a signing secret, and pick which events to send. Save, then verify with "Send test event" — the button uses exactly the same path the service uses for real events, so a successful test is meaningful.

https is accepted everywhere. Plain http only for targets inside your own network (loopback, 10.x, 172.16–31.x, 192.168.x, 169.254.x, CGNAT), because the payload contains sender, recipients and subject, which has no business travelling unencrypted across the internet.

Events

Event	When
delivery.failed	A message could not be delivered after all retry attempts
relay.paused	Microsoft Graph is unreachable, sending is paused
relay.resumed	Sending is working again
certificate.expiring	The STARTTLS certificate expires in 30 days or less
secret.expiring	The Azure client secret is about to expire
test	Triggered manually from the test button

Request format

POST with Content-Type: application/json, plus the headers X-Smtply-Event (event name) and, if a secret is configured, X-Smtply-Signature.

{
  "event": "delivery.failed",
  "timestamp": "2026-07-31T08:45:13+02:00",
  "server": "SRV-RELAY01",
  "version": "1.7.16",
  "data": {
    "from": "printer@example.com",
    "to": "accounting@example.com",
    "subject": "Scan 2026-07-31",
    "error": "HTTP 403 Forbidden",
    "tenant": "Primary tenant",
    "attempts": 5
  }
}

The fields inside data follow your privacy settings: with masking enabled, addresses and subjects arrive already masked.

Verifying the signature

With a secret configured, X-Smtply-Signature carries an HMAC-SHA256 over the exact request body in the form sha256=<hex>. The receiver recomputes it and thereby knows the call genuinely came from this installation and was not altered in transit:

# PowerShell example for the receiving side
$secret   = "YourSigningSecret"
$body     = $request.Body          # exactly as received, do not reformat
$hmac     = [System.Security.Cryptography.HMACSHA256]::new([Text.Encoding]::UTF8.GetBytes($secret))
$hash     = $hmac.ComputeHash([Text.Encoding]::UTF8.GetBytes($body))
$expected = "sha256=" + ([BitConverter]::ToString($hash) -replace '-','').ToLower()

if ($expected -ne $request.Headers["X-Smtply-Signature"]) { throw "Invalid signature" }

Important: compute over the unmodified body. Parsing the JSON and re-serialising it produces a different string and therefore a different signature.

For Teams and Slack webhooks you can leave the secret empty — there the unguessable URL is the protection.

Delivery behaviour

Up to three attempts, 2 and 6 seconds apart. If the receiver answers with a 4xx error (other than 408 and 429), there is no retry, because that is a configuration problem and repeating it changes nothing. A webhook is a notification, not guaranteed delivery — the mail tracker remains the reliable record. Sending runs concurrently: a slow or unreachable receiver never slows down mail relaying. The outcome of the last attempt is shown in Settings under "Last delivery attempt".

As of version 1.7.13 SMTPly ships an HTTP monitoring endpoint (Business/Enterprise). Enable it in Settings under Monitoring (checkbox + port, default 8025), then restart the service. The endpoint is disabled by default and answers only on 127.0.0.1 — responses contain nothing but counters and status values, no addresses, subjects or mail content.

GET /health — for HTTP sensors

Returns HTTP 200 while the relay is operational and HTTP 503 when sending is paused (Microsoft Graph unreachable, circuit breaker open). A plain HTTP sensor is enough: 200 = green, anything else = alert.

{
  "status": "ok",                  // "ok" or "degraded"
  "version": "1.7.13",
  "uptimeSeconds": 86400,          // seconds since service start
  "queueLength": 0,                // mails queued / retrying
  "circuitBreaker": "Closed",      // Closed | Open | HalfOpen
  "today": { "sent": 312, "failed": 1, "pending": 0 }
}

The daily counters use the server's local calendar day — the same values as the dashboard tiles.

GET /metrics — Prometheus text format

smtply_up 1
smtply_uptime_seconds 86400
smtply_queue_length 0
smtply_circuit_breaker_open 0
smtply_mails_sent_today 312
smtply_mails_failed_today 1
smtply_mails_pending_today 0

Useful alerts: smtply_up missing (service down), smtply_circuit_breaker_open == 1 (sending paused), smtply_queue_length growing steadily, smtply_mails_failed_today spiking.

Hooking up common systems

PRTG: an "HTTP" or "HTTP Advanced" sensor on http://<server>:8025/health — status code 200 as the OK condition is all it takes. For values as channels, use "EXE/Script Advanced" with the PowerShell script below. Zabbix: HTTP agent item on /health with JSONPath preprocessing (e.g. $.queueLength), or scrape /metrics natively via the Prometheus support. CheckMK: active HTTP check on /health or a local check based on the script below. Prometheus/Grafana: scrape job straight on /metrics.

RMM platforms: in N-able N-sight, deploy the script below as a "Script Check" (non-zero exit code = alert); in N-able N-central, as an automation policy (AMP) or custom service check. Octoja and comparable RMM solutions with script sensors hook SMTPly up through exactly the same pattern — and since the agent runs locally on the server, the default bind on 127.0.0.1 is sufficient, no firewall opening needed.

PowerShell example

Universal health check — as a Task Scheduler probe, Zabbix UserParameter or PRTG "EXE/Script Advanced" (exit code 0 = OK, 1 = warning, 2 = critical):

# smtply-healthcheck.ps1 — example, adjust the port if needed
$url = "http://127.0.0.1:8025/health"
try {
    $h = Invoke-RestMethod -Uri $url -TimeoutSec 5
    if ($h.circuitBreaker -eq "Open") {
        Write-Output "CRITICAL: sending paused (circuit breaker open), queue=$($h.queueLength)"
        exit 2
    }
    if ($h.queueLength -gt 50) {
        Write-Output "WARNING: queue backlog ($($h.queueLength) mails)"
        exit 1
    }
    Write-Output "OK: v$($h.version), today $($h.today.sent) sent, $($h.today.failed) failed, queue=$($h.queueLength)"
    exit 0
}
catch {
    Write-Output "CRITICAL: SMTPly endpoint unreachable ($($_.Exception.Message))"
    exit 2
}

Polling from the LAN: by default the endpoint answers locally only. For remote polling, set BindAddress in the Monitoring section of %ProgramData%\Smtply\appsettings.json to the LAN IP or 0.0.0.0, restart the service, and open the port in Windows Firewall for your monitoring server specifically. The endpoint deliberately has no authentication — the firewall rule is the access control.

Yes — you can simply start Smtply.exe as a desktop application. The relay then runs as long as the GUI is open. For production 24/7 operation, the service variant is better: no logged-in user needed, auto-start with Windows.

Yes, starting with the Business edition. Business (€249) relays through up to 5 Microsoft 365 tenants in parallel on one Windows server, Enterprise (on request) 10+. Routing is selectable per tenant: by sender domain (mail from alice@firma1.de goes via the "Firma 1" tenant) or by AUTH-user binding (an authenticated SMTP user is pinned to one specific tenant).

The Starter edition (€149) supports exactly one tenant. To upgrade from Starter to Business: purchase a Business license, activate the new key on the License settings page — the multi-tenant UI unlocks immediately, and the existing single-tenant configuration is preserved as "Primary tenant".

Yes. SMTPly supports AUTH LOGIN and AUTH PLAIN on the listener since v1.5.4. Passwords are stored as PBKDF2-SHA256 hash with per-user salt — not recoverable, not even by the admin. Three sub-modes:

• AUTH off (default): senders are gated by the IP allow-list only.
• AUTH offered: AUTH is advertised in EHLO. Authenticated senders get priority routing; senders without AUTH fall back to the IP/domain allow-list.
• AUTH required: unauthenticated MAIL FROM is rejected with SMTP 530.

STARTTLS is required by default for plaintext passwords; an explicit "Allow plaintext AUTH without TLS" toggle exists for legacy devices that cannot do STARTTLS — opt-in only, with a clear warning.

Older devices (e.g. industrial controllers, smoking-chamber or cooling-system controllers) often speak an encryption variant their interface simply calls "SSL": implicit TLS. The connection is encrypted from the very first byte, without the plaintext phase that STARTTLS requires. If that doesn't match, the device typically fails with an error like SSL23_GET_SERVER_HELLO:unknown protocol.

Since version 1.7.5, SMTPly supports exactly this case: in the settings under SMTP listener → TLS/SSL, "Implicit TLS/SSL" is available as a mode alongside STARTTLS. Both modes share the same certificate selection (self-signed, PEM, or PFX) and are mutually exclusive — a listener port only ever serves one of the two modes.

If you have both old "SSL" devices and newer STARTTLS devices in use at the same time, that's not a contradiction: from the Business edition onward, you can run several SMTP listener ports in parallel, each with its own TLS mode. The old devices simply point at one port (implicit TLS), the newer ones at another (STARTTLS) — no per-device configuration required.

Currently no — SMTPly is Windows-native (DPAPI, Windows service, WPF). A Linux variant is not on the roadmap. For mixed environments, a Windows server as dedicated relay host is the simple solution.

No, that's a SmartScreen reputation warning, not a malware detection. Microsoft Defender SmartScreen blocks any file by default until it has built up enough download reputation — every brand-new release has a fresh hash and triggers this warning. It fades automatically once enough users have downloaded and run the same file.

As of version 1.7.18 the installer is digitally signed, issued to IT-Beratung - Andreas Hähnel. Two things change immediately: User Account Control names the publisher in plain text instead of "Unknown publisher", and the origin of the file can be verified independently of where you downloaded it. The SmartScreen warning itself does not disappear right away — that rating still depends on how often the specific file has been downloaded. The signature is what allows reputation to accumulate at all, not a switch that turns the warning off.

How to run the installer anyway:

• Browser download: click "Keep" → "Keep anyway".
• On launch: "Windows protected your PC" → "More info" → "Run anyway".

Check the signature: right-click the EXE → Properties → Digital Signatures → select the entry → Details. The signer must read IT-Beratung - Andreas Hähnel, and the chain runs through Microsoft ID Verified CS EOC CA up to the Microsoft Identity Verification Root Certificate Authority 2020. From PowerShell:

Get-AuthenticodeSignature SMTPly-Setup-latest.exe | Format-List Status, SignerCertificate

Compare the SHA-256: the checksum still applies and remains the sharpest check. It is published on the Download page and in every GitHub release:

Get-FileHash SMTPly-Setup-latest.exe -Algorithm SHA256

If the hashes match, your file is bit-identical to what we built and published. SmartScreen reputation is a heuristic signal — SHA-256 is cryptographically unambiguous.

How signing works here: through Azure Artifact Signing. The private key never sits on our build machine — it never leaves Microsoft's hardware security module, and the build only submits a hash to be signed. The issued certificates are deliberately very short-lived, so every signature carries a timestamp and stays valid after the certificate itself expires.

Just run the new installer. It detects the existing install, replaces the binaries and keeps configuration, license and logs under %ProgramData%\Smtply\ unchanged. From version 1.3.0 on, SMTPly proactively notifies you about available updates — the public release API is checked once per day and release notes are shown directly on the „About" page.

Yes, if you enter a recipient address under Settings → Microsoft 365 → E-mail notifications. SMTPly then sends a warning mail to that address as the expiry date approaches. The warning is sent from the same e-mail address that is configured for the mail relay.

By default the first warning is triggered 14 days before expiry (configurable). Additional warnings follow automatically at 7, 3, 1 and 0 days remaining — each threshold fires exactly once. Once the secret has expired, no more e-mails are sent because Microsoft 365 authentication stops working at that point; the colour-coded warning in the Microsoft 365 settings of the GUI remains visible.

Yes. Under Settings → Microsoft 365 → E-mail notifications, in addition to the secret-expiry warning, you can pick a report cadence: daily, weekly or monthly. The report is sent to the same notification address and contains totals (sent / failed / rejected), average delivery time, top senders, top recipient domains and the most common error reasons for the period.

The report respects your privacy settings — with masking enabled it shows masked addresses, with "Log addresses" disabled the top-lists are omitted entirely. You can switch the report off at any time with the "No reports" option.

No. SMTPly stores only metadata (timestamp, addresses, subject, size, status) in the mail tracker — body and attachments are discarded immediately after successful relay or final failure (GDPR data-minimisation).

Under Help / FAQ → Create diagnostics package, SMTPly builds a ZIP archive you can send to support, e.g. by email. It contains the most recent system log files, a masked overview of recently sent emails (sender, recipient, and subject are redacted — regardless of your usual masking level, because this package leaves your machine), the public certificate data (validity, issuer, thumbprint — never the private key), and a summary of the non-secret configuration (listeners, TLS modes, license edition). The sender IP address is deliberately kept in plain text, since it's needed for network and firewall diagnostics.

Passwords, client secrets, license keys, and private certificate keys are never included. A clear warning appears before the package is created — it's only generated locally, and it's only ever sent if you actively share it with a trusted party.

Yes. Under Help / FAQ → Run self-test, SMTPly checks its own state in one click: Windows service running, write permissions in the configuration directory, port availability, a real connection to its own listener (including a TLS handshake for implicit TLS), certificate validity, client secret decryption, and Microsoft Graph reachability. Each check shows up as a green/yellow/red result with a plain-language explanation.

Important: these checks connect over 127.0.0.1 (localhost) — Windows Firewall does not filter loopback traffic at all. A green result proves the listener works correctly locally, but not that an external device (e.g. the printer or ERP system) can actually get through the firewall. For that, the page offers a ready-made Test-NetConnection command to copy and run from the sending device, to verify real reachability.

Incoming mails land in a local, persistent queue (queue.db) before they reach the in-memory send queue. If Graph has a hiccup, exponential backoff handles it; if the Windows service restarts (or the whole server), SMTPly reloads the pending entries on startup and delivers them automatically. Only after a successful send — or a final failure — is the raw payload deleted.

During a Graph outage the GUI dashboard shows a warning banner; a circuit breaker prevents pointless retries from burning tokens.

Yes — SMTPly was deliberately designed so that no data flows to third parties. Processing stays within your existing M365 contractual relationship. Still, verify your internal compliance (e.g. whether legacy devices may send personal data at all).