Knowledge base
Send email from your own domain, on your own account
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.
Which provider should I use?
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.
Do the DNS first. It is most of the work.
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.
Use a subdomain for sending
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@.
How the setup works
- Choose your provider and paste in its credential.
- Press Send test message. We send a real email through your provider, to an inbox you
- Read the code out of that inbox and enter it.
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.
Why we insist the test message actually arrives
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.
What happens if my provider stops working
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.
What if I do nothing?
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.
Removing it
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.
Still stuck?
Support is included on every plan and answers in your own language.
Contact support → All articles →