YourTrend — an email, SMS & push messaging platform

01Project overview

YourTrend is a messaging platform for business: transactional and marketing email, SMS, and web push from a single API. The product's tagline reads like a promise — "Email your customers actually receive". Behind that promise sits very concrete engineering: every connected domain is DKIM-signed, SPF and DMARC records are generated automatically, sending goes out over a dedicated IP, and unsubscribes, complaints, and bounces are handled by the platform itself, with no effort from the sender.

The idea grew out of an observation familiar to anyone who has launched online products: sending an email from an application is easy, but making it land in the inbox consistently is a profession of its own. Year after year, mailbox providers tighten their requirements for sender authentication and reputation, and "plain SMTP" without DKIM, SPF, and DMARC increasingly means the spam folder — or a silent rejection. Meanwhile the business accumulates a zoo of services: one for transactional mail, another for marketing campaigns, a third for SMS, a fourth for push. Each has its own API, its own contacts, its own statistics — and no coherent picture anywhere.

YourTrend gathers all of this into one platform: an SMTP relay and a clean HTTP API for sending, campaigns and automations for marketing, SMS and web push on the same contact base, a unified inbox for incoming mail across every domain, and a zero-access encrypted mailbox for private correspondence. We designed and built the product end to end — from the delivery pipeline and the event model to the dashboard, the documentation, and the trilingual landing pages (EN/UK/RU).

Like the studio's other ecosystem products, YourTrend was never conceived as a one-off service but as a shared communications layer: connect a domain once, and all the mail of your projects — from receipts to campaigns — flows through one pipeline with one reputation, one analytics view, and one event model. Below we break down how the system works inside and which engineering decisions make deliverability a property of the architecture rather than a lucky accident.

02Context and the problem

There is a paradox about mail sent from your own application: it "works" right up until the moment it actually matters. While volumes are small, everything looks fine; as they grow and provider rules tighten, a whole set of pains surfaces:

• Spam instead of inbox. Without correct DKIM, SPF, and DMARC, even honest transactional messages end up in spam or get rejected. Configuring those records correctly on the first try is a task that trips up even experienced teams.
• Shared-IP reputation. On shared infrastructure your deliverability depends on your neighbours: someone else's aggressive blast damages the IP's reputation for everyone on it.
• Duplicates on retries. The network blinks, the application repeats the request — and the user gets two identical receipts. Without idempotency on the API side this is inevitable.
• Disconnected channels. Email in one service, SMS in another, push in a third: contacts and segments don't match, and the "single customer view" exists only in slide decks.
• Manual list hygiene. Bounces and complaints must be caught and excluded from future sends. Almost nobody does this by hand — and reputation quietly degrades with every campaign.
• Incoming mail scattered everywhere. A business with several domains has customer replies spread across mailboxes and tabs, and answering from the exact address they wrote to is a quest of its own.

The brief was this: build a platform where deliverability is not the result of painstaking configuration but a default property. The developer connects a domain, publishes the generated DNS records, and sends; everything else — signing, reputation, suppression lists, unsubscribes — the platform takes care of.

A separate layer of the task concerned the pipeline itself. A password-reset email must leave within seconds and has no right to get lost; a marketing campaign to thousands of addresses must not get in the way of the transactional stream; and for every message the sender must see what happened to it: accepted, delivered, opened, rejected, complained about. All of this with two equally supported integration paths: good old SMTP for existing applications and a clean HTTP API for new ones.

03Project goals

From the brief grew concrete product and engineering goals that we kept in focus at every stage:

• Deliverability by default. DKIM signing for every domain, automatic generation of SPF and DMARC, a dedicated sending IP, automatic suppression lists, and one-click unsubscribe.
• Two entry points — one pipeline. An SMTP relay for applications that already know how to send mail, and a REST API for everything else. Inside — the same pipeline with the same guarantees.
• Idempotency and batching. A repeated request never produces a second email; bulk sends travel in batches, not as thousands of individual calls.
• Three channels on one base. Email, SMS, and web push work with the same contacts and segments — no CSV exports between services.
• Observability. Every event — delivery, open, click, bounce, complaint — is visible in the dashboard and streamed to the sender's webhooks.
• Incoming mail in one place. A unified inbox across all domains with replies from the exact receiving address, plus a zero-access encrypted mailbox for private correspondence.

As in our other products, these goals worked as constraints that cut off unsuitable options at the design stage. The "two entry points — one pipeline" requirement forbade making the SMTP relay a "facade" with its own separate logic: both SMTP and the API drop messages into the same pipeline with the same checks. The observability requirement forced us to design the event model before the first handler was written. And "deliverability by default" meant something simple: no onboarding path may ever allow sending from a domain without correct authentication.

04What we built

YourTrend organises messaging into four pillars that together cover a business's entire communications cycle:

On top of the core sit a dashboard with analytics and domain management, a webmail client, documentation, a status page, and landing pages in three languages. Starting is free: connect a domain, publish the generated DNS records, and send your first email — the whole journey fits into three steps.

Crucially, the four pillars don't exist in isolation. The sending pipeline feeds the analytics, the analytics feed the suppression lists, the contact base feeds all three channels, and the unified inbox closes the loop by bringing recipients' replies back into the platform. The integrator works not with a bundle of services but with one system where every message shares a single lifecycle: accepted → prepared → signed → delivered → event.

05Solution architecture

Logically, YourTrend consists of six blocks, each with its own area of responsibility and clear boundaries:

• Intake — the SMTP relay (mail.yourtrend.online: authentication, STARTTLS) and the HTTP API: validation, sender verification, idempotency.
• Processing pipeline — queues: template rendering, personalisation, checking recipients against suppression lists, DKIM signing.
• Delivery — sending from a dedicated IP, managing connections to receiving servers, retries on transient failures.
• Event loop — deliveries, bounces, complaints, opens, and clicks are collected into a single stream; the dashboard and the webhooks read one source.
• Inbound loop — receiving mail for the user's domains, the unified inbox, replying from the exact address; the zero-access mailbox runs as a separate track.
• Contact graph — email addresses, phone numbers, and push subscriptions live on a single contact; segments are shared across all channels.

This division let us separate streams with different requirements. Transactional mail is latency-sensitive — its path through the pipeline is as short as possible. Campaigns are throughput-sensitive — they travel in batches and never jostle in the same queue as receipts and password resets. The event loop is deliberately kept apart: both the dashboard and the webhooks are merely readers of the same event stream, so their readings never diverge.

Roles are separated at the host level too: the landing site with documentation, the dashboard, the webmail, and the SMTP relay each live at their own address with their own access and caching policies — the public site doesn't share an environment with the interfaces where users work with their mail. Cloudflare handles DNS, TLS, and perimeter protection; an integration with it also lets a domain's DNS records be published with a single command right from onboarding.

06How a message travels

From the integrator's point of view, a message's journey fits into five steps, and most of them happen without their involvement:

• 1. Intake. The application hands over the email — an SMTP request to the relay or a POST to the API. Median API accept time is under two seconds: the request is validated, deduplicated by idempotency key, and queued.
• 2. Preparation. The pipeline renders the template, fills in the recipient's data, and checks the address against the suppression list: anyone who unsubscribed or complained will not receive the message.
• 3. Signing. The email is signed with the sender domain's DKIM key; SPF and DMARC have been published in DNS since the domain was connected. To the receiving server, the message is cryptographically bound to the domain.
• 4. Delivery. Sending goes out over a dedicated IP; transient failures — greylisting, an overloaded recipient — are handled by retries with growing intervals.
• 5. Events. Accepted, delivered, rejected, opened, clicked, complained — every event is recorded, appears in the dashboard, and is streamed to the sender's webhooks.

There is a principled detail here that we promoted into the data model: "accepted" and "delivered" are different events. The API can accept an email in a fraction of a second, but its fate is decided later, on the receiving server's side. The platform doesn't hide this difference behind a single "sent" status; it shows the whole journey: the integrator sees both the instant acceptance acknowledgement and the actual delivery outcome, and everything that happened in between.

The second detail is idempotency. Network errors are inevitable, and a client's correct reaction to a timeout is to retry the request. If both requests reach the platform, it recognises by the idempotency key that they are the same email and sends it once. The same principle protects batches: resending a batch never duplicates messages. For transactional mail this is not a convenience but a correctness requirement: two receipts for one purchase undermine trust more than one lost receipt does.

07Key capabilities

Let's look at what makes YourTrend not an "email blaster" but a production-grade communications platform.

Transactional email

Receipts, password resets, event notifications — messages the user is waiting for right now. They take the short path through the pipeline: signed, tracked, and delivered in seconds. They need no campaigns or segments — just an API call or an SMTP request from the application's code.

SMTP relay and HTTP API

An existing application doesn't need to be rewritten for a new API: it's enough to point its SMTP host at the platform's relay and supply credentials — everything the app already knows how to send now travels through YourTrend's pipeline with signing and analytics. New integrations are easier to build on REST: a JSON request, predictable responses, machine-readable errors. Around the API, the platform is ecosystem-friendly: Laravel, Node.js, Python, WordPress, Zapier, and React are among the listed integration paths.

Idempotency and batching

A repeated call with the same key never creates a second email — retries are safe by construction. Bulk sends are assembled into batches so that thousands of messages don't become thousands of individual requests: less network chatter, higher throughput, simpler code on the integrator's side.

SMS

When email isn't the right channel — a confirmation code, an urgent delivery notice — an SMS goes out from the same contact base: transactional and marketing messages, the same segments, the same event loop. No need to maintain a second phone-number database in a separate service.

Web push

Browser notifications bring users back to the site: strictly opt-in subscriptions, segmented audiences, instant delivery. For products without a mobile app this is the shortest path to "push" — no app stores, SDKs, or release cycles.

Analytics and webhooks

Opens, clicks, bounces, and complaints are visible in the dashboard — and streamed to webhooks in parallel. The dashboard is convenient for humans, webhooks for code: you can build your own logic on top of the events (say, flagging hard-bounced addresses in your own CRM) without polling the API in a loop.

08Deliverability as engineering

Deliverability is often treated as magic, or as a "warm-up" service billed by subscription. We approached it as an engineering problem with concrete components, each of them built into the platform:

• DKIM for every domain. Every connected domain gets a key, and every email is signed: the receiving server cryptographically verifies that the message really comes from your domain and wasn't altered in transit.
• SPF and DMARC — generated for you. The platform doesn't send the user off to read RFCs: the ready-made records can be copied into DNS as they are — or published with a single command via the Cloudflare integration.
• A dedicated sending IP. Reputation isn't shared with other people's campaigns: your mail leaves from an address whose history only you shape.
• One-click unsubscribe (RFC 8058). List-Unsubscribe with one-click: the recipient unsubscribes with a button in their mail client, without opening a website. It's a requirement major providers impose on bulk senders — and the best way to turn a potential complaint into a quiet unsubscribe.
• Automatic suppression. A hard bounce, a complaint, an unsubscribe — the address automatically lands on the suppression list and is excluded from future sends. Lists clean themselves; reputation doesn't degrade.

Order matters here: authentication without list hygiene doesn't save you, and hygiene without authentication is pointless. That's why these mechanisms are not "features on a price list" but mandatory parts of the pipeline: the platform won't send from an unverified domain and won't let complaints be ignored. The sender can forget about deliverability precisely because the architecture won't let them forget it in any way that matters.

09Security and zero-access mail

A platform that carries other people's transactional mail has to be meticulous about access. Sending through the SMTP relay requires authentication and is protected by STARTTLS; API access is by sender keys; all traffic runs over TLS only. One-click unsubscribe and automatic suppression also work as security mechanisms: they prevent the platform from being turned into a source of unwanted mail, and the published anti-spam policy enshrines this in rules that protect both recipients and the reputation of honest senders.

A distinct part of the product is the zero-access encrypted mailbox. It's mail for private correspondence built on end-to-end encryption: content is encrypted on the user's side, and the server stores only ciphertext. "Zero-access" is literal here: the platform has no technical ability to read these messages — there are no keys, nothing to hand over on request, and nothing to lose in a compromise.

We deliberately separated the two circuits. Regular mail comes with the open-and-click analytics a business needs; the private mailbox has no analytics by construction, because the server never sees the content. The user picks the circuit for the task instead of accepting one compromise for everything at once.

10Campaigns and automations

The marketing side of YourTrend is built around campaigns and automations. A campaign is a send to a segment: the platform can segment lists, A/B test subject lines, and send responsive templates that render correctly on desktop and in mobile clients alike. All of it at scale: the pipeline is designed for bulk sends that never get in the way of the transactional stream.

Automations remove the routine of "a message per event": a welcome series after sign-up, a drip flow after a purchase, a win-back message after a pause. Flows are assembled without code: event → message → interval → next message. Once configured, an automation runs on its own, and every email it produces goes through the same pipeline — with signing, suppression, and analytics — as everything else.

Significantly, the marketing circuit is not isolated from the transactional one: contacts and events are shared. If an address unsubscribes or hard-bounces, campaigns take that into account immediately; if a campaign leads a user to a purchase, the transactional receipt goes to the same contact through the same platform. For the business this means one base and one communications history instead of CSV exports between three services.

11The unified inbox

Sending platforms usually stop where incoming mail begins. YourTrend goes further: all mail arriving at connected domains is collected into a unified inbox. One interface instead of a dozen webmail tabs, one search across all correspondence — and one habit instead of login roulette between mailboxes.

The key detail: a reply goes out from the same address the message arrived on. A customer wrote to the support address of one of your domains — the reply comes from exactly that address, not from some "general" platform mailbox. To the recipient the thread looks seamless; the sender doesn't have to keep track of which domain they're answering from — the platform picks the address itself.

For studios, agencies, and owners of multiple projects this is a quiet superpower: each product has its own domain and its own addresses, but all the correspondence lives in one place. The webmail runs as a separate application and doesn't mix with the marketing dashboard; the same interface also serves the zero-access mailbox — with the difference that its content is decrypted only on the user's side.

12Developer experience and integrations

We designed YourTrend from the position of a developer who wants to "plug in email and forget about it". Hence the three steps to production: add a domain and publish the generated SPF, DKIM, and DMARC (copy-paste or one command via Cloudflare), connect — SMTP relay or HTTP API — and send. Starting is free; scale comes as you grow.

The integration is friendly to any stack: Laravel, Node.js, Python, WordPress, Zapier, and React are among the listed paths. Legacy applications already have an SMTP client; new ones have HTTP; in both cases the road to the first email is measured in minutes, not a sprint. The documentation, the API reference, and the status page are public — you can integrate without a single call.

Battle-tested — on ourselves. The contact form and the transactional mail of ostohlo.com run through the mail.yourtrend.online SMTP relay — authenticated, over STARTTLS. The platform carries the production mail of the studio's entire ecosystem: every message we send to clients goes through the same pipeline as any YourTrend user's mail. It's the best form of quality control there is: if the pipeline lost messages, we would be the first to notice — on our own inbound leads.

13Technology stack and infrastructure

YourTrend runs in a dedicated environment where web interfaces, the API, and background delivery processes coexist — with different load profiles but a shared data model.

• Backend — PHP 8.3: the API, the dashboard, the processing pipeline, and the event loop in one predictable environment.
• Mail layer — an authenticated SMTP relay with STARTTLS, DKIM signing, queues with retries, automatic suppression lists.
• Channels — an SMS gateway and web push on top of the same contact model; the unified inbox and webmail for incoming mail.
• Infrastructure — Cloudflare (DNS, TLS, perimeter protection) with an integration for one-command DNS record publishing; a dedicated IP for sending.

The load-bearing structure of the whole platform is the queues. They decouple intake from delivery: the API answers in a fraction of a second because it never waits for the receiving server; the transactional stream never queues behind a campaign; retries are a natural part of the model rather than a patch on top of it. The choice of PHP 8.3 is pragmatic: a mature, fast platform that comfortably hosts the API, the interfaces, and the background processes in one stack. Cloudflare closes off the perimeter and DNS — and also provides that "one command" integration that turns the scariest step for a newcomer, DNS configuration, into a formality.

14Design and UX

An infrastructure product sells confidence, so the YourTrend landing page explains the value in seconds: "Email your customers actually receive", three steps to launch, and honest numbers — a 99.9% uptime target and a median API accept under two seconds. The product is trilingual — EN, UK, and RU: the interfaces, the documentation, and the landing pages are written in each language, not run through a translator.

The product's tone is set by its mascot — Trendy, a friendly green envelope. For a B2B tool this is a deliberate move: email infrastructure is a dry subject, and a charming character lowers the barrier to entry without diluting the technical depth. Next to it on the homepage are floating channel cards and a ribbon of integrations: within seconds a visitor understands both what the platform does and what it plays well with.

The most important UX area is domain onboarding. This is usually the moment a newcomer drowns in TXT records; YourTrend generates the records and presents them ready to copy, and with Cloudflare publishes them in one command. We treated this screen the way we treat a payment checkout in fintech projects: it's the place where the user either reaches the value or walks away. Every detail — from the wording to the order of the steps — works towards making the first successfully delivered email happen as early as possible.

15How we worked

We ran the project in sequential stages, demonstrating a result at every step:

• Research. We mapped mailbox providers' requirements for authentication and bulk senders (DKIM, SPF, DMARC, RFC 8058), transactional and marketing sending scenarios, and the SMS and push channels.
• Architecture. We designed the pipeline, the event model, the contact graph, and the contracts: API formats, idempotency semantics, the suppression-list scheme.
• Core. We built intake (the SMTP relay and the API), the queues, DKIM signing, delivery from a dedicated IP, the event loop, and the dashboard.
• Channels and inbox. We added SMS, web push, the unified inbox with webmail, and the zero-access encrypted mailbox.
• Launch. We deployed the infrastructure behind Cloudflare, produced the landing pages, the documentation, and the status page in three languages — and moved our own ecosystem's mail onto the platform.

The order is not accidental: first we fixed the contracts — the event model, the API semantics, the suppression rules — and only then built the implementation around them. Dogfooding was in the plan from the very beginning: the platform's first "customer" was our own studio, and some product decisions — such as how to surface the difference between "accepted" and "delivered" — were born of our own operating experience rather than hypotheses.

16The result

What we got is not "yet another mailer" but a full-cycle communications platform: from DNS records to analytics, from a receipt to a campaign, from SMS to an encrypted mailbox.

• A domain connects in minutes: SPF, DKIM, and DMARC are generated automatically and published by copy-paste or with one command via Cloudflare.
• Transactional and marketing mail, SMS, and push live on one contact base with one set of analytics.
• Every message's events are visible in the dashboard and streamed to webhooks — the integrator builds their own logic on top without polling the API.
• The platform carries the production mail of the studio's ecosystem: ostohlo.com's contact form and transactional messages go through its SMTP relay.

The main shift is in the model. Email stopped being a scatter of per-project settings and became a shared layer: a new ecosystem product connects to a ready pipeline with a ready reputation, and the first email from a new site inherits all the engineering the platform has accumulated — from DKIM signing to suppression lists.

17Takeaways

YourTrend is a case study in deliverability being architecture, not luck. Everything that decides an email's fate — signing, DNS records, IP reputation, list hygiene, unsubscribes — has long been known and written down in standards; the only question is whether it happens by default or is left to the user "for later". We chose the former — and that is precisely what separates a platform from a configuration manual.

For us this was a project at the intersection of protocols, infrastructure, and product: SMTP and DNS, queues and event models, marketing scenarios and the cryptography of a zero-access mailbox. If you need a service with an API, a processing pipeline, and demanding reliability requirements — from a payment gateway to a communications platform — we know how to carry that through to launch.

And a methodological takeaway: the best test of an infrastructure product is to put your own business on it. YourTrend carries the mail of the studio and its ecosystem, and every incident that didn't happen is a direct consequence of decisions made at the architecture stage: idempotency, the event model, automatic suppression. That's exactly how we approach the work — first the right contracts and boundaries, and only then everything else.