Knowledge base
Send your clients' notifications from your own domain, on your own mail account: which provider to choose, the SPF, DKIM and return-path records they all need, why we insist a test message actually arrives, and what happens when a provider breaks.
Every notification your clients receive — invoices, password resets, ticket replies, project updates — leaves through a mail service. By default that service is ours, the From line says Zinn Digital®, and we pay for it.
If you are on an agency or reseller plan you can attach your own mail service instead. Your clients then see your domain in the From line, replies come back to you, and the messages are sent on your account with your provider.
Set it up at Email sending in your dashboard.
Any of these work. Pick the one you already have an account with.
| Provider | Best if | Guide |
|---|---|---|
| Mailgun | You want an API and generous sending volumes | Set up Mailgun |
| SendGrid | You already use it for marketing mail | Set up SendGrid |
| Postmark | Transactional mail only, best deliverability | Set up Postmark |
| Amazon SES | You are already on AWS and want the lowest price | Set up Amazon SES |
| Resend | You want the simplest setup | Set up Resend |
| Your own SMTP server | You run your own mail infrastructure | Set up SMTP |
If you have no preference and no existing account, Postmark is the one we would choose for transactional mail: it refuses to carry marketing, which is exactly why its delivery rates are what they are.
Whichever provider you choose, the same three DNS records decide whether your mail arrives or lands in spam. Your provider generates the exact values; you add them to your domain.
SPF — a TXT record on your domain listing who is allowed to send as you. If you already have one, you edit it; you do not add a second. A domain with two SPF records fails SPF entirely, which is worse than having none.
DKIM — a TXT or CNAME record holding a public key, so receiving servers can check that a message really came from your provider and was not altered. This is the record that does the most work, and it is the one that has to match for DMARC to pass.
Return-path (bounce) domain — usually a CNAME. It sets the invisible envelope address your provider uses to collect bounces. Without it, bounces go somewhere you cannot see and your domain's reputation degrades without you knowing.
DMARC — a TXT record at _dmarc.yourdomain.com telling receiving servers what to do when SPF and DKIM disagree with your From line. Start at p=none while you check that everything passes, then move to p=quarantine and p=reject.
⚠️ DNS changes are not instant. Give them up to an hour before you decide something is wrong.
Send from mail.yourdomain.com or notifications.yourdomain.com, not from yourdomain.com itself.
The reason is reputation. Your main domain is what your business email uses. If a bulk send ever goes wrong, a separate sending subdomain contains the damage — your staff can still email clients while you sort it out. It also lets you set DNS records for sending without touching the records your own mailboxes depend on.
You still put a domain, not an address, into the Send from this domain field. The part before the @ is chosen per message: receipts leave as billing@, password resets as no-reply@, ticket replies as support@.
nominate, with a code in it.
Only then does your mail start leaving as you.
⭐ Use an inbox on a different domain for the test — a Gmail or Outlook address is ideal. A message that never leaves your own server proves much less than one that crossed the internet and got past somebody else's spam filter.
Because a provider that accepts a message and then silently drops it looks identical to one that works. A brand-new Amazon SES account is in a sandbox and will accept your message and deliver it nowhere. A Mailgun domain whose DNS has not propagated does the same. So does an SMTP relay that answers 250 and discards.
If we switched your sending over the moment your credential was accepted, the first thing you would learn is that your clients stopped receiving anything — and you would learn it from a client, days later. The code is proof that a message left your provider and landed.
Your notifications are recorded as failed, retried, and your Email sending screen turns red with your provider's own error message on it.
⛔ We do not send them from our domain instead. That is deliberate. A silent fallback would mean a broken mail account keeps working well enough that nobody fixes it — while we quietly pay for it. So a fault is visible, and it is yours to fix, which is the only way it gets fixed.
Until it is fixed, your clients are not receiving those notifications. Everything is still in their dashboard inbox, and nothing is lost — but treat a red banner here as urgent.
Nothing breaks. Your notifications keep going out from our domain, as Zinn Digital®, and we keep paying for them. Your clients simply see our name instead of yours.
Press Disconnect. Your stored credential is deleted and your notifications go back to our domain from the next message. You can reconnect at any time.
What we have been writing about hosting, SEO and running sites at scale.
How hosting shapes indexing and link equity in 2026: keeping pages indexed, vetting aged domains before you build on them, link building without a footprint, and an honest line on what infrastructure can and cannot do for SEO.
Read the post →A practical checklist for fast, secure WordPress: server-level caching, a per-site object cache, the handful of plugins worth running, keeping the stack current, and the WooCommerce pages you must never cache.
Read the post →What actually separates good managed hosting from a cheap box with a control panel — migrations, backups, isolation, real caching and honest scaling — and how to judge it before you commit.
Read the post →Support is included on every plan, the desk is open 24 hours a day, and you can write to us in any of our 58 languages — we answer you in yours.
Contact support → All articles →