The questions we are actually asked — by developers integrating the API, and by teams who have to account for a supplier in writing. The answers describe the platform as it behaves, including where that does not flatter us.
Both, and they are the same path. The REST endpoint takes JSON; the SMTP relay authenticates with an API key and then submits through the same code, so everything decided by the key — the sending identity, the transport policy, the unsubscribe behaviour — applies identically whichever you use. There is no SMTP-only configuration to keep in step.
| Host | mail.zedmail.com |
|---|---|
| Port | 465 (implicit TLS) or 2587 (STARTTLS) |
| Username | your API key |
| Password | the same API key |
We do not use port 25. If your host blocks outbound 25, that is not a problem to solve before you can send — one customer spent a month waiting for an unblock they never needed. Use 465 or 2587.
Two CNAMEs for DKIM and one SPF include, added once per sending domain. The CNAMEs are the same targets for every customer, so a key rotation on our side never asks you to touch DNS again.
We will tell you the exact records when you add the domain, and check them with you afterwards rather than leaving you to interpret a propagation delay.
Yes, and for application mail it is usually the better choice. A subdomain is added exactly like a domain, and DKIM signs with that subdomain, so DMARC passes on DKIM alignment and your organisational domain can keep a strict policy of its own.
Yes, with no fixed ceiling — one customer runs nine domains on a single account. Agencies and multi-tenant products usually want a key per client or per environment, which also keeps each one’s configuration independent: transport policy and unsubscribe behaviour are properties of the key, not of the account.
No. Binding a key to a single From address is an option, not a rule, and it is on by default because most people want a credential that can only ever send as one identity. Leave that field empty and the key may send as any address on a domain you have verified; anything else is refused rather than silently rewritten.
The first 200 messages each day are included at no charge and need no payment method. The allowance does not accumulate — a quiet day does not lend its remainder to a busy one — and it continues to apply once a card is on file, with only the volume above it billed. Current rates are on the homepage.
Nothing, provided you pass an idempotency_key of your own on the send — an order
number, a job id, anything unique to that one message. An identical retry within 24 hours returns
the first response again, with 200 and an Idempotent-Replay: true header
rather than the usual 202, and no second message goes out.
The edges are deliberate. A retry while the first attempt is still running answers
409 — the only reply that cannot double-send. The same key with a different
message is refused with 422, because quietly handing back the first message’s id
would mean the second never sent and nobody was told. And a send we reject releases its key, so a
bad address or an unverified domain is something you fix and retry with the same key rather than a
dead end.
Without a key the behaviour is unchanged, so nothing about existing integrations breaks. The
header Idempotency-Key works too, if that suits your HTTP client better.
By default, yes — CASL requires an unsubscribe mechanism in commercial electronic messages, and the footer is the simplest way to be certain one is present. It is added when the message is built, in the language set on the key.
Yes, per key or for the whole account. You may also find it already stands aside: before adding anything we scan both the HTML and plain-text parts of your message for an existing opt-out, in several languages, and suppress our own footer when you have one. The footer was never meant to land underneath yours.
No — those stay on every message regardless, because Gmail and Yahoo require them of bulk senders and removing them would cost you placement rather than protect your flow.
The consequence is worth planning for. A recipient who uses the mailbox
provider’s own unsubscribe button is recorded as unsubscribed with us, and your system
will not know unless you consume the unsubscribed webhook. Consume it and the two stay
in step, with your own mechanism remaining the one your users see.
A recipient who unsubscribes, a mailbox that hard-bounces, and an address that reports a message as spam. Suppression is enforced at send time, so a later attempt to that address is refused rather than delivered and regretted.
Reputation refusals and temporary failures are deliberately not treated as dead mailboxes: a receiver throttling us, or an authentication complaint, says nothing about whether the address exists.
An unsubscribe can be scoped to one API key rather than the whole account, which matters if you send genuinely separate kinds of mail — someone declining your newsletter should not thereby decline their own password resets. Spam complaints and hard bounces are account-wide and are not narrowable: a complaint is a statement about you and that recipient, and a dead mailbox is dead for every key you own.
Not through us. Only hard bounces raise the bounced webhook; mailbox-full,
greylisting and reputation deferrals update the message record without firing an event. List
managers tend to treat any bounce event as terminal, and that behaviour was quietly removing
hundreds of valid contacts from customer lists.
delivered, bounced, blocked, complained,
unsubscribed, opened and clicked. Every payload carries
event, a message identifier and a timestamp; events with detail add a
data object, and events without one omit it, so treat it as optional.
unsubscribed is the exception worth reading twice: it has no message identifier,
because an opt-out is an action against an address rather than a bounce of one particular message,
and the link stays valid long after that message has left your retention window. Read the address
from data.
Yes. An endpoint can be bound to one key, so a staging environment’s events reach a staging receiver and production reaches production, with no demultiplexing in between. Leave an endpoint unbound and it receives everything on the account, which is how endpoints behaved before the option existed.
A URL supplied with each individual message is not offered, and the reason is not oversight: it would mean posting to whatever endpoint a request named, with retry state for addresses that may never have existed.
Every event we can attribute to a key carries the key’s own identifier. It is not the secret and not derived from it, it survives a key rotation, and it is safe to log and store — which makes it a sound routing value if you would rather keep one shared endpoint than several bound ones.
Yes, two ways, and the choice turns on one question: does something at the receiving end need to read your identifier?
If not, use tags (tags): up to ten per message, fifty characters
each, stored with the message and returned on the delivery and failure events. They never leave
our side, so the recipient never sees them. Two limits to design around: tags are trimmed to
those bounds rather than rejected, so a long composite identifier can arrive shortened; and
because unsubscribed carries no message, it carries no tags either — use the key
identifier if you need to attribute an opt-out.
If so, use custom headers (headers): they go on the message,
where a system at the receiving end can read them, and come back in every webhook event
about it. One field does both jobs; elsewhere you generally need a header for the message and a
separate metadata field to get a value returned.
"headers": { "X-Survey-ID": "survey-8842" }Up to ten headers, 64 bytes per name, 200 bytes per value, 2 KB in total. Unlike tags, a
bad header fails the send with a 422 naming it — nothing is trimmed or escaped, so you
will never have a header you think you set and didn't. Headers we set ourselves
(From, Subject, Message-ID, Content-*,
List-* and the rest) are refused rather than overridden.
Two judgement calls. A header travels with the message, so it is visible to the recipient, their mail provider and anyone the email is forwarded to — keep the value opaque. And a custom header is not covered by the DKIM signature, which is fine for a correlation id but should not be treated as proof of origin.
Each endpoint has its own secret, shown once when you create it, and deliveries are signed with it so your receiver can reject anything it cannot verify. Failed deliveries are retried on a backoff; an endpoint you disable stops receiving rather than accumulating a backlog.
In Canada. Sending infrastructure and the database are in the Beauharnois, Québec region, and encrypted off-site backups are held in Québec as well. The service is administered from Ottawa, Ontario.
If you or your client falls under Québec’s Law 25, note that administration from outside Québec is a factor in your own privacy impact assessment. We will give you what you need for it rather than leave you to infer it.
Ozonagram Ltd, a Canadian federal corporation. There is no parent company, no outside investor with control, and no office or staff outside Canada.
Our reading is no, and the reasoning is about corporate structure rather than reassurance. The CLOUD Act reaches providers subject to US jurisdiction — US companies and the subsidiaries of US groups. It runs down from a US parent; it does not run up from a foreign one.
Our hosting is provided by a French group through its Canadian company, and that group’s US business is a separately governed subsidiary. The group states in its annual regulated filing that only the US subsidiary falls under those rules, because non-US activity is segregated from it, and its published analysis says the same of the Canadian company specifically: out of scope, with mutual legal assistance the route an American authority would have to take.
Three, and none of them handles your email: authoritative DNS for our own domains is provided by two European operators, and billing is handled by a UK company. They receive no message content, no recipient addresses and no account data.
Specifically: there is no third-party sending service, relay or spam-filtering service in the path. The mail servers are our own software on our own machines, and analytics is self-hosted.
No — including contractors.
There is one published at zedmail.com/dpa.php. It forms part of the terms and is accepted with them without a signature, and we will execute a signed copy if your process requires one on file.
You choose, per stream, down to a floor of seven days. When the window passes, the whole record goes together: recipient, subject, body and delivery status.
Three exceptions, because a complete answer is more useful than a short one:
Every message is encrypted in transit whenever the receiving server offers it. You can also require it per key, in which case a message to a server that cannot offer verified encryption is not sent rather than sent in the clear, and we tell you which recipients were affected.
For the major consumer providers it is enforced regardless, because they publish policies saying their servers should never accept unencrypted mail, and we hold them to that.
We do not disclose data to any foreign government. Where a Canadian court or public authority compels disclosure, we disclose only what we are compelled to disclose, notify you first unless the law prohibits it, and refer the authority to you where that is possible.
Within 72 hours of becoming aware, committed in the terms: what we know and what we are doing about it. Deciding whether regulators or individuals must be notified is yours, and our job is to give you what you need to decide it.
99.5% monthly on the submission endpoints, measured across five-minute intervals, with service credits if it is missed and stated exclusions. It is section 6 of the terms rather than something offered on request, and you can hold it against externally operated monitoring at status.zedmail.com.
Affected accounts are emailed and the status page is updated. Separately and automatically: if sending is ever held on your account — for a bounce or complaint rate above threshold, say — you are emailed at once with the reason, rather than discovering it from failed API calls.
At least 90 days in writing, to your billing contact and in the dashboard. It is in section 7 of the terms, and it commits to more than the notice period: the service runs normally throughout, including the uptime commitment; nothing is billed for any period after it stops; unused prepaid credit is refunded; and you can export your sending data, delivery logs and suppression lists throughout.
That last item is worth checking against any vendor you evaluate. Your compliance obligations outlive the contract, and you cannot honour opt-outs you were not able to take with you.
There are limits, but they are per-account settings rather than plan tiers: a daily cap and a per-minute rate, both raised on request. A message is refused if you cross the cap, so the right move at onboarding is to set it comfortably above your expected peak rather than at it — tell us the busiest day you can imagine and we will set it above that.
Write to hello@zedmail.com. If the answer belongs on this page it will be added to it — most of the questions above arrived exactly that way.