Documentation / Provider playbooks

T-Online Delivery Operations

Production-oriented PowerMTA playbook for T-Online, including conservative controls, monitoring signals and change management.

PowerMTA 5.xUpdated 2026-07-19Operational reference2 min read

PowerMTAv4.1 frameworkProduction reference

Review before production. Adapt hostnames, IPs, credentials, paths and limits to your licensed PowerMTA release and validate syntax in a staging environment.

Operational objective

Apply cautious connection limits and validate DNS, TLS and recipient quality before changing throughput.

Preserve stable source IP, HELO and PTR identity
Use aligned SPF, DKIM and DMARC
Separate provider outcomes in reporting
Change one control at a time

Conservative starting profile

# Illustrative provider policy for T-Online
<domain t-online.example-provider-group>
  max-smtp-out 2
  max-msg-per-connection 10
  max-msg-rate 120/h
  retry-after 20m
  bounce-after 4d
</domain>

# Map actual recipient domains using an audited pattern list.
# Verify all directive syntax against your installed PowerMTA version.

The values are intentionally illustrative. Start from your verified traffic history, permission model and provider feedback.

Signals to monitor

Signal	Interpretation	Action
Queue age rising	Delivery is slower than intake	Inspect recent response codes before changing rates
Temporary failures concentrated	Provider-specific throttling or policy issue	Isolate by VMTA, domain and response family
Hard bounces increasing	Recipient quality or list hygiene issue	Suppress invalid recipients immediately
Complaints increasing	Permission, expectation or segmentation problem	Pause affected stream and investigate

Change workflow

Capture a baseline window from accounting logs.
Group outcomes by provider, VMTA and campaign stream.
Change only the smallest relevant rate or connection control.
Observe long enough to distinguish noise from trend.
Record the change and rollback condition.

Common mistakes

Using a catch-all domain rule before provider-specific rules.
Rotating HELO or DKIM identity during a reputation incident.
Increasing concurrency while queue age is already rising.
Ignoring complaints because SMTP acceptance remains high.

Validation checklist

Configuration parses and service restarts cleanly
Expected VMTA is selected for test messages
Accounting logs expose provider response codes
Rollback configuration is available
Post-change queue age and complaint rates are reviewed