A fallback copy was not added

Diagnose licence, configuration, detection, exclusion, duplicate, mail transport, and mailbox causes in order.

Written By Kelsey

Last updated About 1 month ago

Work through these checks in order. They separate Always Alert configuration and eligibility from downstream email delivery.

1. Confirm the licence and plugin are active

Open Always Alert → Dashboard.

If you see a licence-inactive or oversight-paused notice, fallback injection and monitoring are not running. Reactivate the licence, then test again.

Also confirm the plugin is active under Plugins and Enable Always Alert is selected under Always Alert → Settings.

2. Confirm the fallback recipient

Check that Fallback recipient email:

  • is present;

  • is syntactically valid;

  • is the exact inbox you are checking;

  • has not been replaced by a stale staff or agency address.

Save Settings after any correction.

3. Check the activity log

Go to Always Alert → Logs and find the form submission by time and subject.

The entry may show that the message was:

  • injected successfully;

  • excluded as a system or WooCommerce message;

  • skipped because it did not match Form Notification Mode;

  • left unchanged because the fallback recipient was already in To, CC, or BCC;

  • rejected from injection because the fallback address was invalid;

  • affected by another recorded handling reason.

The reason is usually the fastest route to the next check.

4. Review coverage and exclusions

In Form Notification Mode, a custom or unsupported form may not expose a recognised signal. Confirm the source article for the current compatibility list.

For a controlled diagnosis, temporarily compare the same form in Universal wp_mail Mode. If Universal mode handles it, the issue is likely detection rather than the downstream mail path.

Return to Form Notification Mode after the comparison unless broader coverage is genuinely required.

If the message is excluded, confirm it is not using a subject or header that makes it look like a common system or WooCommerce email.

5. Check duplicate prevention

Always Alert does not add the same effective recipient twice. Inspect the form’s To, CC, and BCC settings. If the fallback address is already present, no extra copy is added.

6. Confirm the form uses WordPress mail

Always Alert cannot handle messages that bypass wp_mail. Some hosted form services, CRM integrations, or custom code send directly to an external API.

Check the form plugin’s notification method and logs.

7. Separate injection from inbox delivery

If Always Alert logs the message as injected but the copy is not in the inbox:

  1. Run the Mail Handoff Test.

  2. Check spam, quarantine, mailbox rules, bounces, and suppressions.

  3. Review the SMTP or transactional-provider event log.

  4. Verify SPF, DKIM, DMARC, credentials, and provider status.

  5. Ask the receiving mail administrator to trace the message if the provider shows acceptance.

At that point, Always Alert has handled the WordPress message and the remaining investigation is downstream.

8. Check for plugin or custom-code conflicts

Other code may alter recipients or headers after Always Alert runs. Compare behaviour in a staging site with non-essential mail customisations disabled, and inspect provider logs for the final recipient list.

Do not disable security or mail plugins on production without a controlled plan.

Related articles