What Always Alert can—and cannot—tell you about delivery

Interpret observed, injected, dispatched, and successful handoff states without mistaking them for final inbox delivery.

Written By Kelsey

Last updated About 1 month ago

Always Alert reports what it can observe inside WordPress. Email delivery continues through systems outside the plugin’s control.

Understanding that boundary prevents both false confidence and false alarms.

The delivery chain

A typical notification passes through:

  1. The form or WordPress feature.

  2. WordPress wp_mail and its filters.

  3. Always Alert eligibility, fallback injection, and metadata logging.

  4. The site’s SMTP plugin, host mailer, or transactional provider.

  5. DNS authentication and the sending provider.

  6. The receiving mail server.

  7. Spam, quarantine, and mailbox rules.

  8. The final inbox and its user.

Always Alert primarily observes step 3 and the WordPress handoff into step 4.

What the common terms mean

Observed

Always Alert saw a WordPress email that matched the active eligibility rules.

Fallback copy added or injected

Always Alert added the configured recipient to the message before the remaining mail stack handled it.

Dispatched or handoff successful

WordPress accepted a plugin-generated message for sending. This is not a final-delivery receipt.

Excluded

The message matched an enabled system or WooCommerce exclusion and was deliberately not treated as an eligible form notification.

No activity observed

No eligible message was seen during the configured period. This says nothing by itself about traffic, submission attempts, or mailbox delivery.

What Always Alert cannot prove

It cannot prove that:

  • the sending server accepted or retained a message;

  • SPF, DKIM, or DMARC passed;

  • the receiving server accepted the message;

  • the message reached the inbox rather than spam or quarantine;

  • the intended person read or acted on it;

  • a silent site has a broken form;

  • a message that bypassed WordPress mail was sent.

How to confirm final delivery

Use evidence from the whole chain:

  • controlled form submissions;

  • Always Alert logs;

  • SMTP or transactional-provider event logs;

  • bounce and suppression lists;

  • DNS authentication checks;

  • receiving-server traces;

  • mailbox spam, quarantine, rules, and access checks.

For high-value workflows, combine Always Alert with a reputable transactional provider and an operational process that reviews alerts and test results.

Why the product is called Always Alert

The product was previously named Always Deliver. The current name reflects its honest responsibility: create a fallback path, surface activity, and alert people to investigate. It does not promise a delivery outcome that depends on multiple independent systems.

Related articles