Authenticated email is not proof of delivery

An application can complete a business task successfully and then fail when sending the associated email. If your interface combines both into one green tick, the team lacks the information needed to know where to intervene.

A message has several observable states

In the fictional product design, a support portal creates notification N-68. The sending service accepts the job. Later, feedback from the receiving mail system arrives. The interface should derive precisely the statement supported by that evidence.

This table proposes a mapping for the design. It contains no sending tests performed here. The available feedback must be established for the service used and its events.

Domain checks answer a different question

A successful DMARC result confirms authorised use of the sender domain, not content quality or harmlessness. It is not a general acceptance guarantee either. The receiver may apply further checks and decide differently.

The product message should therefore not automatically turn a positive authentication result into “delivered”. Conversely, absence from the inbox alone does not explain which authentication mechanism might be faulty. Examine the sending route and the specific feedback together.

Treat feedback as part of the application

AWS describes separate events for bounces and complaints and notes that multiple notifications are possible. For this design, the application therefore needs to link events to the message and define how repeated feedback is processed. A second event should not trigger a second message without a reason.

If an event is missing, that part of the state remains unknown. Monitor such cases and assign handling to a responsible role. This lets the team manage the notification while the business task’s state remains traceable. The statement in the interface then follows the available observation.

Sources

• IETF: DMARC

• AWS: Setting up event notifications