At-Least-Once Delivery
The guarantee that a message will be delivered, possibly more than once — the practical default in every distributed messaging system.
The three delivery semantics and what each really means. At-most-once: fire and forget; messages can be lost; acceptable only for telemetry where loss is tolerable. At-least-once: acknowledged after processing, so a failure before the acknowledgement causes redelivery; messages are never lost and may be duplicated. Exactly-once: what everyone wants and what the network cannot provide.
The important claim to be precise about: exactly-once delivery is impossible across an unreliable network, because the acknowledgement itself can be lost and the sender cannot distinguish "processed" from "lost". What systems offer instead is effectively-once processing — at-least-once delivery combined with deduplication or idempotent handling, which produces the same observable outcome. Kafka's transactional producer and consumer offsets achieve this within Kafka; it does not extend to external side effects such as sending an email.
So the design rule is unavoidable and worth stating plainly: every consumer must be idempotent. Either the operation is naturally idempotent, or it deduplicates on a message ID, or it uses a conditional write. Anything else is a duplicate-processing bug waiting for a redelivery.