How to send low-volume app notifications from your own domain is one event, one message, one approved From. Paid MailerZ SMTP sends notify@yourdomain.com. Free cannot. Caps on Solo start at 2,500 outgoing per month and 20 per hour. A user dump is a campaign. This is not a campaign platform.
Quick answer for app notification smtp custom domain
Map notify@ or receipts@. Prove inbound. Leave Free. Put the dashboard SMTP pair in environment variables. Send on password reset, invoice, or alert — not on “all users.” IETF RFC 5321 — Simple Mail Transfer Protocol is the hop. Alignment follows IETF RFC 7208 — Sender Policy Framework (SPF), IETF RFC 6376 — DomainKeys Identified Mail (DKIM), and IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC). List law still exists if you mail people who did not trigger the event — see US Federal Trade Commission — CAN-SPAM compliance guide.
The sibling “low-volume SMTP versus bulk ESP” page is the category choice. This page is the app wiring. Gmail send-as is a human composer. Do not paste Gmail wizard values into a Rails initializer.
MailerZ: inbound MX plus paid send-as, Secuno LLC. Envelope SRS only. Header From never rewritten. Not IMAP. Not an open relay. Unauthorized send is 550 / 550 5.7.1.
Free: send-as Off, SMTP Off, API Off. Solo $40/year: 2,500 outgoing, 20/hour. Starter $8/$80: 5,000 and 40. Business $19/$190: 12,000 and 60. Agency $39/$390: 20,000 and 60. Unlimited $99/$990: 100,000 and 300. Confirm MailerZ pricing. Caps are not an inbox SLA.
Product pages: send and reply, features, docs.
The user problem and the decision criteria
A site uses the host’s mail() and lands in spam, or uses a personal Gmail password in env and gets the account locked, or uses a bulk ESP for password resets and trains the ESP that transactional mail is a list. The fix is authenticated SMTP from a named domain identity with a published ceiling.
| Signal | Notification | Campaign |
|---|---|---|
| Trigger | User or system event. | Your marketing calendar. |
| Recipient | The person in the event. | A stored list. |
| Retry | Idempotent, same Message-ID story. | A second blast. |
| Unsubscribe | Usually not a newsletter footer. | Required for commercial lists. |
| Volume shape | Spiky per event, small daily. | Smooth and large. |
If the shape is a campaign, stop. Buy a bulk ESP. Keep MailerZ for the domain identity humans use. Mixing the rows is how a 550 becomes a “billing bug.”
Technical mail flow
App → SMTP AUTH → MailerZ → recipient MX. Header From is the mapped alias. Bounces return on the envelope path MailerZ used. If you also forward that alias to Gmail, humans can read replies.
Inbound still needs exclusive MX if you want replies and bounces on the same domain. Leftover suite MX steals a fraction and looks like a flaky notifier.
Step-by-step setup and decision path
Name the From
notify@,receipts@, oralerts@. Create the alias. Catch-all is not a From.Prove inbound
Foreign probe to that alias. Leftover MX gone.
Leave Free
SMTP is Off on Free. Solo is the smallest On.
Store the pair in env
Host, port, TLS, username, password. One service account. Rotate without a commit if you can.
Send one event
Unique subject. Third-party inbox. History 250. Header From is the alias.
Make retries idempotent
If the worker runs twice, the user gets one message. A queue without a key is a duplicate generator.
Watch caps
Hourly first. Solo’s 20/hour will stop a reconnect storm. That is the product working.
Failure modes and proof
| Symptom | Likely cause | What to check |
|---|---|---|
| 535 | Wrong pair or leftover Gmail password. | Dashboard values only. |
| 550 5.7.1 | Free, unknown From, open-relay guard. | Paid plan. Mapped identity. |
| Duplicates | Retry without idempotency. | Event key. Not a second SMTP host. |
| Works in staging only | Prod still on mail() or a different From. | Env in the running process. |
| Cap 550 after deploy | Loop or forgotten cron. | Counters. Kill the loop. |
| Secret in GitHub | Committed .env. | Rotate now. History is not enough. |
Not SOC 2. Do not mail the password to support. Send a 550, a timestamp, a Message-ID. Security. Hops in Mailbox.
MailerZ workflow and product boundary
MailerZ will send transactional-looking mail from approved identities on paid plans. It will not warm a list, manage unsubscribe, or raise caps because a launch email “needs to go out today.”
- Authenticated SMTP and API on paid plans.
- Delivery history per hop.
- Published hourly and monthly ceilings.
- No send-as on Free.
- No IMAP store for the app to poll.
Cost, alternatives, and trade-offs
A bulk ESP is cheaper per thousand when you actually send thousands of marketing messages. It is the wrong default for ten password resets a day. A host-level mail() is free and unsigned. Workspace device SMTP is a suite feature — quote Microsoft live via Microsoft Learn — Send email from a device or app using Microsoft 365 if that is your stack.
| Approach | Fits | Breaks |
|---|---|---|
| MailerZ paid SMTP | Resets, receipts, alerts under plan caps. | List launches. |
| Bulk ESP | Newsletters, drip, unsubscribe. | People who expected a receipt From the app domain only — still possible, but a second vendor. |
| mail() on the VPS | Almost never. | Authentication and reputation. |
Count Gmail human replies on the same identity against the same cap if they share SMTP. Split identities if the app would starve support.
Operational rules that keep the hop boring
One From per product surface. Password resets and marketing never share a local-part if you can help it. Recipients learn to trust receipts@. They learn to filter hello@ after a campaign mistake.
Render failures should not send a blank body. If the template throws, do not AUTH and submit an empty message. That is how you spend cap on garbage.
Nightly digests are still notifications if each user opted into that digest as a product feature. They become a campaign when you add a pitch. Keep the pitch off this hop.
Staging must use a sink or a dedicated alias you own. Pointing staging at production SMTP is how customers get two receipts. Use a separate MailerZ identity or a reject-all sink.
VPS port 25 is often blocked. Use the dashboard port. Testing SMTP from a VPS is a sibling article. Do not open 25 to “make it work” on a cloud VM.
Logs may store recipient and Message-ID. They must not store the SMTP password. If a log line printed AUTH PLAIN, rotate.
Timeouts need a bounded retry. Infinite retry plus a 421 is a cap-eater. Back off. Surface the failure in the app UI. The user can tap resend once.
When the notifier is closed, the next action is one production-like event, not a CSV. Start free to prove the domain. Upgrade when the first real receipt must leave. Sign in if the zone already lives here.
Agencies isolate client SMTP. A shared env across ten WordPress sites is one leak away from ten brands sending as each other. Agency plan capacity exists so you can hold more domains. It does not replace per-client secrets.
Field notes for app notification smtp custom domain
Teams that bookmark How to Send Low-Volume App Notifications From Your Own Domain usually arrive after a locked Gmail account, a host mail() that never authenticated, or a bulk ESP that treated password resets like a list. The useful brief is still boring. Name the From. Prove inbound. Leave Free. Put the dashboard pair in env. Send one event. Read Header From. Only then add a queue.
MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is Mail Box portal webmail, not IMAP, not POP, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.
If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening app notification smtp custom domain. Replies and bounces never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.
Catch-all forward is not a From factory. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com. Map notify@ exactly.
Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.
Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear app notification smtp custom domain works while customers never see the receipt. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.
Agencies should keep app notification smtp custom domain per client zone. Separate SMTP credentials. Do not pour every client into one env file because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, rotate the env, and stop forwarding leftovers into the agency inbox.
A contact form, a Gmail identity, and this notifier can share one monthly cap. If the form already burns Solo’s 2,500, receipts 550 and look like a deploy regression. Split identities or raise the plan. Do not open a refund ticket for a published ceiling. Campaign mail belongs on a campaign platform. MailerZ is not that platform. US Federal Trade Commission — CAN-SPAM compliance guide still applies if you start pitching.
WordPress “sent” toasts and framework “mail dispatched” logs are not SMTP 250. The only outbound proof that belongs on this page is a received copy plus a history row. If you cannot produce both, you do not have app notification smtp custom domain yet. You have a feeling. A for-loop is bulk even when the subject line says “notification.”
Idempotency is the difference between a retry and harassment. If the worker crashes after the 250 and before it records success, the next run must not send again. Store the event key. If you cannot do that, you are not ready for a queue. Stay on a single synchronous send until the key exists.
Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.
A second worked pass: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. If the sticky note says leftover MX, you do not have a notifier mystery. You have a split. Delete the leftover. Wait for TTL. Probe inbound again. Only then send the event.
A third worked pass: print the public list of From identities the app will use. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Ten named aliases on Free are enough to stop printing a personal Gmail on a homepage. They are not enough to send receipts. Grow the send list when a real event exists, not when a harvest guessed admin@.
When How to Send Low-Volume App Notifications From Your Own Domain is closed, the next physical action is one event and a lookup, not a CSV. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a secret leak. That is how app notification smtp custom domain stays a runbook instead of an incident.
Worked examples
A password-reset worker retries five times without a key. The user gets five emails and reports abuse. The hop was fine. The app was not. Store the event id before AUTH, or after 250 before you ack the queue. If you cannot, stay synchronous.
Staging and production share one SMTP password. A designer triggers a test order. A real customer gets a second receipt. Use a sink identity on staging, or a reject-all alias you own. Never point staging at the production From.
A VPS blocks port 25. The app uses 25 because a tutorial said so. AUTH never starts. Copy the dashboard port. Testing from a VPS is a sibling article. Opening 25 on a cloud VM is not the fix.
The site already sends 2,400 Solo messages through a contact form. Receipts start 550 after a launch. Split hello@ and receipts@ only helps if they are different plan identities with separate counters — on MailerZ they share the domain’s outgoing cap. Raise the plan or move the form. Do not disable AUTH.
A developer committed .env. Rotate the SMTP password the same hour. Update the running process. History of the leak is not containment. Do not mail the new secret to a ticket. Put it in the secret store the app already uses.
Template render failures should abort before AUTH. An empty body still counts as outgoing if you submitted it. That spends Solo’s 2,500 on garbage and trains recipients to mark you. Fail the job, surface the error, let the user tap resend once.
Nightly digests are notifications only when the user opted into that digest as a product feature. Add a pitch and you are in US Federal Trade Commission — CAN-SPAM compliance guide territory. Keep the pitch off this hop. Keep unsubscribe on the campaign platform. Do not hide a launch list behind the word “alert.”
Timeouts need bounded retry with backoff. Infinite retry plus a 421 eats the hourly cap and then the monthly cap. Surface the failure in the app. The hop will not become a bulk ESP because you are impatient.
Logs may store recipient and Message-ID. They must not store the SMTP password. If a log line printed AUTH PLAIN, rotate. Corporate TLS interception on 587 looks like a MailerZ outage and is a middlebox. Test from a network that does not intercept.
One From per product surface. Password resets and marketing never share a local-part if you can help it. Recipients learn to trust receipts@. They learn to filter hello@ after a campaign mistake. Keep the notifier boring. Boring is the point.
Count Gmail human replies on the same identity against the same cap if they share SMTP. Split identities only if the product allows separate counters — on MailerZ, outgoing is a plan ceiling for the domain. Raise the plan or move the form. Confirm /pricing before a launch week.
Start free to prove the name. Upgrade when the first real receipt must leave. Sign in if the zone already lives here. One event. One 250. Then a queue. If you cannot name the From, you are not ready for env. If you cannot name the event key, you are not ready for retries. If the volume looks like a list, you are not ready for this hop. Buy a campaign platform for that row and keep MailerZ for the domain identity. Mixing the rows is how a published 550 becomes a launch-week incident. Do not mix them.
FAQ
What is the safest way to send app notification SMTP from a custom domain?
Create a named identity such as notify@ or receipts@, prove inbound on that alias, upgrade off Free, put dashboard host port TLS username and password in env, and send one message per event with an idempotency key. Count hourly and monthly caps on /pricing. Do not warm a user dump. Do not disable AUTH.
Does this require a new mailbox?
No. App notification SMTP is outbound. MailerZ is not IMAP. Bounce and reply copies can land in Gmail or Outlook through the same alias. Buy a mailbox only if someone must host an archive.
Will it work with Gmail or Outlook?
Yes as the place humans read replies and bounces when the From is a mapped alias. The app itself uses SMTP, not a Gmail wizard. Free cannot send-as from the app either.
What DNS records are involved?
Verification TXT, one MX set, leftover host MX removed, and SPF, DKIM, and DMARC from the dashboard for the sending domain. Port numbers are not DNS. Copy them from the app.
What should I test before production?
One real event to a mailbox you do not own. Read Header From and a history 250. Trigger a second identical event and confirm you did not double-send. A for-loop is bulk. Self-send from Gmail hides the hop.
Key takeaways
- App notification SMTP is one event, one message, one mapped From.
- Free has no send-as. Solo $40/year is the smallest On.
- Caps are published. Loops hit them. That is correct.
- Idempotent retries. No user dumps. No AUTH off.
- Env holds secrets. Git and tickets do not.
- Header From is the alias. Prove with a foreign inbox and history.
- Campaigns belong on a bulk ESP.
- Not IMAP, not SOC 2, not an inbox SLA.
Conclusion and next action
If you came here to send low-volume app notifications from your own domain, map a From, prove inbound, leave Free, put the dashboard pair in env, and send one real event. Read Header From. Add a queue only after that 250 exists.
MailerZ fits receipts, resets, and alerts under published caps. It does not fit a launch list. Confirm pricing, then wire one identity.
Ready to send one event
Start free with one domain, then enable paid SMTP.
Prove the name on Free. Send notifications on a paid plan. Sign in if the domain is already there.
Review quarterly, or sooner if MailerZ outgoing caps or SMTP values change. Author: MailerZ editorial, Secuno LLC.