Fastmail Delivery Operations

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

PowerMTA 5.xUpdated 2026-07-19Operational 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

Use standards-compliant authentication, stable source identity and evidence-based retry behavior.

  • 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 Fastmail
<domain fastmail.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

SignalInterpretationAction
Queue age risingDelivery is slower than intakeInspect recent response codes before changing rates
Temporary failures concentratedProvider-specific throttling or policy issueIsolate by VMTA, domain and response family
Hard bounces increasingRecipient quality or list hygiene issueSuppress invalid recipients immediately
Complaints increasingPermission, expectation or segmentation problemPause affected stream and investigate

Change workflow

  1. Capture a baseline window from accounting logs.
  2. Group outcomes by provider, VMTA and campaign stream.
  3. Change only the smallest relevant rate or connection control.
  4. Observe long enough to distinguish noise from trend.
  5. 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
Search Trushilla Documentation