Documentation — Managed Email Infrastructure

This documentation covers a different layer than the API provider documentation you're probably familiar with. Postmark, Mailgun, and SendGrid document REST endpoints and webhook handlers — the code-first integration surface for transactional email. We document the operational layer: how dedicated PowerMTA + MailWizz infrastructure is provisioned, configured, monitored, and recovered when something goes wrong. Both layers are necessary; they just answer different questions. If you need a quickstart for the Postmark API, you're in the wrong place. If you need to understand the 14-day path from contract signing to your first production campaign on dedicated infrastructure, this is it.

Quickstart — first 60 minutes after signing

The most common question after contract signing: "What do I do first?" The five-step quickstart below is the actual path from signing to having your environment ready for the formal onboarding sequence. None of these steps requires writing code; they require coordinating DNS access and authorizing ownership.

Onboarding timeline — 14 days from signing to first campaign

Onboarding is structured as five hard milestones across 14 calendar days. Each milestone has a specific deliverable and a clear owner (us or you). The cadence assumes typical commercial onboarding; expedited timelines (5-7 days) are possible for clients migrating an existing program with established reputation, and longer timelines (21-30 days) are sometimes warranted for programs requiring extensive list cleanup before first send.

The detailed checklist for each milestone is in Onboarding Process. Before the formal sequence starts, the Getting Started guide walks through the prerequisites and decisions you need to make in week 1.

Documentation sections

The documentation is organized into four operational areas: orientation, configuration, monitoring, and recovery. Each section is structured to match a specific question you'll be answering during the lifecycle of your sending program. The four guides below are the published sections; additional reference material (specific PowerMTA configuration patterns, MailWizz integration recipes, custom monitoring setups) is added quarterly based on client request volume.

Configuration access tiers — what you control directly vs what requires engineering review

Managed infrastructure draws a line between what clients control directly and what requires engineering review. The line we draw protects clients from accidental configuration that damages reputation while preserving the agility that makes infrastructure useful. Three tiers map to typical sender profiles:

Monitoring access — what you can see in real time

Visibility is the foundation of operating any high-volume sending program. Without real-time monitoring, the gap between "something went wrong" and "I know what went wrong" can be hours — and at high volumes, hours matter. The monitoring stack provided with managed infrastructure is structured around four data layers: deliverability metrics, infrastructure telemetry, ISP-side reputation feedback, and external blocklist surveillance.

Incident severity model and response SLAs

Not every incident needs the same urgency. The severity model below defines the four classification tiers and the response SLAs we maintain. Severity 1 incidents include direct phone escalation; Severity 2-4 use the standard ticketing flow.

The full incident response runbook including the severity-classification decision tree, the seven most common incident playbooks, and the escalation contacts is in Incident Response.

API access — what's exposed and what isn't

Managed PowerMTA infrastructure exposes a different API surface than transactional email API providers. Understanding this difference upfront avoids integration mismatches: you can't drop in our infrastructure as a Postmark/Mailgun replacement at the API layer, because the architectural model is different. What we expose is the layer above the SMTP transaction — campaign and list management, monitoring data, and event streams.

Common integration patterns

The four most common integration architectures we see across clients, with the trade-offs of each:

Where managed infrastructure fits versus API providers

The transactional email API ecosystem (Postmark, Mailgun, SendGrid, Resend, Amazon SES, Brevo) and managed PowerMTA infrastructure are complementary, not competing. Understanding when each fits saves migration cycles and operational pain. The fundamental distinction:

• API providers are optimized for code-first integration. You send messages by calling REST endpoints; they handle the underlying SMTP, IP reputation, and ISP relationships. Pricing is per-message-sent. Best for transactional volumes (less than 10M emails/month) where developer time is the constraint.
• Managed PowerMTA infrastructure is optimized for operational control at scale. You have dedicated IPs, dedicated MTA instances, and direct access to the throttling and routing layer. Pricing is by infrastructure footprint, not per message. Best for high-volume senders (more than 5M emails/month per program) where reputation isolation, custom routing, or compliance requirements drive the architecture.

The migration patterns we've seen go in both directions:

External references and learning resources

Documentation linking to canonical external sources rather than reproducing them. The following are the references we use ourselves and direct clients to:

• PowerMTA documentation: The official Bird (formerly SparkPost / Port25) PowerMTA documentation is the source of truth for product capabilities and configuration syntax. Available at the Bird customer portal.
• MailWizz user guides: Official documentation at mailwizz.com/kb covers UI workflows, list management, campaign creation, and the API reference.
• Spamhaus FAQs: Definitive on Spamhaus zone semantics and listing/delisting policy at spamhaus.org/faqs.
• Microsoft SNDS: Direct portal at SNDS (migrating to new URL May 2026).
• Google Postmaster Tools: Domain-level reputation at postmaster.google.com.
• M3AAWG best practices: Industry consortium publishing operational best practices at m3aawg.org.
• RFCs: Protocol specs at rfc-editor.org. The most relevant for sender operations: RFC 5321 (SMTP), RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 8461 (MTA-STS), RFC 8617 (ARC).
• Our DNSBL Reference: The 12 DNSBLs that matter, response code mapping, severity tiers, and remediation playbooks at DNSBL Reference.
• Our Glossary: Curated email infrastructure terminology with operational treatment at glossary.

Frequently asked questions

How does managed PowerMTA documentation differ from API provider documentation?

API providers (Postmark, Mailgun, SendGrid) document REST endpoints, SDK installation, and webhook handlers — code-first integration. Managed PowerMTA documentation describes the operational layer: how the dedicated infrastructure is provisioned, what configuration parameters apply to your account, the monitoring access provided, and the incident response procedures when something needs a human. Both layers are necessary, but they answer different questions for different roles.

What's the typical onboarding timeline?

14 calendar days from contract signing to first production campaign, with hard milestones at days 1, 3, 7, 10, and 14. Day 1: account provisioning + DNS access requirements communicated. Day 3: dedicated IPs allocated, SPF/DKIM/DMARC records published. Day 7: PowerMTA + MailWizz instance ready, IP warmup schedule activated. Day 10: deliverability monitoring connected (SNDS, GPT, FBLs). Day 14: first scheduled production campaign with full reputation infrastructure in place.

How is configuration access provided?

Configuration access is tiered. Tier 1 (always): dashboard access to MailWizz with campaign building, list management, suppression lists, and reporting. Tier 2 (on request): direct PMTA Manager access for VirtualMTA configuration, throttle rules, and per-domain routing. Tier 3 (engineering review): root SSH access on dedicated infrastructure for clients with internal mail engineering teams. Most clients operate at Tier 1; Tier 2 is the most common upgrade.

What monitoring access do you provide?

Real-time PowerMTA queue and throughput dashboards, hourly DNSBL checks across 50+ lists with 5-minute alerting, MailWizz campaign analytics, daily reputation reports from SNDS and Google Postmaster Tools (when registered to your domain), and weekly deliverability reviews summarizing inbox placement trends. Custom monitoring (log shipping to your SIEM, Prometheus/Grafana endpoints) is available at Tier 2.

What's the incident response SLA?

Severity 1 (delivery completely down for your IPs): response within 15 minutes, 24/7. Severity 2 (significant placement degradation, single ISP affected): response within 1 hour during business hours (Estonia time, GMT+2/+3). Severity 3 (configuration questions, optimization requests): response within 4 hours, business days. Severity 4 (general inquiries, feature requests): 1-2 business day response. Severity 1 incidents include direct phone escalation paths.

Do you provide API access?

Yes, but it's a different layer than Postmark/Mailgun-style APIs. We expose the MailWizz API for programmatic campaign management (list operations, campaign creation, statistics retrieval), the PowerMTA log access for shipping events to your stack, and webhook delivery for FBL events and bounces. We do not expose a high-level REST API for individual email sending — that pattern is better served by Postmark or Mailgun than by managed PowerMTA. Customers typically integrate at the MailWizz API level.

How is documentation kept current?

Documentation is reviewed quarterly against current vendor docs (PowerMTA release notes, MailWizz changelogs), and updated immediately for any breaking change in our infrastructure. The "Last updated" timestamp on each guide is authoritative — guides older than 6 months without revision are flagged in our review queue. Critical changes (new authentication requirements from Gmail/Yahoo, breaking SNDS migrations) trigger same-day documentation updates and customer notifications.

Can I export my data and configuration?

Yes, at any time. Lists, suppressions, and campaign history are exportable from MailWizz in standard CSV/SQL formats. PowerMTA configurations (config files, virtual MTA definitions) are provided on request. There is no vendor lock-in mechanism — the infrastructure is built on standard PowerMTA + MailWizz, so migration to self-hosted or to another managed provider is straightforward technically. We will support export and migration assistance for any client leaving the platform without prejudice.

What if our team has internal PowerMTA expertise?

Tier 3 access (root SSH) is designed for exactly this case. Internal mail engineering teams get direct visibility into PowerMTA configuration files, accounting logs, and the ability to make changes within the boundaries of our shared operational responsibilities. Engineering review is required for changes that affect IP reputation or shared infrastructure, but day-to-day configuration is yours to control.

How do you handle DNS for sending domains?

Two patterns: (1) you delegate a subdomain (typically m.yourdomain.com) to NS records we manage — fastest, cleanest separation between your application DNS and sending DNS; (2) you publish records we provide on your existing DNS — slower (depends on your team's DNS update cadence) but keeps DNS authority entirely with you. The delegation pattern is recommended for clients with multiple sending domains or who want to isolate marketing DNS from corporate DNS.