This is the only ability here that answers the actual question. Configuration can be flawless and mail still not arrive: a host blocks the port, a provider rejects the sending address, another plugin quietly takes over.
email/send-test-email puts a real message through the real mailer and reports what happened.
At a glance
| Ability | email/send-test-email |
| Toolset | Email Delivery — toolset/wp-mail-smtp |
| Group | Email Delivery › Diagnostics |
| Requires | WP Mail SMTP, active on the site |
| Capability | manage_options |
| Safety | Writes data |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
The gate on this one
This delivers a real email to a real inbox, so it requires confirm: true and a recipient that is never defaulted. Sending a test to whichever address the site happens to have on file is how test mail ends up in a client’s inbox.
How it works
When it fails, the mail plugin’s own error text comes back rather than a generic refusal. That text is the whole point — “535 authentication failed” and “connection timed out” send you to completely different places.
proves_delivery is deliberately separate from accepted_by_mailer. A mailer accepting a message means it took responsibility for it, not that it arrived; only checking the inbox proves the rest.
domain_check_passed reports whether the sending domain looks authorised for the mailer in use. A failure here is the commonest reason mail is accepted and then silently dropped or filed as spam.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
recipient | string | Yes | Where to send the test message. Never defaulted. |
confirm | boolean | Yes — must be true | This puts a real message in a real inbox. |
What comes back
| Name | Type | What it is |
|---|---|---|
recipient | string | Where the test was sent. |
mailer | string | Which mailer carried it. |
accepted_by_mailer | boolean | Whether the mailer took the message. |
domain_check_passed | boolean | Whether the sending domain looks authorised. |
proves_delivery | boolean | Whether this constitutes proof of delivery. |
notes | array | The mailer’s own error text and anything else it reported. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Send a test email to me at deepak@example.com so I can confirm mail works.
It resolves to one call:
{
"ability": "email/send-test-email",
"parameters": {
"recipient": "deepak@example.com",
"confirm": true
}
}Worth knowing
- Not idempotent — every call sends another message.
- Send it to an address you control. A failed test to a customer’s inbox is worse than no test.
- Read
noteson failure. The provider’s own wording is what tells you which thing is broken. - Run
email/get-delivery-statusfirst — it catches the cheap problems without sending anything.
Related abilities
- Diagnose Email Delivery — the cheaper check to run first
- Get Email Delivery Settings — what it will send as
- Update Email Delivery Settings — fix the sender and retest
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category