A property manager needs a password reset email whose required fields help a tenant recover access while leaving an auditable record of the instruction. Start with one application-owned recovery template and a separate audit record. The bill contains message transport, retained content, event storage, and investigation work; for the content term alone, keeping 2 identical full bodies consumes twice the body storage of keeping 1, before compression or storage overhead. That arithmetic is a design illustration, not a measured operating cost. Remove the duplicate body before considering a more elaborate template system.

TL;DR: A password reset email should identify the service and the requested action, contain a controlled recovery link, explain its validity and single-use behavior, and tell an unrecognized requester how to obtain help. These are proposed application requirements, not a universal list of fields mandated by an email standard. Keep the template version and delivery events as evidence; exclude the usable recovery secret from that evidence. For a property-management compliance notice, establish separately what the applicable rule accepts as service or receipt.

Keep secrets separate.

What fields belong in a tenant password reset email?

Treat the email as an instruction to the tenant, while treating the audit record as evidence about the instruction. Mixing those responsibilities encourages a tempting mistake: retaining a complete rendered email because it is convenient to inspect, even though its recovery link carries authority to change an account credential. A record that helps investigate a complaint should not become a second place from which somebody can initiate account recovery.

For an application implemented in Go, the following is a template acceptance checklist. It defines the behavior the application must implement before the wording can truthfully promise it; it does not claim that a particular set of visible fields establishes security by itself.

Template element Proposed content Acceptance boundary
Service identity The property-management service name and a clear recovery subject Identify the account service without including a unit number or tenancy dispute details.
Request explanation A statement that an account password reset was requested Do not imply that the request authenticates the person who submitted it.
Recovery action A clearly labeled link to the application's controlled recovery destination Keep the destination under application control and review the rendered target as well as its label.
Validity The application's actual expiration condition Publish wording only when the backend enforces the same condition.
Single-use instruction A statement that a successful reset consumes the recovery authorization Make consumption an application invariant, not merely template text.
Unexpected-request guidance A brief explanation of what to do if the tenant did not request recovery Ensure the guidance matches the application's actual account behavior.
Help route An established way to reach the service's support function Do not ask the tenant to reply with a password or recovery secret.

No password belongs in this template. Nor does the underlying compliance notice: the recovery message should enable access to the account where the notice can be handled through its own workflow. That separation preserves a useful distinction between a recovery request, a completed password change, and the later handling of a notice. They are three different application events.

The supplied validity statement deserves particular care. A template saying that a link expires cannot enforce expiration, and a single-use sentence cannot arbitrate two concurrent redemption attempts; the backend must decide which attempt consumes the authorization and reject subsequent consumption. An exactly-once mindset is useful here because it forces the invariant into a durable state transition. It should not become a promise of exactly-once email delivery.

Own the template and the evidence contract together

Template ownership is the primary decision. Give the application team responsibility for the recovery action, supported variables, version identifier, and retention boundary; require the party responsible for compliance language to review wording that describes notice obligations. This is a proposed division of responsibility, not a claim that one organizational arrangement satisfies every property-management rule.

A useful example record identifies a tenant account, a notice reference, a recovery-request identifier, a template version, a rendering locale, and the transport attempt identifier. Choose the account reference rather than a street address when the address adds no investigative value. The compliance notice should have its own record and its own evidence requirements. Link the records through an internal reference instead of copying the notice into the recovery email.

Version the words.

If a template can change without a retained version, an investigator may know that an email was submitted but be unable to establish what the tenant was told about expiration or support. Keep an immutable reviewed template artifact and its variable schema, then record which artifact a rendering used. Separate approved edits to explanatory language from changes to destinations or security promises, because those changes require different review expertise. A deployment that changes token behavior must include a check that the associated language still describes the resulting behavior.

This boundary also determines whether an external template editor is appropriate: require an exportable, reviewable version and a reliable way to associate that exact version with an attempt. If those conditions cannot be met, retain rendering ownership in the application. The trade-off is additional release responsibility for the application team in exchange for a simpler account of which words were authorized.

Reconcile delivery events without claiming proof of receipt

RFC 6376 describes DomainKeys Identified Mail, including the relationship between a signing domain, message headers, and a message body. Its signing-domain identifier is not an assertion that the signer is the author. A valid signature is therefore useful evidence within its defined scope; it does not establish that a tenant opened a recovery email, controlled the intended account, or received legally sufficient service of a compliance notice.

Those limits matter.

Use distinct application states for a recovery request, a submission attempt, a reported transport outcome, and a completed reset. Preserve the provenance and interpretation of each event. Do not relabel an intermediate transport event as tenant receipt merely because a reporting interface calls it delivery, and do not infer notice acknowledgment from successful account recovery. The relevant property-management requirement must determine what additional evidence is necessary. This article does not establish a jurisdiction's service rules or retention period.

An idempotent submission policy should attach retry attempts to one logical recovery request, while preserving each attempt as a separate audit event. Repeated ingestion of the same event should leave the interpreted state unchanged. That preserves reconciliation without erasing the attempt history, which is the difference between suppressing a duplicate state transition and pretending a retry never occurred. Record the event identity and its source so an operator can explain the distinction later.

Before release, exercise expiration, repeated redemption, concurrent redemption, a retry after an ambiguous submission outcome, and a repeated event notification. Inspect the generated email as well as the state transitions. Operational monitoring should distinguish submission failures from missing or delayed outcome events, and logs should reference the recovery request without recording its usable link. These are acceptance tests and operating rules for the proposed design, not reported performance results.

Retain the explanation and retire the secret

The storage change follows from the ownership choice: retain one immutable template artifact per version, retain the permitted nonsecret rendering inputs and event history per request, and avoid retaining a second complete body containing the recovery authorization. This reduces the duplicated-body term identified at the start. It does not establish that storage dominates the total bill; transport volume and investigation labor need their own measurements. Do not trade away evidence merely to improve an unmeasured cost estimate.

A template hash can help identify an artifact, but a hash alone cannot reconstruct its text. Likewise, a redacted rendering can explain the visible instructions while failing to reproduce the exact bytes of the original signed message. Decide whether either limitation is acceptable before adopting the retention policy. If exact-message evidence is required, that requirement needs a separate design for access control, secret lifetime, and retention review.

For this design, deliberately stop keeping usable recovery URLs in ordinary audit records, stop duplicating full bodies across routine logs, and stop retaining raw recipient details once the approved retention purpose ends. Keep the versioned explanatory text and permitted event references for the period established by the applicable policy. The cost appears during an investigation: a redacted record cannot reproduce the original usable link, and deleting recipient details can prevent later independent reconstruction of the destination. Accept those losses explicitly, with the compliance owner, before deletion begins.

References

RFC 6376 supplies the technical basis for the discussion of signing identity and the limits of message-signature evidence. The field checklist, ownership boundaries, tests, and retention choices above are proposed application controls; the RFC does not prescribe password reset email content or establish legal proof of service.

Further reading