# Zupost ## Security > Category: Resources --- ## Pages ### Getting started - [What is Zupost?](https://docs.zupost.com/getting-started/what-is-zupost) - [Rate Limits](https://docs.zupost.com/getting-started/rate-limits) ### Quickstart - [Node.js](https://docs.zupost.com/quickstart/node-js) ### Resources - [Security](https://docs.zupost.com/resources/security) - [Acceptable Use](https://docs.zupost.com/resources/acceptable-use) - [Data Processing](https://docs.zupost.com/resources/data-processing) --- # Security At Zupost, security is not treated as a checkbox or an afterthought. It is a core part of how the product is designed, operated, and improved. Email infrastructure sits in a sensitive position within a company’s stack. It is often involved in sign-in flows, password resets, billing notifications, order confirmations, marketing campaigns, account alerts, and other critical customer communication. That means security matters at every level: infrastructure, access control, template management, API usage, internal processes, and abuse prevention. Zupost is built for teams that want reliable email delivery, a strong European infrastructure story, and a workflow that keeps email content manageable over time. Instead of hardcoding full email content directly into application code, customers manage templates centrally in Zupost and send emails by referencing a template ID together with recipient and variable data. This model improves collaboration, reduces operational friction, and creates a cleaner foundation for maintainable email systems. This page explains how we approach security, what principles guide our decisions, and what customers should keep in mind when using Zupost in production. ## Our approach We believe good security starts with clear principles. ### Security by design Security is considered during product architecture, infrastructure setup, workflow design, and operational processes. The goal is not only to protect the platform itself, but also to help customers use Zupost in a safer and more structured way. ### Least privilege Access should only be granted where it is actually needed. This applies to internal systems, operational processes, and customer-facing product permissions. Reducing unnecessary access reduces unnecessary risk. ### Defense in depth No single control is enough on its own. Security is strongest when multiple layers work together: authentication, authorization, infrastructure hardening, monitoring, operational processes, and product-level safeguards. ### Operational ownership Zupost operates its own SMTP delivery infrastructure rather than using a third-party cloud email sending backend. This gives us more direct control over how delivery infrastructure is configured, monitored, maintained, and secured. ### Practical transparency We prefer clear and grounded communication over vague claims. Security is too important for marketing language that sounds impressive but says very little. We aim to communicate in a way that is understandable, credible, and useful to technical and non-technical teams alike. ### Infrastructure and platform design Zupost is built around direct operational control of the sending infrastructure. Instead of outsourcing the actual message delivery layer to another sending provider, Zupost runs its own SMTP nodes. This matters for several reasons. First, it gives us more direct control over configuration, maintenance, delivery behavior, and security-related improvements. Second, it supports our Europe-first product direction and our focus on stronger infrastructure sovereignty. Third, it allows us to build the platform around the needs of Zupost customers instead of inheriting the constraints of an underlying email sending service. From a security perspective, operating our own delivery layer allows tighter control over areas such as: - infrastructure configuration and hardening - message delivery behavior - abuse prevention measures - operational monitoring - delivery diagnostics - platform-specific security improvements Owning the infrastructure does not automatically make a system secure. It means the responsibility sits with us directly, and we take that responsibility seriously. ## Why the Zupost template model improves control A defining part of Zupost is the way emails are created and sent. With Zupost, applications typically do not send fully assembled email HTML or text bodies from code. Instead, they send: - a template ID - a recipient - the variables needed for rendering Zupost then renders the final email from the centrally managed template and handles delivery. This approach has important operational and security advantages. ### Less content spread across repositories and services When email content is stored directly inside application code, it often ends up duplicated across multiple repositories, services, environments, or deployments. Over time, this becomes harder to manage, harder to review, and easier to lose track of. Central template management reduces that sprawl. ### Clearer separation between code and communication content Application code can focus on business logic, while templates are managed in a dedicated interface designed for that purpose. This creates cleaner responsibilities across engineering, product, marketing, and operations. ### Safer collaboration Non-developers can update and maintain email templates without needing repository access or deployment rights. That reduces the need to expand technical access just to change text, layout, or content. ### More consistent production behavior When templates are updated centrally, teams do not need to redeploy every application that uses them. This makes it easier to keep communication consistent and reduces the chance of outdated template versions staying active somewhere in production. This does not remove the need for good security practices. Customers should still be careful about who can edit templates, what data is passed into them, and which templates are considered sensitive. But the overall model creates a more structured and controllable foundation than scattering email content across codebases. ## Access control and account security Protecting access to Zupost accounts and workspaces is a core part of platform security. Access to production email systems should never be broader than necessary. That is especially important because email platforms often control sensitive communications such as login links, verification emails, invoices, transactional notices, and customer updates. A strong access model should separate responsibilities wherever possible. In practice, different users may need different levels of access. For example, one person may only need to edit templates, while another may need to manage domains, credentials, or sending settings. Depending on the customer’s internal setup, sensitive actions may include: - managing templates - changing domains or DNS-related settings - creating or rotating API credentials - managing team members and permissions - viewing message activity - accessing operational sending settings Customers should review workspace access regularly and remove users who no longer need it. This is especially important when teams grow, roles change, or contractors and external collaborators are involved. ## API and credential security Zupost is designed to be integrated into applications, backend services, and internal workflows. That makes API credentials an important part of the overall security model. API keys and similar credentials should be treated as secrets at all times. They should never be placed in public repositories, client-side code, screenshots, shared documents, or unsecured internal notes. Customers should use secure secret storage and environment variable management appropriate to their own infrastructure. Production credentials should be kept separate from development, preview, and staging environments. That separation reduces risk and makes incident response easier if a credential is ever exposed. As a general rule, customers should also rotate credentials when: - exposure is suspected - team access changes - an integration is retired - a standard security review requires renewal Long-lived credentials should never be treated as permanent. ## Data handling Zupost processes the information needed to render and send emails. Depending on how the platform is used, this may include recipient information, template metadata, rendering variables, message-related metadata, and delivery-related operational data. Good security in this area is not only about protecting data after it enters the system. It is also about reducing unnecessary exposure in the first place. ### Data minimization Customers should only send the data that is actually needed to render and deliver a specific email. If a value is not necessary for the email content or sending workflow, it should usually not be included. As a best practice, highly sensitive secrets or broadly scoped internal credentials should never be passed into templates or rendering payloads. ### Structured rendering flow Because rendering happens inside a controlled platform workflow, email generation can be standardized instead of being implemented differently across multiple services. This reduces inconsistency and makes behavior easier to reason about. ### Operational metadata Like other email systems, Zupost may process operational metadata that is necessary for delivery, routing, diagnostics, reliability, and abuse prevention. This kind of data helps keep the system stable and secure. ## Template security Templates are one of the most important assets in Zupost. They are also one of the most visible parts of a customer’s communication with their own users. That is why template security is not just about technical protection. It is also about process, review, and responsible handling. ### Central management and controlled change Templates managed in one place are easier to review, update, govern, and maintain than templates spread across multiple applications. This is one of the biggest practical advantages of the Zupost model. ### Special care for high-impact templates Some templates deserve additional internal review because they directly affect trust, security, or legal communication. Examples include: - password reset emails - login or verification emails - invoice and billing emails - account alerts - compliance or policy notifications Customers should treat these templates as high-impact communication assets and apply appropriate internal review standards before changes go live. ### Safe use of variables Dynamic variables are a powerful part of the Zupost workflow, but they should be used responsibly. Customers should avoid treating template variables as a place to pass arbitrary internal objects, unnecessary personal data, or information that end users were never meant to see. The more disciplined the input data is, the easier it is to keep templates secure, understandable, and predictable. ## Domain authentication and delivery security Email security does not stop at the application layer. Proper domain setup is a critical part of running a trustworthy and reliable email operation. Customers should correctly configure email authentication records such as SPF, DKIM, and DMARC where applicable. These records help establish sending legitimacy, improve alignment, reduce spoofing risk, and support a stronger overall sender posture. Correct DNS and domain authentication are not only deliverability concerns. They are also part of a responsible security setup. Email delivery also depends on communication with recipient infrastructure outside of Zupost’s direct control. No provider can control the full path an email takes across the internet or the policies of every destination server. What matters is that the sending side is operated responsibly, standards are respected, and the delivery infrastructure is maintained with security and reliability in mind. ## Abuse prevention Operating an email platform includes a responsibility to prevent misuse. Zupost is intended for legitimate transactional and marketing communication. It is not intended for spam operations, phishing, impersonation, malware distribution, or other abusive behavior. Abuse prevention is essential not only for protecting the platform itself, but also for protecting customers, recipient trust, and the health of the sending infrastructure overall. Poor abuse controls can quickly become both a security problem and a deliverability problem. A responsible email platform should therefore pay close attention to suspicious behavior, unusual sending patterns, abuse signals, and operational anomalies. Security and deliverability are closely connected here. A platform that does not actively care about abuse prevention cannot offer meaningful long-term reliability. ## Monitoring and operational awareness Security depends on visibility. Monitoring and logging help detect suspicious activity, infrastructure issues, unusual behavior, delivery anomalies, and platform degradation. They are also important for debugging, incident investigation, and long-term resilience improvements. The purpose of operational visibility is not to collect data for the sake of it. The purpose is to maintain enough awareness to detect problems early, investigate them effectively, and improve systems over time. ## Incident response No credible security posture assumes incidents are impossible. The real goal is to reduce likelihood, reduce impact, detect problems quickly, and respond in a disciplined way. A sound incident response process typically includes: - identifying unusual behavior or security-relevant events - validating whether an actual issue exists - limiting impact where needed - investigating scope and root cause - applying remediation - reviewing what should be improved afterward Customers should also maintain their own internal response processes for issues such as compromised credentials, misconfigured domains, accidental template changes, or suspicious sending activity originating from their own environment. ## Reliability, resilience, and continuity Security and reliability are closely linked. Email is often a dependency in critical workflows such as authentication, onboarding, billing, and customer communication. If email systems fail, the impact can go far beyond a single missed message. That is why resilience matters. Operational safeguards, failure handling, recovery planning, and careful infrastructure management are part of running a serious email platform responsibly. Customers should also think about this in their own systems. If email is a critical part of a product flow, it is worth considering fallback processes and broader operational planning as well. ## Shared responsibility Security is a shared responsibility between Zupost and the customer. Zupost is responsible for securing the platform, operating the infrastructure responsibly, and designing workflows that support safe and maintainable email operations. Customers remain responsible for how they integrate and use the platform in their own environment. That includes: - protecting API credentials - limiting workspace access appropriately - configuring domains and DNS records correctly - choosing what data is passed into templates - reviewing sensitive template changes - maintaining secure upstream application logic Even a well-designed platform can be undermined by weak credential handling, poor access control, or insecure application-level practices. Strong results come from both sides doing their part. ## Responsible disclosure If you believe you have discovered a security issue in Zupost, we encourage responsible disclosure. Please report suspected vulnerabilities privately and include as much detail as possible. Helpful reports typically include: - a clear description of the issue - affected components - reproduction steps - proof of concept where appropriate - expected impact - relevant timestamps, logs, or request details Please avoid public disclosure before the issue has been reviewed and addressed. For security-related reports, contact: **[security@zupost.com](mailto:security@zupost.com)** ## What customers can expect from Zupost Customers should expect Zupost to treat security as part of core product quality. That means building and operating the platform with intention, maintaining direct ownership of the sending infrastructure, designing workflows that reduce unnecessary complexity, and taking abuse prevention and operational integrity seriously. We believe strong security is not about dramatic claims. It is about building a platform that is structured, understandable, carefully operated, and trustworthy in day-to-day use. If you have security questions about your setup, your sending architecture, or your planned use of Zupost, feel free to contact us.