SDS SMTP

Overview

SDS SMTP gives WordPress administrators a controlled alternative to relying on the web server’s default mail configuration. It can deliver mail through either an authenticated Primary SMTP connection or Microsoft Graph using delegated OAuth. Only one Primary transport is active at a time, and switching transports retains the inactive configuration for later use.

An optional independent Fallback SMTP connection can protect delivery when the Primary transport fails before confirmed message acceptance. SDS SMTP deliberately refuses to fail over after an uncertain outcome that could otherwise produce a duplicate email.

Built-in logging, failure and recovery monitoring, SMTP connectivity tests, DNS authentication diagnostics, and optional out-of-band alerts provide operational visibility without requiring a separate provider SDK or remote management service.

Features

Why SDS

Security & Privacy

SDS SMTP handles email content, recipient information, authentication credentials, and external service connections. Its security model emphasizes authenticated encryption, least-privilege authorization, verified transport security, privacy-conscious logging, and conservative failover behavior.

• Authenticated credential encryption

  SMTP passwords, Microsoft client secrets and OAuth tokens, and Notification Channel credentials are protected with XChaCha20-Poly1305 authenticated encryption through PHP Sodium. SDS SMTP does not provide a plaintext or Base64-only storage fallback.

• Encryption keys outside the database

  On supported hosting configurations, SDS SMTP creates its SMTP master key outside both the WordPress directory and public web root. The master key is not stored in the WordPress database. Advanced installations may supply an externally managed key through documented configuration constants.

• Separate Notification Channel encryption

  Pushover, ntfy, Telegram, Discord, and Slack credentials use a separate 256-bit master key from SMTP and Microsoft Graph credentials. The Notification Channels key is created only when the first channel secret is saved.

• Stored secrets are never displayed

  Saved SMTP passwords, Microsoft client secrets, OAuth tokens, notification credentials, and webhook tokens are never rendered back into the WordPress administration interface. Administrators deliberately replace or remove a stored secret without revealing its existing value.

• Verified transport security

  Remote SMTP requires STARTTLS or SMTPS with peer and hostname certificate verification. Supported HTTP integrations use HTTPS, certificate verification, disabled redirects, bounded responses, and short timeouts.

• Least-privilege Microsoft authorization

  Microsoft Graph uses the OAuth authorization-code flow with PKCE, a one-time expiring state value, user binding, and exact redirect, application, and tenant binding. SDS SMTP requests only delegated Mail.Send and offline_access; it does not request User.Read or application-wide mailbox access.

• Conservative duplicate prevention

  Fallback SMTP is attempted only after a definite Primary failure that occurred before confirmed message acceptance. Timeouts, connection loss, Microsoft Graph server errors, and other uncertain submission outcomes are not replayed automatically because the original provider may already have accepted the message.

• Privacy-conscious email logging

  Logging defaults to metadata only. Stored metadata includes recipient addresses, subject, transport, delivery status, timing, and bounded diagnostic fields. Message bodies, headers, and attachment names are stored only when an administrator enables Full logging, and that optional content is authenticated-encrypted at rest.

• Bounded retention and cleanup

  Email logs default to 30-day retention and a maximum of 10,000 entries. Administrators can adjust the limits, delete individual entries, or disable logging. Scheduled cleanup removes records exceeding the configured age or entry limit using bounded database work.

• Minimal notification payloads

  Failure and recovery notifications contain only bounded operational information such as the website hostname, incident category, duration, and recovery state. They exclude email recipients, subjects, message bodies, SMTP responses, credentials, and WordPress administration URLs.

• Protected administrative actions

  SDS SMTP uses a dedicated WordPress management capability. State-changing administration requests require both authorization and a WordPress nonce. The external Microsoft OAuth callback requires the same capability plus verified one-time state and PKCE values.

• Fail-closed configuration handling

  Malformed credentials, settings, encryption state, or overlapping Primary transports are not silently repaired or used. SDS SMTP disables the affected operation and reports the problem rather than guessing at a configuration that could expose credentials or misroute email.

• No telemetry

  SDS SMTP does not send analytics, usage statistics, activation reports, diagnostic reports, email metadata, credentials, or site activity to SDS International. Communications with configured mail providers and enabled Notification Channels are functional service requests, not telemetry.

• Verified data removal

  Deactivation does not delete persistent data. When complete deletion is enabled, uninstall removes and verifies plugin-owned settings, logs, encrypted credentials, notification state, scheduled events, capabilities, and SDS-managed encryption keys. Administrator-managed external key files are never deleted.

Technical Details

Changelog