App notification SMTP on a custom domain is one authorized message per real event: a password reset, a receipt, a seat invite. It is not a weekly digest blast and not a warm-up dump. MailerZ paid send-as uses dashboard credentials and a mapped From. Count hourly and monthly caps on pricing. Free has no send-as. Exclusive inbound MX only if users will reply to notify@. Port 25 on the app host is the wrong shape.
Quick answer for app notification smtp custom domain
Upgrade off Free. Map notify@ or noreply@ if you will never read replies—prefer notify@ you staff. Copy SMTP from the dashboard into env. Idempotent keys on retries. Product path: send and reply, docs, features. IETF RFC 5321 — Simple Mail Transfer Protocol. IETF RFC 7208 — Sender Policy Framework (SPF). IETF RFC 6376 — DomainKeys Identified Mail (DKIM). Quote ImprovMX SMTP if you compare hops—do not copy their ports onto us.
Confirm MailerZ pricing. Solo $40 per year. Starter $8 or $80. Business $19 or $190. Agency $39 or $390. Caps are published there. 550 5.7.1 is authorization. No inbox SLA. Not SOC 2. Not an open relay. CAN-SPAM: US Federal Trade Commission — CAN-SPAM compliance guide if you slide into lists.
Helpful pages name the event, not a blast: people-first content.
The user problem and the decision criteria
Founders want password resets from hello@example.com without Workspace. The useful path is paid SMTP and a cap you can live with. The useless path is a cron that mails every user “to test reputation.”
| Question | If yes | If no |
|---|---|---|
| Is there a user action or state change? | One message may fit. | You are designing a campaign. |
| Will volume fit published caps? | Quote the plan. | Use a transactional specialist. Quote live. |
| Must users reply? | Exclusive MX plus mapped alias. | Still map From. Noreply is a choice you staff. |
| Retry on 550? | Stop. Fix auth. | Retry 4xx with backoff and a key. |
| Mailing the whole table? | Not this product job. | Good. |
Technical mail flow
The app authenticates, offers MAIL FROM as notify@, and sends to the user’s address. MailerZ accepts or 550s. The user’s provider decides inbox placement. We do not sell placement. Header From should stay notify@. Do not spoof the user.
If leftover Google MX exists, user replies to notify@ may vanish into a cancelled seat. Send can still work. Mix those tickets and you will toggle the wrong control.
Outlook/M365 recipients follow their MX; see Microsoft Learn — Send email from a device or app using Microsoft 365 only if you send through Microsoft instead. Do not copy their settings into MailerZ env.
Step-by-step setup and decision path
Map notify@ and exclusive MX
Staff the destination if replies matter. HOLD unknowns. Probe inbound.
Pay for send-as and copy SMTP
Dashboard host, port, user, password into env. Gitignore .env.
Count events against caps
Password resets plus receipts plus invites. Peak hour matters as much as the month.
Idempotency on the event id
A double click must not send two resets if the first 250’d.
Prove one event
Third mailbox. Unique subject. History 250. Then a reply if you staff notify@.
Close port 25 on the app host
You are a client. Not an MTA.
Failure modes and proof
| What you see | Likely cause | Proof |
|---|---|---|
| 550 5.7.1 | Free or bad From | Plan and mapped alias |
| Two resets from one click | No idempotency | Event key in the app |
| Hits monthly cap mid-day | You undercounted | Upgrade or a specialist. Quote live |
| Replies missing | Leftover MX | Two resolvers |
| Cron retries 550 | Permanent fail loop | Stop the worker |
| Users call it spam | Placement, not MX | We do not sell inboxing |
Proof is a counted cap, one 250, an idempotency key, and exclusive MX if replies exist. Agencies: per-app credentials. Do not share SMTP across client apps.
MailerZ workflow and product boundary
Inbound MX plus authenticated SMTP. Envelope SRS on forward. Header From not rewritten inbound. Outbound From authorized only. Not IMAP. Not a campaign sender. Not an open relay. 550 on unhosted send.
Free: 1 domain, 3 aliases, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/yr. Starter $8/$80. Business $19/$190. Agency $39/$390. Confirm pricing. No inbox SLA. No SOC 2.
Features do not grow list tooling. Paid plans authorize send-as and raise caps.
Cost, alternatives, and trade-offs
| Choice | What you get | What you give up |
|---|---|---|
| MailerZ paid SMTP | Domain From at published caps | High-volume transactional APIs |
| Dedicated transactional vendor | Their scale. Quote live | One hop for aliases plus send |
| Workspace SMTP | A suite. Quote Google live | Seats you may not need |
| User-dump warm-up | A blocklist story | The domain’s future |
Time is a line item. Counting events costs less than a month of 550 loops. Leftover MX costs more than Solo if replies matter.
What low volume actually means
Low volume is a number you can write: resets per day, receipts per day, peak hour. If you cannot write it, you will hit a cap and call it an outage.
Solo’s hourly send-as cap is real. A launch that invites 200 people in ten minutes is not a password-reset shape. Quote Business or Agency, or a specialist, the morning you plan the launch.
Digests that mail everyone nightly are campaigns even if the template says “notification.” Move them off this hop.
Staging must use a separate From or a separate domain. A staging loop against production SMTP will spend the cap and surprise users.
Retries without a user storm
4xx: backoff and the same event key. 5xx: stop and page a human. 250: do not send again for that key.
Users will double-click forgot-password. The app owes them one message, not five. History will show five 250s if you do not key the event.
Workers that replay a queue after a deploy must skip already-250 keys. That is app design, not MailerZ.
A later article covers retry without duplicates in more depth. The rule here is: one event id, one success.
Why this is not warm-up
Warm-up services and “send to your whole list to build reputation” are out of scope and often against AUP. We will not help dump users. Purelymail and others ban warm-up on their homepages. We are not a warm-up product either.
Open relays and verified sending are a later article. Authenticated, mapped From is the control. Unauthenticated 25 is the failure.
Secrets in env. Rotate on leak. Do not log passwords. Two-factor on the staff Gmail that reads notify@.
Registrar republish steals replies. Re-query MX after DNS saves. IPv6 failures are host problems after exclusive names exist.
Legal hold of notification content lives in the app and the user’s mailbox. MailerZ store windows are hops we accepted. Not a SIEM. Not SOC 2.
If a second operator needs the order, send this page plus the Postfix article. Map notify@. Exclusive MX if replies. Paid SMTP. Count caps. Idempotent events. Prove one. Close 25.
Paid plans do not authorize a blast. They raise caps. They do not buy inbox placement.
The artifacts that close app notification smtp custom domain are a written event count, dashboard SMTP in env, one unique 250, and a worker that will not replay success. Everything else is a campaign wearing a notification label.
Field notes for notify@ events
Write the event count first
Low volume is a number: password resets per day, receipts per day, peak hour. If you cannot write it, you will hit a cap and call it an outage. Solo’s hourly send-as cap is five. A launch that invites two hundred people in ten minutes is not a password-reset shape. Quote Business or Agency the morning you plan that launch, or use a specialist ESP. Confirm pricing.
Digests that mail everyone nightly are campaigns even if the template says notification. Move them off this hop. MailerZ is operational mail. Not a blaster. Not warm-up.
One event key, one 250
Users double-click forgot-password. The app owes them one message. Key the event. 4xx: backoff, same key. 5xx: stop and page a human. 250: do not send again for that key. Workers that replay a queue after a deploy must skip already-250 keys. That is application design.
Trigger one reset-style event to a mailbox you do not own. Unique subject. History 250. Header From is notify@, not noreply@localhost. Free has no send-as. Unhosted From is 550 / 5.7.1.
Staging must not spend production caps
Staging uses a separate From or a separate domain. A staging loop against production SMTP spends the cap and surprises users. Close port 25 on the app host. Submit to the dashboard port. Secrets in env. Rotate on leak. Do not log passwords.
If users reply to notify@, exclusive inbound MX and a mapped alias. Leftover MX steals replies. Re-query after DNS saves.
Legal and questionnaires
Notification content lives in the app and the user’s mailbox. MailerZ store windows are hops this layer accepted. Not a SIEM. Not SOC 2. Not HIPAA. Point questionnaires at the security page. CAN-SPAM applies if you dress a campaign as a notification.
Worked story: a deploy replayed the password-reset queue. Users got five messages. History showed five 250s. They added an event key, skipped successes, and kept one probe mailbox. The hop was fine. The worker was not.
Second story: staging pointed at production SMTP and invited the whole seed list. Hourly cap hit. Real resets 550’d. They split credentials, counted events, and proved one third-mailbox reset before the next launch.
Operator brief: count events, paid SMTP, mapped notify@, idempotent retries, one unique 250, closed 25, exclusive MX if replies. Start free for inbound. Solo when the first reset must leave as the domain.
Related: send and reply, how to test SMTP from a VPS, how to send transactional website email without Postfix, docs, pricing. Keep the written event count next to the dashboard pair.
Low volume means one event, one message, one From
How to send low-volume app notifications from your own domain is authenticated SMTP, not a campaign tool and not Postfix on the app host. Paid MailerZ send-as. From a mapped identity such as notify@ or noreply@ that you created. One message per user event. Idempotent retries so a double-click does not double-send. Count hourly and monthly caps on the live pricing page before you ship. Free has no send-as. Unhosted or unauthorized From is 550 / 550 5.7.1. MailerZ is not an open relay.
Copy the dashboard host, port, and TLS pair together. Do not paste a Gmail password into an env file and call it SMTP. Do not mail the secret to support. Rotate if a secret already leaked in a ticket or a CI log. Set From to the identity you created. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Header From, Subject, Date, Message-ID, body, and MIME stay intact on inbound. Envelope SRS only. Outbound is a second hop with its own auth records: one SPF, DKIM, DMARC from the dashboard. Two SPF records permerror.
If users will reply to notify@, publish exclusive MailerZ MX and map that local-part to a staff Gmail or Outlook. Leftover Google or registrar MX is a hard stop. Delete leftovers. Two public views. Probe from another mailbox. Self-send from the dest Gmail hides errors. If users must not reply, still map the From so inbound probes have a home, or accept that replies will 550 at an unhosted name. Do not leave notify@ as a silent black hole you promised in a privacy policy.
Volume math: Solo is one hundred outgoing per month and five send-as per hour. Starter two hundred and ten per hour. Business four hundred and fifteen. Agency eight hundred and twenty-five. Confirm /pricing. A password-reset spike of two thousand users in an hour is not this hop. Queue it or buy a transactional specialist and cite their docs. Do not “warm up” reply SMTP by blasting a list. That is how dests file you as bulk. This product does not sell an inbox SLA.
Retries without a user storm
Store an idempotency key per event. If the SMTP session 4xxs, retry with backoff and the same Message-ID policy you chose — usually a new Message-ID after a dest 5xx, same logical event id in your database so the user sees one email. A dest 421 for quota is not a reason to open port 25 on the VPS. Read the enhanced status. Empty MailerZ history on inbound replies means leftover MX or an unnamed alias, not a failed notify send.
Test with one password-reset style event to a mailbox you do not own. Unique subject. History 250. Header From intact. Do not loop all users. Do not use the production list as the first proof. Check the dest including spam. Classify is hop four. We do not promise Primary.
Why this is not warm-up and not Postfix
Opening port 25 on an app host makes you an accidental open relay the first time a library defaults wrong. Verified sending through MailerZ returns 550 to unauthorized recipients. That is the boundary. A campaign platform is a different product with suppression lists and unsubscribe law. Cite it if you need it. Do not hang a newsletter on notify@ and then ask why Gmail tabbed it.
A worked miss: a SaaS on Free shipped resets. 550. They waited overnight calling it deferral. Free cannot finish send-as. Waiting does not mint outbound. They moved to Solo, copied the pair, set From notify@, sent one probe. It landed. They did not then export the user table.
A second miss: the app used the same SMTP secret as a contractor CMS. The CMS leaked. Rotate in the same hour. Update the one env. Do not leave the old pair in a backup compose file. Agencies: separate credentials per client app. Offboard means revoke SMTP and delete MX you own.
Related: features, send and reply, docs, troubleshooting. RFC 5321 for SMTP. RFC 7208 if SPF breaks. Commercial competitor pages stay nofollow. MailerZ is not SOC 2, not HIPAA. Point questionnaires at /security.
Ship checklist for notify@
Paid plan that fits the monthly and hourly estimate. Identity created. Pair copied. Env not a ticket. Exclusive MX if replies matter. Leftovers gone. Two resolver views. One foreign probe inbound. One foreign notify send. Spam checked. Idempotency key in the app. No list blast. No Postfix. Confirm pricing. Start free only to prove inbound first. Sign in if the zone already lives here.
Review after a plugin swap or a staff departure. The next physical action is one event to a third mailbox, not another comparison tab. That is how low-volume app notifications from your own domain stay operational mail instead of a reputation incident.
If the dest 4xx repeats past a business day with quota proven empty, open a dest-side ticket with the full enhanced line. That is still not a leftover MX and not a Free 550. Keep exclusive MX while you wait. Do not add aliases to “see if a new From retries faster.”
Operator packet for notify@ in production
Event budget you can show engineering
Resets per day, receipts per day, invites per launch hour, digest yes or no. If digest is yes, it leaves this hop. If launch hour exceeds the card, change the card before the launch, not during the 550s. Solo is five send-as per hour and one hundred outgoing a month. Starter is ten per hour and two hundred outgoing. Business fifteen and four hundred. Agency twenty-five and eight hundred. Confirm /pricing. Caps are not inbox placement.
Write the event key scheme: user id plus event type plus day, or a UUID stored on the row. Double-clicks share a key. Deploys that replay must skip 250 keys.
Credentials and environments
Production pair in production env. Staging pair on a staging From or staging domain. Local laptops do not get production SMTP. Port 25 closed on every app host. Dashboard submission port only. Rotate if a secret hits logs or chat.
notify@ mapped if users reply. Exclusive MX. Leftover MX steals replies and looks like “notifications work but replies vanish.” Re-query after DNS saves.
Failure classes in the worker
AUTH failure: stop, page, fix env. 550 5.7.1: plan or From, not a retry loop. 4xx dest: backoff same key. 5xx dest: stop that address, do not poison the queue. 250: mark success. Empty history: you never reached MailerZ.
Do not open Postfix to “just get it out.” That is an open-relay rehearsal. Related: VPS SMTP test, transactional website email without Postfix, send and reply, CAN-SPAM if someone proposes a list.
Launch day
Prove one third-mailbox event the day before. Unique subject. History 250. Header From notify@. Then open the real trigger. Watch hourly remaining. If you designed a loop, you will find it in the first ten minutes. Stop the worker. Do not add leftover MX. Do not warm a list.
Start free for inbound. Solo when the first reset must leave as the domain. Not SOC 2. Not a SIEM. Store windows are hops, not notification archives.
More operational notes
Idempotency keys you can implement this week
Store a UUID on the password-reset row. Send once. On retry, if history or your table says 250, skip. If the user requests another reset, that is a new row and a new key. Do not reuse yesterday’s key. Do not use email address alone as the key or a second device will suppress a real second request.
Quiet hours and hourly caps
A burst at midnight UTC can still be noon for users and still hit Solo’s five-per-hour send-as cap. Spread invites. Or quote a higher card the morning you plan the burst. Caps are published so a bug cannot become a campaign.
Support mailbox versus notify@
Replies to notify@ should land on a staffed alias. If notify@ is receive-only, say so in the template. Do not print a From you will not staff. Exclusive MX still applies if you print it.
Close the launch checklist
One third-mailbox 250 the day before. Event budget written. Staging pair isolated. Port 25 closed. Worker skips successes. Hourly remaining watched. No list. No warm-up. Start free for inbound. Solo when notify@ must travel.
MailerZ remains inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. Not Google Workspace, not IMAP, not webmail, not an open relay. Unauthorized send is 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Not SOC 2, not ISO 27001, not HIPAA. Free is one domain, three aliases, one seat, a fourteen-day store, fifty outgoing messages per month, unknown recipients held, and no send-as. Solo is forty dollars per year. Starter is eight monthly or eighty yearly. Business is nineteen or one hundred ninety. Agency is thirty-nine or three hundred ninety. Confirm numbers on the pricing page. Limits are not an inbox-placement promise. Start free at the MailerZ register URL when inbound must be proven first.
FAQ
What is the safest way to handle app notification smtp custom domain?
Paid MailerZ SMTP, From a mapped notify@, one message per user event, idempotent retries. Count hourly and monthly caps on pricing. Exclusive MX if users reply. Free has no send-as. Do not dump a user list. Unhosted From is 550 5.7.1.
Does this require a new mailbox?
No. Users keep their inboxes. Staff can receive replies in Gmail if MX is exclusive and notify@ is mapped. MailerZ is not IMAP.
Will it work with Gmail or Outlook?
Recipients can be Gmail or Outlook users. Self-send is a bad gate. Prove to a third mailbox. Free cannot send as the domain.
What DNS records are involved?
Inbound exclusive MailerZ MX if replies matter. Verification TXT. Outbound SPF, DKIM, DMARC from the dashboard. Two SPF records permerror. See RFC 5321 and RFC 7208.
What should I test before production?
Trigger one password-reset style event to a mailbox you do not own. Unique subject. History 250. Header From intact. Do not loop all users. Do not open port 25 on the app host.
Key takeaways
- App notification SMTP: one authorized message per real event.
- Paid send-as. Free cannot. Caps on /pricing.
- Mapped From. No user spoof. No list dump.
- Idempotent retries. Never loop a 550.
- Exclusive MX if users reply to notify@.
- Close port 25 on the app host.
- Not a campaign sender. Not an inbox SLA. Not SOC 2.
- Prove one third-mailbox event before launch.
Conclusion and next action
If you want low-volume app notifications from your domain, count the events, pay for send-as, map notify@, and prove one message. MailerZ can authorize From it knows. It will not warm a list or run Postfix for you. Start free for inbound, Solo when the first reset must leave as the domain.
Ready to send resets as the domain
Start free for inbound, then Solo for notify@.
Copy dashboard SMTP. Count caps. Sign in if the domain is already there.
Review when event volume or caps change, and quarterly otherwise. Author: MailerZ editorial, Secuno LLC.