Every email sent at commercial scale travels through a layered technical stack — from the campaign management platform that assembles the message, through the MTA that routes it, across an SMTP session negotiated with the recipient server, to the inbox provider that makes the final delivery decision. Understanding how these layers interact is the foundation for diagnosing deliverability problems, designing reliable sending systems, and making informed infrastructure decisions.
The Email Delivery Stack: Layer by Layer
Modern email delivery infrastructure has five distinct functional layers. Each layer has specific responsibilities and specific failure modes. Deliverability problems almost always trace to one of these layers failing — and most are misdiagnosed because teams look at the wrong layer.
MailWizz (or equivalent) handles list management, segmentation, template rendering, personalisation, campaign scheduling, and tracking link generation. The platform assembles each message and passes it to the MTA for delivery. Most bounce handling and suppression management also lives at this layer.
PowerMTA accepts messages from MailWizz via SMTP injection, manages the outbound delivery queue, routes messages to the correct destination MX servers, applies per-ISP throttle controls, handles bounce processing and retry logic, and generates the accounting logs that feed deliverability analytics.
Dedicated sending IPs with correctly configured rDNS (PTR records), HELO/EHLO hostnames that match PTR, SPF records authorising the sending IPs, DKIM signing keys, and DMARC policy records. Authentication failures at this layer cause delivery failure regardless of IP reputation or content quality.
The actual delivery of each email happens through an SMTP session: TCP connection to recipient MX server, EHLO, MAIL FROM, RCPT TO, DATA, and QUIT. The recipient server evaluates the sending IP reputation, domain reputation, authentication status, and content score during this session and returns a 250 (accepted), 4xx (temporary failure, retry), or 5xx (permanent failure, bounce).
Gmail, Outlook, Yahoo, and corporate mail servers apply their own filtering algorithms post-acceptance. An email accepted at the SMTP layer (250 response) can still be placed in spam, the Promotions tab, or silently discarded by the ISP filter. Inbox placement is determined at this layer by sender reputation, engagement signals, and content analysis.
PowerMTA in the Delivery Architecture
PowerMTA occupies Layer 2 and acts as the routing and control layer between MailWizz and the internet. Its most operationally significant capabilities are:
Virtual MTAs (VMTAs). PowerMTA allows a single installation to present multiple virtual sending identities, each with its own IP pool, EHLO hostname, and queue management settings. A typical production deployment uses separate VMTAs for marketing email, transactional email, and cold outreach — so that each stream has dedicated IP pools and can be throttled independently without affecting the others.
Per-ISP Throttle Control. Different ISPs have different connection limits, message-per-second rates, and retry tolerance policies. Gmail accepts high concurrency but is sensitive to complaint rate. Microsoft imposes strict per-IP message rate limits for new senders (451 4.7.650 responses are rate-limiting signals, not permanent rejections). Yahoo is sensitive to connection speed but has published FBL data. PowerMTA domain-based throttle configuration applies different limits to each destination domain — so Gmail gets 200 concurrent connections while a smaller ISP with stricter limits gets 2.
Bounce Classification. PowerMTA parses SMTP response codes from recipient servers and classifies each delivery outcome as: delivered, soft bounce (temporary failure, retry), hard bounce (permanent failure, suppress), or unroutable. The classification drives automatic suppression of permanently failed addresses — preventing continued sending to addresses that have already returned 550 (Mailbox not found) or 551 (User not local) responses.
DNS Authentication: The Non-Negotiable Foundation
Google, Yahoo, and Microsoft now require full authentication compliance for commercial senders. Failure to meet authentication requirements results in rejection or spam classification regardless of IP reputation or content quality. The three required records:
| Protocol | What It Does | Common Failure Mode |
|---|---|---|
| SPF | Declares which IP addresses are authorised to send email for a domain | More than 10 DNS lookups (PermError), or no SPF record at all |
| DKIM | Cryptographic signature that proves the email was not modified in transit and was authorised by the domain | Key rotation without updating DNS, message modification breaking signature, wrong selector |
| DMARC | Policy that tells ISPs what to do if SPF or DKIM fails, and requests aggregate reports | p=none is not protective; p=reject/quarantine required for full protection and Google compliance |
Reverse DNS (PTR records) is a fourth authentication element that is technically separate from the SPF/DKIM/DMARC stack but equally critical. Every sending IP requires a PTR record that resolves to a hostname matching the EHLO string in the SMTP session. Missing or mismatched PTR records cause Microsoft and many ISPs to classify email as spam regardless of other authentication status.
Monitoring the Architecture
A production email delivery architecture requires monitoring at each layer. Key monitoring points:
- PowerMTA accounting logs: Per-domain delivery rates, deferral codes, connection accept rates, and SMTP response code distributions. The first layer of delivery diagnosis.
- Google Postmaster Tools: Domain reputation tier and spam rate at Gmail. Requires DNS TXT verification. Data appears 24-48 hours after first sends to Gmail addresses.
- Microsoft SNDS: IP-level complaint rate and colour status for Outlook/Hotmail recipients. Requires JMRP registration.
- Blacklist monitoring: Continuous checks against major DNSBLs (Spamhaus SBL/XBL/PBL, Barracuda, SORBS, Spamcop). Blacklist entries require immediate action — delisting requests and investigation of the cause.
- MailWizz campaign analytics: Open rates, click rates, unsubscribe rates, and complaint rates at the campaign and list segment level. Aggregate engagement trends are leading indicators of reputation trajectory.
Our managed infrastructure service includes continuous monitoring of all five data sources with alerting when metrics move outside normal ranges. See our Operational Notes for detailed guidance on monitoring each component of the delivery stack.
Frequently Asked Questions
What is the difference between delivery rate and inbox placement rate?
Delivery rate is the percentage of messages accepted by the recipient server (250 response). Inbox placement rate is the percentage of those accepted messages that land in the primary inbox rather than spam, Promotions, or other folders. An email can have 99% delivery rate and 40% inbox placement rate — meaning most emails were accepted by the server but then classified as spam by the ISP filter. The distinction matters enormously for programme performance.
Why does per-ISP throttle control matter?
Different ISPs enforce different connection and message rate limits. Sending at the same rate to Gmail, Microsoft, and a small corporate mail server ignores these differences. Gmail can handle thousands of concurrent connections; a small corporate server may only accept 5. Microsoft imposes per-minute message rate limits for new senders. PowerMTA per-ISP throttle rules prevent overloading ISPs that generate rate-limit responses, which would cause message deferral and delay.
Can I use a self-hosted architecture with your infrastructure?
Yes. We provide managed infrastructure where our team handles the PowerMTA and MailWizz operational layer. For organisations that want self-hosted control with expert setup assistance, we offer installation and configuration consulting. The architecture documentation in our operational notes section provides detailed technical guidance for self-managed deployments.
What PowerMTA version do you run?
We run the current production release of PowerMTA (6.x), updated as new stable versions release. The 6.x series added REST API capabilities and improved MX handling that we use in our production configuration. Clients are notified of planned PowerMTA upgrades with at least 48 hours advance notice.
Get This Architecture Running for Your Organisation
Our managed infrastructure includes the complete PowerMTA + MailWizz delivery stack, configured and monitored by our team. You provide the campaigns and the list — we provide the infrastructure that delivers them.
View Infrastructure Plans →Related Services
PowerMTA + MailWizz
Dedicated infrastructure. Managed operations. Full deliverability control. Starting at €490/month.
View Plans