Building an email marketing product and operating the infrastructure that delivers its email are two separate engineering problems. The first is about interfaces, contact data, segmentation and automation. The second is about relay operation, sender reputation, abuse control and what happens when a receiving mail server decides it no longer trusts your traffic. A team can be excellent at the first and have no particular advantage at the second.
That raises a practical question: why build every layer of the delivery stack yourself? Many platforms conclude they should not, keeping the customer-facing product in-house and using specialised infrastructure for the relay layer beneath it.
EmailZoro, an email marketing platform operating both an independent product and a Shopify app, is a working example. EmailZoro uses PhotonConsole as its SMTP relay infrastructure partner for applicable email delivery, while retaining its own platform, workflows and merchant experience.
This article explains the reasoning behind that model — including one problem that is specific to marketing platforms and rarely discussed: a platform is accountable for sending traffic it did not create.
An Email Marketing Platform Is More Than an Email Sender
An email marketing platform is a data and workflow product. Sending is the last step, not the substance.
The product layer typically covers:
- Contact management — importing, storing and de-duplicating recipient records
- Lists and segmentation — defining audiences from attributes and behaviour
- Campaign creation and templates — editor, template library, custom HTML
- Scheduling and automation — send-now, send-later, recurring and triggered sequences
- Engagement monitoring — opens, clicks and campaign reporting
- Ecommerce workflows — store synchronisation, cart tracking, recovery sequences
- User experience — the interface customers actually evaluate and pay for
EmailZoro provides capabilities across all of these, and its WDT Emailzoro Shopify app adds store customer synchronisation, segmented campaigns, abandoned-cart tracking and automated recovery emails with recovered-order reporting.
None of that solves the delivery problem. A perfectly designed segmentation engine does not make a receiving mail server accept the message. The product layer decides what to send and to whom. Something else has to move it, and take responsibility for what happens when it does not arrive.
What Actually Happens After a User Clicks “Send”?
The path from a campaign send to a delivery outcome runs through several stages. This is a simplified conceptual model, not the proprietary implementation of any specific platform.
- A user creates or triggers an email.
- The application prepares the message and resolves the recipient set.
- The email or API layer passes it toward the delivery infrastructure.
- An SMTP relay accepts and processes approved traffic.
- Sender identity and authentication considerations apply.
- Delivery attempts are made against recipient mail servers.
- Recipient mail systems accept, defer, reject or filter.
- Delivery signals such as bounces and complaints return as feedback.
Stages four through eight are the infrastructure layer. Our pillar guide to email delivery infrastructure for SaaS covers each component in depth. The rest of this article is about why a marketing platform in particular may choose not to own them.
The Problem Specific to Marketing Platforms: Traffic You Did Not Create
An email marketing platform is accountable for sending behaviour it does not control. Its customers build the lists. Its customers decide what “consent” meant when they collected an address. The platform carries the consequences.
This is the structural difference between a marketing platform and an ordinary SaaS product. A project management tool sending notification email answers for its own list. A marketing platform answers for thousands of lists assembled by other people to standards it did not set.
Several consequences follow, and none of them are solved by having a working mail server:
- Complaint attribution. When complaint rates rise across shared sending infrastructure, the platform has to determine which tenant caused it — quickly, and before shared reputation degrades for everyone else.
- Tenant vetting. Self-serve signup combined with bulk sending is precisely the profile abusers look for. Deciding who may send, and how much, becomes an operational function rather than a policy page.
- Consent verification. A platform cannot inspect how every customer built a list, but it is answerable for the aggregate result when those lists are mailed.
- Isolation. One customer importing a purchased list can affect delivery for unrelated customers sharing the same infrastructure. Containing that requires structure that exists before the incident, not after.
- Onboarding friction versus risk. Every control that reduces abuse also adds friction to legitimate signup. That tension is permanent and has to be actively managed.
This is the real infrastructure burden for a marketing platform. It is not “can we run an SMTP server.” It is “can we run an abuse and reputation operation, continuously, alongside building the product.”
Why Building the Entire SMTP Infrastructure In-House Is a Different Problem
Operating delivery infrastructure internally means taking on a set of ongoing responsibilities that do not appear in a product roadmap.
Depending on how much of the stack a company owns, these can include:
- Infrastructure operation — running the relay with capacity for peak campaign load
- Delivery monitoring — visibility into acceptance, deferral and rejection patterns
- Traffic management — shaping volume so a large campaign does not read as an anomaly
- Reputation and abuse — tracking sender standing, detection, enforcement and the judgement calls involved
- Sender authentication — per-customer SPF, DKIM and DMARC configuration at scale
- Bounce and complaint processing — automated suppression, applied consistently
- Operational maintenance — patching, credential rotation, blocklist remediation
- Scaling — new work introduced at each growth step rather than smoothly
- Incident response — someone on call who understands delivery, not just servers
None of this argues that building internally is wrong. Some organisations have good reasons: unusual compliance constraints, volume economics at large scale, or a requirement no provider serves. What matters is whether the ongoing cost is acknowledged. The common failure is not choosing to build — it is drifting into ownership informally, with no one accountable for delivery operations, until a reputation problem makes the gap visible.
The Separation Between Product Layer and Delivery Layer
The two layers have different work, different skills and different failure modes.
| Product layer | Delivery infrastructure layer |
|---|---|
| Campaign creation, templates and scheduling | SMTP relay operation |
| Contacts, lists and segmentation | Approved traffic processing and delivery attempts |
| Automation and triggered sequences | Sender-quality controls and reputation-related practices |
| Engagement analytics and reporting | Infrastructure monitoring and delivery visibility |
| Ecommerce and store integrations | Responsible sending controls and abuse handling |
| Customer experience and interface | Bounce and complaint signal processing |
Separating them makes organisational sense for a simple reason: the two kinds of work have incompatible rhythms. Product work ships on a roadmap. Delivery work is continuous and largely reactive, and it does not wait for a sprint boundary. Teams that hold both tend to defer the reactive half until it forces attention.
The Real-World Example: EmailZoro and PhotonConsole
EmailZoro has selected PhotonConsole as its SMTP relay infrastructure partner. PhotonConsole provides the underlying SMTP relay infrastructure for applicable approved email traffic, while EmailZoro operates the customer-facing platform.
EmailZoro runs two product experiences:
- The independent EmailZoro platform — contacts, lists, segmentation, campaigns, scheduling, templates, engagement monitoring and automation.
- The WDT Emailzoro Shopify app — customer synchronisation, segmentation, campaigns, abandoned-cart workflows, automated recovery emails and recovered-order reporting.
Both use PhotonConsole’s reputation-based SMTP relay as the email delivery backend for applicable traffic, giving EmailZoro one common delivery foundation across two customer-facing experiences rather than separate arrangements per surface.
The division holds in both directions: PhotonConsole does not build EmailZoro’s features or merchant experience, and EmailZoro does not operate the relay. The arrangement supports transactional and permission-based marketing communication, with responsible sending, sender identity, list hygiene, unsubscribe handling and anti-abuse controls forming part of the stated approach. Purchased, rented, harvested and scraped lists, spam, phishing, deceptive messaging and falsified sender identities are not permitted.
The complete announcement, including the full scope and the responsibilities each company retains, is in the EmailZoro and PhotonConsole infrastructure partnership announcement.
EmailZoro and PhotonConsole remain independent organisations. The arrangement does not create an agency, franchise or joint venture, and neither party can bind the other.
Why This Model Can Make Sense for Email Marketing Platforms
The advantages below are conditional, not automatic. Whether they apply depends on architecture, scale and the team involved.
Product focus
Engineering attention can concentrate on the campaign experience, segmentation depth and automation logic — the things customers evaluate — rather than on relay operations no customer will ever see.
Infrastructure specialisation
A provider whose primary discipline is delivery treats reputation practice and abuse handling as core work rather than as an interruption to the roadmap.
Multiple product experiences
A common infrastructure foundation can support several customer-facing surfaces — a standalone platform and a marketplace app, for instance — without duplicating sender configuration and reputation management for each.
Defined operational responsibility
An open-ended operational burden becomes a defined arrangement with a stated boundary. For some platforms that clarity matters more than any individual capability.
What About Deliverability?
Using a specialised SMTP relay does not guarantee inbox placement. No provider can promise that, because the final decision belongs to the receiving mail system.
Delivery outcomes are influenced by:
- Authentication — whether SPF, DKIM and DMARC are correctly configured and aligned
- Sender reputation — accumulated standing of the sending domain and infrastructure
- List quality — the proportion of valid, engaged, consenting recipients
- Complaint and bounce behaviour — how often recipients object, how many addresses are dead
- Sending patterns and content — volume consistency, and resemblance to patterns filters distrust
- Recipient engagement — whether messages are opened, ignored or deleted
- Receiving-provider policy — each applies its own logic, and it changes
For a marketing platform, most of these sit with the customer rather than the platform — a well-run relay cannot rescue a campaign sent to a purchased list. What the infrastructure layer contributes is removing the failures within its control and stopping one sender degrading conditions for others: a real contribution, and a different claim from guaranteed placement. Our guide to improving email deliverability covers the sender-side practices.
Transactional and Permission-Based Marketing Email
Most email marketing platforms carry both categories, and they behave differently.
Transactional communication is connected to a requested service or a specific user interaction — confirmations, notifications, account messages. Complaint rates are typically low and timing matters.
Permission-based marketing goes to recipients who have given affirmative consent or where another applicable lawful basis exists. Complaint risk is materially higher and timing tolerance is broader.
Because receiving systems evaluate reputation at the domain and IP level rather than per message, marketing complaints can affect transactional delivery sharing the same sending identity. The separation mechanics are covered in our guide to transactional versus marketing email.
Across both, responsible sending depends on accurate sender identity, functional unsubscribe mechanisms, current consent records, prompt opt-out handling, ongoing list hygiene, and treating complaints as operational triggers rather than report lines.
Build vs Use Specialized SMTP Infrastructure
| Factor | Build internally | Use specialised infrastructure |
|---|---|---|
| Engineering ownership | Full control over delivery behaviour | Control of the product layer; delivery defined by the provider |
| Infrastructure operation | Servers, IPs and capacity are yours to run | Operated by the provider as its primary product |
| Delivery expertise | Must be hired or developed in-house | Sits with the provider |
| Product focus | Attention divided between product and delivery | Attention concentrated on the product |
| Operational burden | Continuous, including out-of-hours incidents | Largely transferred, within the agreed boundary |
| Scaling | New infrastructure work at each growth step | Mainly a commercial and configuration matter |
| Reputation responsibilities | A named internal role, plus abuse operations | Maintained by the provider at the infrastructure level |
Internal ownership can make sense where compliance constraints are unusual, where volume economics justify the investment, or where the team already has genuine mail-operations capability and intends to keep it staffed. A specialised provider tends to be more practical where delivery is a dependency rather than a differentiator, where the engineering team is small relative to the roadmap, or where multiple product surfaces would otherwise each need their own arrangement.
What Should an Email Marketing Platform Look for in an SMTP Infrastructure Partner?
These questions are worth answering before committing, because the answers determine what remains your problem.
- What traffic types are supported? Transactional only, or permission-based marketing too?
- How is abuse handled? What happens when one tenant’s traffic becomes a problem, and how fast?
- What sender-quality controls exist? What is checked before traffic is accepted?
- What monitoring is available? Enough to support your own customers, not just a dashboard?
- How are delivery failures surfaced? Bounces and complaints need to reach your systems.
- How is responsible sending enforced? Stated policy is one thing; enforcement is another.
- What authentication support exists? Particularly for customers sending from their own domains.
- Can it support the product’s growth? Ask what changes at several times your current volume.
- What operational ownership remains with you? Get the boundary in writing before an incident tests it.
- Is the provider transparent about its limits? A provider that will not describe them is describing a future dispute.
Our guide to criteria developers should evaluate when choosing an SMTP relay covers the technical assessment, and SMTP monitoring tools for transactional email infrastructure covers visibility.
What the EmailZoro and PhotonConsole Partnership Demonstrates
The collaboration demonstrates a specific infrastructure model rather than a performance outcome. EmailZoro handles customer-facing email marketing — campaigns, contacts, segmentation, automation and ecommerce workflows across its platform and Shopify app — while PhotonConsole provides the specialised SMTP relay infrastructure underneath, giving EmailZoro one common delivery foundation across both product experiences.
What it shows is that using specialised infrastructure does not require giving up product control. EmailZoro’s roadmap, features and merchant experience remain entirely its own. What changed is where relay responsibility sits — which is the decision this article is about.
Key Takeaways
- Email marketing software and email delivery infrastructure are separate technical layers with different skills and failure modes.
- A marketing platform is accountable for traffic its customers create, making abuse handling and complaint attribution an infrastructure problem rather than a policy question.
- Building an email marketing product does not mean a company should build every part of its SMTP infrastructure internally.
- Specialised infrastructure can let product teams concentrate on customer-facing functionality, depending on architecture, scale and operational capacity.
- EmailZoro uses PhotonConsole as its SMTP relay infrastructure partner for applicable email delivery across its independent platform and Shopify app.
- The arrangement gives EmailZoro one delivery foundation across two product experiences while it retains its own platform and workflows.
- No infrastructure arrangement removes the need for responsible sending, consent and list hygiene.
Frequently Asked Questions
Why do email marketing platforms use SMTP relay infrastructure?
Because building campaign software and operating email delivery infrastructure are different disciplines competing for the same engineering hours. Specialised relay infrastructure lets a platform concentrate on contacts, segmentation, automation and customer experience, while a dedicated provider handles relay operation, sender-quality signals and abuse controls as its primary work.
What does an SMTP relay do for an email marketing platform?
An SMTP relay accepts approved messages from the platform and takes responsibility for delivering them to recipient mail servers. It manages connections, applies retry logic to temporary failures, interprets response codes, and returns delivery signals such as bounces and complaints. For multi-tenant platforms it is also where traffic controls are applied.
Should an email marketing platform build its own SMTP infrastructure?
It depends on the situation. Building internally can make sense with unusual compliance constraints, volume economics that justify it, or an existing mail-operations capability the company intends to keep staffed. For many platforms, specialised infrastructure is more practical because delivery is a dependency rather than a differentiator.
What is the difference between an email marketing platform and an SMTP provider?
An email marketing platform is the customer-facing product: contacts, segmentation, campaigns, templates, automation and analytics. An SMTP provider operates the delivery layer beneath it, relaying approved traffic toward recipient mail systems and handling authentication, delivery attempts and feedback signals. The platform decides what to send; the provider moves it.
Does EmailZoro use PhotonConsole for SMTP relay?
Yes. EmailZoro has selected PhotonConsole as its SMTP relay infrastructure partner for applicable email delivery across its independent platform and its WDT Emailzoro Shopify app. EmailZoro continues to manage its customer-facing platform, product workflows and merchant experience. The two companies remain independent organisations.
What does PhotonConsole provide to EmailZoro?
PhotonConsole provides the underlying SMTP relay infrastructure for applicable approved email traffic, serving as the email delivery backend across both EmailZoro product experiences. It does not provide EmailZoro’s customer-facing software. Campaign creation, contacts, segmentation, automation and Shopify functionality all remain EmailZoro’s product.
Does using an SMTP provider guarantee email deliverability?
No. Inbox placement is decided by receiving mail systems, which weigh authentication, sender reputation, list quality, complaint and bounce behaviour, sending patterns, content and recipient engagement. A specialised provider can remove infrastructure-side failures and limit the impact of one sender on others, but it cannot guarantee placement.
What should SaaS companies consider before choosing an SMTP infrastructure provider?
Which traffic types are supported, how abuse is detected and enforced, what sender-quality controls exist, what monitoring and failure reporting is available, what authentication support is offered for customer domains, how the infrastructure behaves at higher volume, and exactly where the operational boundary sits between provider and platform.
Need SMTP Infrastructure for an Email-Driven SaaS Product?
If your product sends email on behalf of its customers, the question worth settling early is which layer you intend to own, and who is accountable on the other side of that line. PhotonConsole provides specialised SMTP relay infrastructure for SaaS products, email marketing platforms, ecommerce software and applications that need a dedicated delivery layer rather than an infrastructure side project.
