Trace a WordPress email failure from wp_mail to delivery evidence.

Confirm which WordPress transport handled the message

The EmailDesk API Sender intercepts wp_mail when the plugin is enabled and live routing is active. Another mail plugin, a plugin conflict, or disabled live routing can cause a different transport to handle the message.

Use the plugin's controlled test and then test the real workflow, such as a password reset, form notice, or store notification. A synthetic test can pass while a workflow supplies a different From address, recipient, header, or attachment.

• Confirm the EmailDesk plugin is active and its settings were saved.
• Check whether another SMTP or mail-routing plugin is also intercepting wp_mail.
• Test one real business workflow after the plugin test succeeds.

Verify the API credential and sender identity

The WordPress plugin uses a customer API key. That key is not an SMTP password. Confirm that it is active, belongs to the correct customer workspace, and is allowed to use the configured sender domain or exact address.

The From address must be allowed and verified in EmailDesk. For a contact form, use the site's verified business address in From and place the visitor address in Reply-To when the form supports it.

• Store the API key only in the protected WordPress settings.
• Rotate the key after suspected WordPress administrator or server compromise.
• Do not copy the key into browser code, analytics, source control, screenshots, or debug reports.

Check DNS, quota, and sender readiness

The selected EmailDesk gateway requires its sender-domain authorization, including the applicable SPF check. Production identity should also use the provider-issued DKIM selector and aligned DMARC.

A valid API request can still be stopped by customer status, sender scope, recipient limits, attachment limits, quota, suppression, or gateway readiness. Read the EmailDesk response and Outbound History reason rather than treating every failure as a WordPress error.

Distinguish request failures from fallback delivery

A WordPress HTTP error or timeout can point to DNS, TLS, firewall, hosting egress, endpoint configuration, or PHP request limits. Keep certificate validation enabled and test from the web server environment.

When fallback is enabled and the EmailDesk API attempt fails, control returns to the normal WordPress mail path. That fallback message may not appear as an EmailDesk API send. When fallback is disabled, the failed EmailDesk attempt returns failure to WordPress.

• Choose fallback behavior before live forms or account notices depend on the integration.
• Check the normal web-server mail path separately if fallback may have run.
• Enable WordPress debug logging only during investigation and remove sensitive values before sharing logs.

Keep WordPress and delivery evidence separate

A successful API response or queued provider handoff proves only that stage. It does not prove that the recipient provider accepted the message, placed it in the Inbox, or displayed it to the user.

Review later deferrals, rejections, bounces, complaints, suppressions, and recipient-provider filtering where evidence exists. If a timeout makes the handoff uncertain, inspect EmailDesk history and the recipient mailbox before sending again.