Back to Blog
Landing in the inbox: how Zend Email works

Landing in the inbox: how Zend Email works

By Zend Team · July 22, 2026 · 7 min read

Anyone can put an email in a queue. The hard part is landing it in the inbox, and having it look like it truly came from you. That is the real job of Zend Email, and most of the work happens before and after the send itself. Here is how it works, end to end.

It starts with your domain

You send from a domain you own, and before your first message goes out you verify it. Zend generates two kinds of DNS records for you to publish:

  • DKIM lets Zend cryptographically sign every message, so a receiving server can confirm the mail was not altered on its way over.
  • SPF authorizes Zend's sending infrastructure to send on behalf of your domain.
abc123._domainkey.yourdomain.com   CNAME   abc123.dkim.tryzend.com
yourdomain.com                     TXT     "v=spf1 include:amazonses.com ~all"

You add these at your DNS provider and click Verify. Until the records resolve, any send from that domain is rejected, so you never leak half-authenticated mail. Once verified, you can send from any address on the domain. A dedicated subdomain like mail.yourdomain.com is a good idea, since it keeps your sending reputation separate from the rest of your mail.

This step is the difference between an inbox and a spam folder. Authenticated mail from a domain with a clean reputation is mail that mailbox providers trust.

Sending, and what happens next

A send is one call:

import { Zend } from '@usezend/node';

const zend = new Zend(process.env.ZEND_API_KEY);

const { data } = await zend.emails.send({
  from: 'receipts@yourdomain.com',
  to: 'customer@example.com',
  subject: 'Your receipt',
  html: '<h1>Thanks for your order</h1>',
  text: 'Thanks for your order',
});

You get back a message id and a status of pending. Zend does not send inline and make you wait. The message is queued and delivered in the background, and its status moves through pending, then sent once the provider accepts it, then delivered when it reaches the recipient. If the receiving server rejects it, it lands on bounced, and if the recipient marks it as spam, complained.

You can check where a message is at any time:

curl https://api.tryzend.com/email/messages/6884da240f0e633b7b979bff \
  -H "x-api-key: YOUR_API_KEY"

Attachments travel with the message

Business email is often really about a file, so you can attach up to ten of them, seven megabytes in total. Each file's content is a Buffer or a base64 string:

import { readFileSync } from 'node:fs';

await zend.emails.send({
  from: 'billing@yourdomain.com',
  to: 'customer@example.com',
  subject: 'Invoice #1024',
  html: '<p>Your invoice is attached.</p>',
  attachments: [
    {
      filename: 'invoice-1024.pdf',
      content: readFileSync('./invoice-1024.pdf'),
      contentType: 'application/pdf',
    },
  ],
});

A couple of details worth knowing. The seven megabyte limit is measured on the decoded bytes, not the base64 text, and an oversized request is rejected before it is ever billed. And attachments are handed straight to the provider as part of the message, never stored on our side, which is what you want for a customer's invoice or statement. Set contentType so mail clients render the file correctly, since without it a file falls back to a generic type.

Knowing who opened and clicked

Delivery tells you a message arrived. Tracking tells you what the recipient did with it. Both open and click tracking are controlled per domain, and both are off by default. You turn them on only where engagement matters, like marketing or onboarding, and leave password resets and one-time codes untracked.

When tracking is on, Zend adds an invisible pixel for opens and rewrites links for clicks, decided at the moment of sending. When the recipient opens the message or follows a link, the event travels over the same pipeline that already carries bounces and complaints, and Zend records it. Every open increments a counter, and the first open of a message fires a webhook so your app can react right away:

{
  "event": "message.read",
  "channel": "email",
  "message_id": "6a60c00a4ede20ab509eac0c",
  "to": "customer@example.com",
  "read_at": "2026-07-22T13:05:36.133Z"
}

The first click fires message.clicked in the same way. Under the hood, only the first event of each kind wins a race-safe claim, so no matter how many times a message is opened, you are notified exactly once. All of it rolls up into your metrics: unique and total opens, unique and total clicks, open rate, and click-through rate.

Deliverability that looks after itself

Sending reputation is fragile, and the fastest way to ruin it is to keep mailing addresses that bounce or complain. Zend handles that for you. When an address hard-bounces, or a recipient marks a message as spam, it is added to your suppression list automatically, and the next send to it is rejected before it costs you anything:

{ "message": "Recipient is suppressed due to a previous bounce or complaint", "statusCode": 400 }

You never have to track bad addresses yourself, and one of them cannot quietly drag down the rest of your mail. Aggregate delivery, bounce, and complaint rates are a single call away, and they power the deliverability dashboard:

curl "https://api.tryzend.com/email/metrics?from=2026-07-01&to=2026-07-31" \
  -H "x-api-key: YOUR_API_KEY"

Get started

Add a domain, publish the records, and send your first message. It will look like you, and it will land.