The MX constraint

What that means in practice

support@yourdomain.com is only available to you if that domain carries no other mail. This is the decision provisioning asks you to make, and pithy support is where you make it — running a support inbox and receiving mail generally both start here.

If your apex is already receiving mail — a mailbox provider, a marketing tool, anything with an MX record — claiming it for a support inbox takes that mail with it.

The answer everyone else uses

A subdomain:

support@help.yourdomain.com

It works identically and is slightly less polished. That is the whole trade.

Set up a help. zone, point Email Routing at that, and your apex mail is untouched.

Why the provisioning command will not decide for you

The routing flags are all-or-nothing and deliberately explicit:

pithy support provision \
  --routing-zone <zone-id> \
  --inbound-address support@help.example.com \
  --app-worker api

Creating a rule on the wrong zone would move your real mail, and that is not a mistake a provisioning command gets to make on your behalf.

Leave the routing flags off and everything else still provisions — the bucket, the classification Worker, the migrations. Add the rule when you have decided.

The same care on the way out

pithy support deprovision --routing-zone <zone-id> removes the routing rule first, so mail stops arriving before the Workers that would have handled it go away.

The zone is named for the same reason it is named on the way in: a rule is addressed through its zone, and this command will not go looking through your domains for one.

Leave it off and the rule stays — which the command tells you.

The rule name carries the project

<project>-global-support-inbound, deliberately distinct from the email capability’s bounce rule.

Idempotency keys on the rule name. Sharing one would make whichever capability provisioned second silently believe its rule already existed.

And the project segment is what stops two Pithy projects on one zone doing the same thing to each other — with the loser’s customer mail delivered to the winner’s Worker.

Until you configure an address, the inbox is inert

pithy add support wires the capability and runs the migrations. Until inboundAddresses is set, it ignores every message and says so once in the log — rather than quietly storing mail from an address nobody chose.

ESC