メールの送信に関しては、メールサーバの構成や経路がどうなって
いるかにも影響を受けます。

今回は、標準のメール機能を利用している場合と仮定させて頂きま
す。
この場合は、メディアの設定内で指定されたSMTPサーバを経由して
メールが送信されます。

メールの送信は、メールの送信先の最終的なメールボックスまで直
接送りつけるのではなく、メールの塊を複数のメールサーバを経由
してバケツリレー的にメールを転送していくようになっています。
ですので、SMTPサーバで指定したサーバに対して正常に送られたと
しても、相手のメールボックスに届けるために複数のメールサーバ
を経由している途中で障害が発生してしまう場合があります。
このようなメール配信の経路上での障害は、Zabbix側は最初にアク
セスしたSMTPサーバとのやりとりは終了してしまっているので、そ
の先の障害を検知できません。

つまり、最初にメール送受信処理を行ったSMTPサーバとの間でのエ
ラーしかZabbixのアクション処理では検知できません。

メディアの設定で指定したSMTPサーバへのメール送信処理要求時に
接続できないなどのエラーが発生した場合であれば、リトライを行
うようになっています。

リトライ回数

リトライ回数はソースのinclude/common.hで定義されている

　ALERT_MAX_RETRIES

の値になります。
デフォルトでは、3回になっているようです。
変更する場合は、ソースからコンパイルしなおす必要があります。

最終失敗時のアクション処理

該当するアクションの状態が「失敗」となります。
これは、Webフロントエンドですと、

　「ダッシュボード」画面の「最新20件の障害」のアクション欄
　「イベント」画面のアクション欄

などに表示されます。
また、最終リトライが失敗したからといって、新たに別のアクショ
ンが自動的に実行されることはありません。

その後経路障害復旧後失敗したアクション処理はどう扱われるか。

リトライ回数を過ぎてしまったものに関しては、さかのぼって処理
はされません。
リトライを行っている間に復旧すれば、メールは送信されるでしょ
う。

最後に、Zabbixサーバと直接通信してメール送受信処理を行った
SMTPサーバよりも先のメール転送経路で障害が発生した場合、メー
ルがどう処理されるかは経路となる各メールサーバの設定次第とな
ります。

より確実にメールで通知するのであれば、送信先として複数の全く
異なるメールサービスのメールアドレスを利用したり、他の通知方
法との併用もご検討下さい。

誤りがございましたらご指摘ください。　＞詳しい方々