The mail your app sends.

• Mail to your domain

  A person emailing an address at your domain — a founder, a support inbox, a real mailbox someone reads.

  Handled by

  Your mail provider

  Routed by the MX and authentication records on the record sheet — carried over untouched when a domain moves here. See Domains for the full sheet.

• Mail your app sends

  A password reset, a receipt, an invitation — mail your own code triggers, addressed to someone else.

  Handled by

  This page

  The sending path below, the records it needs, and the honest limits on it.

• Bulk or marketing mail

  A newsletter, a mass campaign, anything sent to a list rather than triggered by one person's action.

  Handled by

  Not hosted here

  Unsolicited bulk email is a prohibited use on every plan — see Acceptable Use for the binding text.

1. 1

   Your app calls the relay, not the operating system

   A machine's own direct outbound mail port is closed on this class of infrastructure, and stays closed. An app that calls the operating system's own mail command has nothing to send through — it needs to call an authenticated relay instead.

   You

2. 2

   Credentials reach the app as environment values

   The relay endpoint and its credentials are wired in the same way any other secret is — never written into a file in your repository. See Access for how a secret is redacted from logs.

   CustomHosted

3. 3

   The message is signed with your domain's key

   The relay signs each message so a receiving server can confirm it really came from your domain, not just that it claims to.

   CustomHosted

4. 4

   The receiving side checks the records

   Whoever receives the mail checks the records on your domain against what just arrived — the record sheet below is what it is checking.

   The receiving side

5. 5

   Delivered, or a bounce comes back

   A pass gets delivered. A failure comes back as a bounce or a deferral — see the four failure modes below for who owns each one.

   The receiving side

• A new sender starts restricted

  A freshly verified sending identity can only send to addresses you have already verified, until that limit is lifted.

• So the request goes in during onboarding, not on launch day

  Ask for the limit to be lifted while the rest of the setup is happening. It takes a short review. Ask early, and the first real password reset does not quietly go nowhere on launch morning.

• Sending volume and reputation build from there

  Once the limit is lifted, sending starts small and steady rather than a sudden burst — a pattern receiving servers trust more than an unknown domain sending thousands of messages on day one.

• No mailbox on this domain

  customhosted.com has no mailbox of its own. The quote form is the one channel in, and it sends mail rather than receiving it.

• Sends as the domain

  The relay sends using this domain's own sending identity, not a generic address at a shared provider.

• Three signing records in this zone

  The signing (DKIM) records this page describes above are not hypothetical — three of them sit in this site's own zone right now.

• Started restricted, same as any new sender

  This identity could only send to a verified address until the limit was lifted — the exact restriction described above, not a special case.

• Delivers to an inbox someone already reads

  A quote-form submission lands as mail in a real inbox, not a queue nobody checks.

• Request logs kept 90 days

  Every request to the form is logged for 90 days — the same retention already published on Under attack.

See Logs for what "kept 90 days" means across every record class, not just this one.

If the sending path itself is down rather than one message failing, the same escalation ladder as everywhere else on this site applies — reused whole, not a second one:

1. 1

   Auto-handled

   A known, safe failure with an established fix — a crashed process, a failed health check, a stuck deploy. Restart, retry, or redeploy the last known-good version, done automatically

   No one, unless it recurs — it goes in the log, not a message to you

2. 2

   You hear from us

   Something that touched the app and needs a person to pick the right response, not just a retry. A human looks at it and decides what to do — revert, restore, or a fix in code

   You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent

3. 3

   Outage handling

   The site or a core function is down, or badly degraded, for real users. Worked ahead of the routine queue

   You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk

• No mailboxes

  We route and sign mail your app sends. We do not run a mailbox service — mail addressed to your domain stays with your own mail provider, untouched.

• No bulk or marketing sending

  Unsolicited bulk email is a prohibited use on every plan, not a paid tier away. See Acceptable Use for the binding text.

• Deliverability is never guaranteed

  Whether a message lands in an inbox, a spam folder, or nowhere at all depends on the receiving side's own filtering and your own sending reputation. Inbox placement is not something measurable from here, and nobody can promise it.

• A dedicated sending address or IP is quoted work, not a switch

  A shared sending identity covers almost every app. A dedicated one is real work we can build — quoted flat, the same as any other custom infrastructure request, not something switched on by asking.

• We cannot read the contents of your mail

  The relay moves and signs a message; what is inside it is between your app and the person it is addressed to.

• Swap the operating-system mail call for the relay

  The one-line fix a migrated app almost always needs — pointing its mailer at the relay instead of a mail command that has nothing to send through here.

• Add a bounce webhook

  Wiring a hard bounce back into your own data, so a dead address stops getting retried.

• Fix a from-address DMARC rejects

  A from-address that does not match your domain's own signing key fails DMARC outright — the fix is application code, not a DNS record.

• Add a queued digest job

  A weekly summary, a reminder, a report — a new background job that sends mail on a schedule.

Every one of those four ships the same way — Agentic iteration — CodeHerder ($25/mo):

1. 1

   A routine scan flags a dependency

   The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.

2. 2

   It's triaged as application-level, not infrastructure

   A library your own code imports isn't ours to patch silently — it can change how the app behaves.

3. 3

   Briefed as a change

   Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.

4. 4

   An agent opens the pull request

   The upgrade lands as a real pull request against the repository, with the test suite run against it.

5. 5

   A human reviews and merges

   Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.

6. 6

   It ships through the same pipeline

   The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.

7. 7

   You're told it's done

   A note confirming what changed and that it merged, in the same shape as every other note on this site.

1. 01Do you host mailboxes?

   No. We route and sign mail your app sends outward. Mail addressed to your own domain stays with whatever mail provider you already use — see Domains for how those records are carried over untouched.

2. 02Will my password-reset mail work on day one?

   Only once the sending path is wired up. A fresh sending identity starts restricted to addresses you have verified — see the restricted-start section above — so ask for the limit to be lifted during onboarding, not on launch day.

3. 03Why did my mail go to spam?

   Usually reputation or content, on either side of the message — nobody can promise inbox placement, ours included. See the honest limits above.

4. 04Can I send a newsletter from here?

   No. Unsolicited bulk email is a prohibited use on every plan — see Acceptable Use for the binding text.

5. 05Do I need a new SPF record?

   You need one SPF record, and you likely already have one. Ours is merged into the record you already have — a domain can only carry one, and adding a second one breaks the first.

6. 06I already use a sending provider — must I change?

   No. We wire the credentials for whichever relay your app calls — swapping providers is not a requirement of moving here.

7. 07Does staging send real mail?

   The classic staging mistake is a test run that emails or texts real customers. Anything a staging copy would otherwise send outward is caught or turned off, not delivered.