Business Role Addresses

How to route one public address to two founders

One hop. Two stores. Write who replies. Leftover MX is not a second founder.

MailerZ editorial · Secuno LLC16 min read

Routing one public address to two founders is a named alias copied to two existing stores. Create hello@ or founders@. Map founder A and founder B. Name who replies. If replies leave as hello@, use one paid send-as identity — not two shared mailbox passwords. Exclusive MX. Probe both Gmail or Outlook dests from another mailbox. Hold unknowns. MailerZ is not a shared inbox product. Envelope SRS only. Header From on inbound stays the customer.

One public alias copied to two founder destination inboxes
A copy into two stores. Not a shared login.

Quick answer

Create one named alias. Add two founder destinations. Name the replier. Publish exclusive MX. Probe both stores. That is the whole design. A third dest is usually a CRM or a mistake — date it if you must. Send-as is one pair. When a founder leaves, remap and rotate. Leftover MX fails both founders the same way.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as Off, SMTP Off, API Off, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99 monthly or $990 yearly. Confirm live numbers on MailerZ pricing. Those ceilings are capacity, not an inbox-placement promise.

Gmail Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a suite is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol. None of those pages ask you to share a Gmail password.

The real decision

Two founders answering the same homepage address usually start with a shared inbox password. That feels simple. It is a lock-in and a leak waiting for last day. The replaceable design is two dests they already search, one public string, and one named replier so customers do not get two competing threads.

Criteria: two dests, one replier, exclusive MX, dual probe. Both sending as hello@ ad hoc with the same secret forever is how you cannot rotate. Only probing one dest is how founder B swears the alias is dead while founder A’s Promotions folder is full.

Two founders, one string
NeedDoAvoid
VisibilityTwo destsShared password
ReplyNamed founderBoth send ad hoc
LeaveRemap and rotateKeep leftover dest
ProofProbe both including spamSelf-send
UnknownsHoldCatch-all as a third founder

Map two dests, name the replier, and prove both stores from another mailbox.

Start free — one domain

Technical mail flow

RCPT TO hello@ matches the named map. MailerZ opens two destination SMTP sessions. Mixed 250 and 5xx is a dest problem, not a half-deleted alias. Probe both stores. Fix quota on the full one. Send a new subject after the fix.

Header From stays the customer so both founders see who wrote. Envelope SRS may rewrite MAIL FROM. Subject, Date, Message-ID, body, and MIME stay intact. That is why this is a copy, not a rewrite into a shared mailbox identity.

One public From identity for replies, two destination inboxes for inbound
Name who sends as hello@. Inbound still copies to both.

Outbound as hello@ is a later hop. One credential on a paid plan. Free returns 550 if you skip that plan. Catch-all is not a second founder. Plus addressing on Gmail is not a custom-domain unknown policy.

MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Not Google Workspace, not IMAP or POP, not an open relay. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Two dests multiply classify: dest A can file Primary while dest B files spam. Search both.

Step-by-step setup

Write both dest emails and the one replier on a line. Then create hello@ or founders@. Do not invent the public string after you printed the homepage.

  1. Pick the public string you will print

    hello@ is the usual brochure name. founders@ is honest if you want that tone. Do not print both unless you will operate both.

  2. Map two founder stores

    Name the replier. If both must see mail, both are dests. If only one replies, write that down so the other does not start a second thread.

  3. Publish exclusive MX

    Delete leftover Google, Microsoft, Cloudflare routing, and registrar hosts. Leftover MX is not a second founder. Help lives on troubleshooting.

  4. Probe from another mailbox

    Unique subject. Check both dests including spam. History should show forwarded toward both. Empty history is hop one, not “founder B’s Gmail is broken.”

  5. Add send-as only if From must travel

    Paid plan. One pair. Attach Gmail Send mail as or Outlook SMTP on the replier’s store. Labels in Google Gmail Help — Send mail from a different address. Do not paste the pair in a shared note forever.

  6. Write the leave rule now

    When a founder leaves, remap and rotate the same hour. That is the employee-leave article with a shorter list. Do not add the intern as a third dest “for visibility.”

Related: aliases and catch-all, use cases, send and reply. sales@ to a larger team is the AE version. This page is two owners.

Failure modes and proof

Two dests, one public string
SymptomLikely causeWhat to check
One founder sees mail, the other does notOne dest probed, or dest filter.Search both including spam. New subject.
Both see nothingLeftover MX or unnamed alias.Public MX. History row.
Two competing reply threadsNo named replier.Write who sends. One send-as identity.
550 on sendStill on Free, or guessed From.Paid send-as. Named alias.
Shared Gmail passwordWrong object.Two dests. Remap later without a reprint.
Third dest filling with noiseCatch-all or intern “visibility.”Hold unknowns. Two dests only.

If both dests are empty, print public MX before you blame either founder’s spam folder.

Open leftover MX troubleshooting

MailerZ workflow and product boundary

Probe both founder inboxes after mapping one public alias
Two dest searches. One unique subject.

MailerZ copies inbound to the dests you map. It does not offer a shared reading pane, presence, or assignment. If you need a shared mailbox product, buy one and make that the dest — still one dest object, or two if you insist. Do not ask this hop to become Slack.

Two dests train two spam buttons. That is the tradeoff for visibility. Name the replier so you do not also train two outbound identities. MailerZ does not promise Primary on either dest. Classify is hop four at each store.

Agencies should not pour every client hello@ into two agency founders plus a catch-all. Per-client dests. Per-client SMTP. Offboard means remove dests you do not own and revoke secrets. Agency plan capacity is for zones, not for infinite dests on one string.

Cost and alternatives

Two dests do not cost two MailerZ seats. A seat is a dashboard operator. Free can hold the alias if you have a slot among ten. Paid send-as starts at Solo, $40 per year, if hello@ must leave as From. Confirm pricing. Limits are not an inbox SLA.

Alternatives: a Microsoft shared mailbox as the single dest (suite object, suite MX if that product owns inbound); Google Groups as a dest (still a dest, still one inbound owner); two public strings (hello@ and founders@) if you want different tones. Dual MX is not an alternative. It is a split.

A suite seat per founder is correct if they need Calendar and a lockable store. It is the wrong buy if you only needed two dests on one printed name. Privacy-mask products are the wrong buy when customers must write hello@ on a domain you own.

Worked examples

They shared one Gmail because it was faster

Last day became a password fight. They created hello@, mapped both personal Gmails, named founder A as replier, attached send-as on A’s store, and probed both. The homepage did not change. The next leave is a remap.

Only founder A was probed

Founder B swore the alias was dead. The unique subject sat in B’s Promotions. They searched both dests, trained B’s store, and left the map alone. Mixed classify is two facts. Do not delete hello@.

One dest 452 mailbox full

History looked broken. A 250’d. B 452’d. They freed quota, sent a new subject, and kept both dests. Averaging the two codes into “the alias failed” would have been the wrong ticket.

Leftover MX as “the other founder”

They thought Google MX plus MailerZ MX meant both people would see mail. Half the senders never hit the map. They deleted the leftover, waited, probed both dests. Two founders live on dests, not on priority numbers.

Write the replier on a sticky note next to both dest emails. If the sticky note says “whoever sees it first,” you will get two threads. If it says “shared password,” rewrite it to two dests. If it says “add the intern,” write an end date or do not add them.

Print the public list. One hello@ plus two dests is enough for a brochure. Do not grow catch-all because you cannot decide the string. Hold unknowns. Promote a leftover only when a real person used it.

When a founder leaves, treat it as the employee-leave hour: keep hello@, remove their dest, rotate SMTP, probe the remaining dest and the remaining founder. Overlap by design ends when the person ends. Do not keep three dests because you were tired.

Self-send from founder A to hello@ that lands in A is not proof B is on the path. Use another provider. Put a unique subject on the probe so both can search. If Header From was rewritten by some other forwarder, you are debugging the wrong hop. MailerZ does not rewrite Header From on inbound.

Two dests multiply support noise. Paste which dest 250’d and which dest 5xx’d before you ask anyone to “check delivery.” Do not mail passwords. Confirm pricing only if outbound 550 is the actual line.

Quarterly leftover MX review still applies. Two founders do not make split MX safer. They make it twice as confusing. Review sooner after a nameserver move or a plugin swap.

Who replies, who watches, who holds the secret

Write three names even if two of them are the same person. The watcher dests can be both founders. The replier should be one. The SMTP secret holder should be one dashboard operator, not a Slack snippet. When founder B is traveling and founder A must send, A uses the same approved identity, not a second guessed From. After the trip, you still have one pair to rotate.

If both founders insist on sending as hello@ from two laptops, you still have one identity and two copies of the secret. That is worse hygiene, not a second product. Prefer one composer. If you cannot, rotate the hour either laptop is lost. Do not wait for last day.

CRM as a third dest

A dated CRM dest can be right for a launch week. An undated CRM dest is how hello@ becomes a warehouse of marketing events and two founders stop reading. If you add it, write the morning you will remove it. Hold unknowns so the CRM does not also eat harvest. MailerZ will not become your CRM. It will copy a message to a mailbox the CRM already watches, or it will not.

Do not point catch-all at the CRM because you want “everything.” That is how you train a third spam button and a fourth ticket. Named hello@ to two humans is the job on this page. Everything else is a different article.

Time zones and weekend operators

Two dests in two time zones is why people want this design. It also means classify happens twice, at two local times, with two junk models. A Friday night probe that founder A sees immediately can sit in founder B’s Promotions until Monday. That is not MailerZ losing the copy. Search both before you rebuild the alias.

If one founder uses Outlook and one uses Gmail, prove both. Outlook junk and Gmail Promotions are different folders with the same unique subject. Mixed dest vendors are fine. Mixed MX operators are not. One inbound owner. Two stores. Confirm pricing only if outbound 550 is the line you actually have.

A last pass: print hello@ on the homepage only after both dests showed the unique subject. If you cannot get founder B to open spam, you are not ready to print. Visibility that only works for one founder is a shared-password design wearing a second dest. Confirm pricing the day you add send-as. Solo at $40 per year is the usual door for one From identity shared as a pair, not as a Slack paste.

Filters, vacation, and threads

Each dest keeps its own filters. Founder A can auto-label hello@ as Customers. Founder B can leave it in the inbox. That is fine. What is not fine is two vacation responders both firing on the same customer thread. If A is the named replier, B’s vacation should not claim hello@. Dest-side autoresponders are dest policy. They are not MailerZ features. Write who may auto-reply before the first holiday.

Conversation view lies. A customer thread that A answered as hello@ may look to B like a personal Gmail thread if B was only a dest. Open original. Confirm Header From on inbound is the customer. Confirm outbound Header From is the role if you paid for send-as. Do not debug “Gmail rewrote the alias” until you opened original.

Mobile notifications double. Two phones will buzz. That is the point of two dests and also how people mute the alias and then miss invoices. If B mutes hello@, B is no longer a dest in practice. Remove them or accept that only A is watching. A dest that never opens mail is a leftover dest with extra steps.

If you later hire a third person for hello@, stop and write the model again. Three dests is a team inbox problem. This page is two owners. A shared mailbox product or a help desk may be the honest next object. MailerZ can still be the hop into that object. It will not assign tickets.

Envelope SRS and intact Header From still matter when two people forward a copy onward from Gmail. If founder A hits Forward in Gmail, that is Gmail’s hop, not MailerZ. The customer’s From may survive or not depending on Gmail. Do not blame this layer for a dest-side forward. The public path is MX to MailerZ to two dests. Everything after that is dest policy. If you need a paper trail of the hop, look at delivery history inside the published store window — 14 days on Free, 90 on paid, 180 on Unlimited — not at either founder’s memory of Primary. Those windows age out. They are not a second archive for either founder.

Calendar invites and double-CC noise

A meeting invite to hello@ lands in both dest calendars if those dests treat inbound mail as invitations. Two founders then accept twice, or one accepts and the other looks like a no-show. Name who owns calendar for that public string. The other dest can leave the invite unread or decline with a note that A will attend. MailerZ will not pick a free/busy slot. It copied a message.

Customers who already have both personal Gmails will write hello@ and CC both founders. That is three copies of the same thread, not proof the alias failed. Tell frequent vendors to use hello@ only, or to use personal addresses only. Mixing both is how people answer the CC and ignore the role. If the noise is unbearable, the dests are still correct — the customer list is the problem. Do not add a fourth dest “so we do not miss the CC.” Confirm MailerZ pricing only if send-as is the next hop, not because a calendar invite annoyed both phones.

FAQ

How do two founders share one public address?
Create one named alias such as hello@ and map two founder destinations. Name who replies. Use one paid send-as identity if replies leave as that address — not two shared passwords. Exclusive MX. Probe both stores from another mailbox.
Does this require a new mailbox?
No. MailerZ is not IMAP and not a shared-inbox product. Each founder keeps Gmail or Outlook. The alias is a copy to two dests, not a third login.
Should both founders send as hello@ with the same SMTP secret?
Prefer one named replier and one pair. A second founder who must send as hello@ still uses that same approved identity, not a second guessed local-part. Do not paste the secret in a shared note forever. When someone leaves, remap and rotate the same hour.
What if one dest 250s and the other 5xxs?
That is mixed status, not a half-broken alias. Probe both stores. Fix quota or policy on the failing dest. Send a new subject after the fix. Do not delete hello@ because one inbox was full.
What should I test before printing hello@?
Send a uniquely titled message from an unrelated provider. Confirm Header From, a history row, and arrival in both dests including spam. Self-send from founder A to founder A is not the public path.
Is leftover MX a second founder?
No. A leftover Google or Microsoft host is a split, not a dest. It hides copies from both founders. One inbound operator. Then two dests.

Key takeaways

  • One public string. Two dests. Not a shared mailbox password.
  • Name who replies. One send-as identity if From must travel.
  • Probe both stores including spam. Mixed 250/5xx is two facts.
  • Leftover MX is not a second founder.
  • Catch-all is not a third founder. Hold unknowns.
  • Free can hold the alias. Solo $40/year starts send-as.
  • When someone leaves, remap and rotate the same hour.
  • MailerZ is not a shared-inbox product and not IMAP.

Conclusion and next action

Route one public address to two founders by mapping two stores you already search. Name the replier. Cut leftover MX. Probe both dests. Pay for send-as only if hello@ must leave as From. Do not share a password. Do not use dual MX as a person. If founder B never searches spam, you are not ready to print hello@ on the homepage. Mixed dest 250 and dest junk are two facts, not a reason to delete the public string.

One string, two stores

Start free, create hello@, map both founders, probe both dests.

Name who replies. Rotate when someone leaves.

Review when a founder changes, and leftover MX quarterly. Author: MailerZ editorial, Secuno LLC.