Sending domain and senders

Your sending domain, sender addresses, the purchase email, Development sends and the send response.

The sending domain

Add your domain on the Domains page and choose what it is for: your web app, email, or both. A domain for email gets all its records at once: SPF and DKIM for sending, and an MX for receiving. The page rechecks them until they are found. A mobile-only app has no web domain and can still have a sending one.

You choose where receiving lives when you add the domain:

• On mail.yourdomain (for shop.example.com, mail.shop.example.com). Sending and receiving share one record set, and the mail your domain already receives is untouched.
• On the domain itself, when its MX is Gemmein's.

Either way, people see your domain in the From line. Reply-To uses the domain too whenever a forward carries it there.

Sender addresses

Each kind of email leaves from its own address on your domain. The Domains page labels each one The word:

Each is a real address. Two kinds can never share one address; the dashboard refuses it. The defaults come from the word you gave the domain when you added it. The kind of a notify() sets only its cap, never its address.

The purchase email

When someone buys a product, through its Payment Link or a relay's fulfil_product, Gemmein emails the buyer once for that payment: Your <product> is ready, from your account address, with a link to your Library. The link is your app's verified web domain plus the Library path, never the file; the Library asks the buyer to sign in with the same email.

• On by default. Payments, under Products: Email buyers when they buy turns it off, and Library path sets where the link opens (/ until you set one).
• Sent only from your domain. With no verified sending domain, or no verified web domain to link, it is not sent; nothing leaves from a Gemmein address instead. Logs shows one row a day saying which is missing.
• Your own instead. Turn it off and send yours with notify(). Keys starting gemmein: are Gemmein's own and answer 400 reserved_key.

Development sends

In your cloud Development environment, every notify(), every relay email_person and every purchase email shares one daily budget: 20 a day per app and 50 a day per account. The next send answers 429 development_capped with resetAt. Sign-in codes are outside it, and Live has no such budget. Test volume locally with npx gemmein dev, which prints each send in the terminal and mails nothing.

Send response

notify() answers { sent, deduped?, recorded?, id, threadId, replyRail }.

• deduped: true: the same key was sent before, and this is its answer again.
• recorded: false: the email was sent but not saved to the Inbox.
• replyRail: whether a reply can reach you now.
• Two sends with the same key at once: the second answers 409 in_flight.
• The caps answer 429 with resetAt.

The full response, with every code, is in the SDK reference.