A background job fails, queues an email and succeeds on retry. The user receives “action required” after the result is already available. The template was accurate when it entered the queue. The notification policy was wrong.
Event does not equal email
For each event, write five fields before copy: eligible recipient, consequence of delay, channel, suppression rule and action. “Prompt” has no universal number of minutes; it means waiting could change the person’s next decision. Derive timing from the workflow.
| Illustrative event | Eligible recipient | Policy choice | Action |
|---|---|---|---|
| Import rejected before any write | Person who started it and still has access | Email only if the in-app result is no longer active; suppress after a successful retry | Review rejected rows |
| Configured review date approaching | Current assignee | Send at the workspace’s chosen lead time; cancel on completion or reassignment | Review the item |
| Routine status changes | Members who chose the relevant summary | Batch by workspace and period | Open one review |
| Job completes while the actor is viewing the result | No email recipient | Record in the product only | None |
These rows are editorial scenarios, not PBT behaviour or a universal notification standard. Test them against your product’s actual roles, state and obligations.
Urgency is about consequence, not importance
- Can this recipient act?
- Will waiting change the outcome or risk?
- Is the current state already visible where the person is working?
- Can several events become one decision-ready summary?
An important monthly review can wait for a digest. A failed import may deserve interruption during setup and no message after recovery. If nobody can act, keep the event in an activity log.
Make suppression a state machine
Recheck authoritative product state at send time. Cancel, redirect or batch only through explicit rules:
| State before send | Policy response |
|---|---|
| Resolved or stale | Cancel the queued message |
| Recipient lost access or ownership | Do not reveal workspace data; recalculate eligibility |
| Equivalent incident already open | Update the incident record instead of repeating the warning |
| Optional category disabled | Respect the stored preference for that category |
| Address bounced or complained | Apply the provider and application suppression rules; expose a safe in-product recovery path |
| Workspace deleted or paused | Cancel product updates unless a separately verified obligation applies |
Strictly transactional, optional product summary and marketing messages may have different requirements. In the United States, FTC guidance distinguishes commercial from transactional or relationship content by primary purpose and treats mixed content carefully. That US framing is not a worldwide classification. Get jurisdiction-specific review for your markets and message types.
Three fictional specimens, attached to policy rows
Illustrative only — no real recipient, customer, delivery result or compliance claim.
Failed import
Subject: Review the rows that were not imported
We stopped before adding records because required fields were missing.
Import reference: EXAMPLE-2048
Current state: No records added
Review the import
Open the product to see the current status. This message is no longer actionable after a successful retry.
Decision digest
Subject: Your workspace review is ready
The current review contains items that need a decision, completed items and blocked items.
Open the current review
This optional summary follows your saved digest preference. The product shows the latest state.
Assigned reminder
Subject: An assigned record is approaching its review date
You are the current assignee for this record.
Review the record
The reminder stops after completion, reassignment or a preference change, subject to the applicable policy for this message.
Transport evidence is not task evidence
In Resend’s documentation, delivered means the recipient’s mail server accepted the message. It does not prove inbox placement or human reading. Other providers may use different semantics. Keep the current task state in the product and link the email back to it.
Maintain only the structured lifecycle needed to operate the feature: notification type, recipient decision, related object, suppression reason, provider reference and states such as created, suppressed, queued, provider accepted, bounced, complained or cancelled. Do not store full message bodies or unnecessary personal data “just in case.” Define purpose, access and retention; legal duties depend on context and jurisdiction.
Authentication, without a deliverability promise
SPF lets a domain authorise hosts for MAIL FROM or HELO use. DKIM associates a domain with a message through a cryptographic signature. DMARC uses SPF or DKIM alignment with the author domain and can publish policy and reporting requests. None guarantees inbox placement, message safety or reading.
RFC 9989 is the current DMARC specification and obsoletes RFC 7489; RFC 9990 covers aggregate reporting. Detailed failure reports described by RFC 9991 can expose headers or content, so assess whether they are needed and protect personal data. RFC 8058 defines one-click unsubscribe for list email through specific headers and an HTTPS POST; it is not a rule that every transactional product email requires the mechanism.
Gmail sender requirements vary by sending profile and volume and apply to personal Gmail accounts. The page is dynamic: check the current rules for your sender instead of copying a threshold into product policy.
Skip a large template library, universal retry count and engagement dashboard. First prove one event-to-recipient row, its stale-state check and its failure path. Opens and clicks do not establish that the customer’s job completed. Email authentication does not establish deliverability performance.
Email rules are jurisdictional and mutable
- RFC 7208 (SPF), 2014-04; RFC 6376 (DKIM), 2011-09; RFC 9989 (DMARC), 2026; RFC 9990 (aggregate reporting), 2026; RFC 9991 (failure reporting), 2026; and RFC 8058 (one-click unsubscribe), 2017-01. Observed 2026-07-28. Protocol scope only; no deliverability guarantee.
- Gmail sender guidelines, requirements in effect since 2024, observed 2026-07-28. Gmail-specific, dynamic and dependent on sender profile.
- FTC CAN-SPAM compliance guide, published 2023-08 and edited 2024-01, observed 2026-07-28. United States only; not legal advice for other markets.
- Resend event types, bounce documentation and suppressions, observed 2026-07-28. Mutable provider semantics; citation does not imply PBT uses Resend.