A domain support email should be available before commercial traffic is sent.
Support Readiness
WeAcuRe should publish a clear support path before checkout, live forms, email updates, or member access are enabled. The current prototype has no public inbox, no message form, and no support ticket system.
Support scope before launch
Users need a clear channel for duplicate payment, access, and refund questions.
Consent, unsubscribe, deletion, and support requests must share a clear route.
Before public support email
- Use a WeAcuRe domain inbox, not a personal mailbox, for public support.
- Prepare domain mail authentication such as SPF, DKIM, and DMARC before relying on outbound support or update email.
- Confirm inbox access, forwarding if used, and reply-from identity before publishing the support route.
- Do not record mailbox passwords, recovery codes, provider tokens, personal mailbox addresses, or private support messages in GitHub, Obsidian, screenshots, or chat.
- Review Support Intake Boundary before adding support forms or tickets.
- Review Operations Readiness before public traffic or support load increases.
- Review Delivery Readiness before paid access support is enabled.
- Document response scope for payment, refund, access, unsubscribe, and deletion requests.
- Keep support messages separate from birth data, chart output, campaign records, and provider credentials.
- Update Contact, Privacy, Terms, Refund, Payment Readiness, and Email Consent Boundary.
Mail authentication preflight
Confirm inbound mailbox or alias and MX routing if the provider requires it.
Confirm SPF record is published, DKIM signing is enabled, and DMARC policy is published.
Send inbound test, send outbound reply test, and confirm reply-from identity.
Do not record mail DNS verification token, DKIM private key, mailbox password, provider token, personal mailbox address, or support message in GitHub, Obsidian, screenshots, or chat.
Before support forms or tickets
- Do not collect birth date, birth time, chart screenshots, or private identity files by default.
- Use hosted support tools only after provider, retention, and privacy wording are reviewed.
- Explain what information users should include for payment or access support.
- Keep SMS support as a later optional channel with separate explicit consent.
Related pages
Review Contact, Refund Policy, Support Intake Boundary, Operations Readiness, Delivery Readiness, Payment Readiness, Email Consent Boundary, Provider Readiness, Privacy Boundary, and Terms before enabling public support.