FluentSMTP setup and delivery diagnostics

Onact calls WordPress wp_mail and does not replace the transport, which allows FluentSMTP to supply a configured provider. Install FluentSMTP, choose the provider in its settings and enter credentials securely in the hosting or plugin configuration. Never put SMTP passwords or API keys into a support chat, public repository, frontend script or release archive.

Configure the sender

Use a sender address authorized by the provider and a recognizable site name. Match the provider’s required host, port, encryption and authentication options. Set up the domain records the provider requires, including the applicable SPF, DKIM and DMARC policy. Use the provider’s current instructions rather than copying unrelated settings from another service. A support mailbox and an authorized sending identity can differ. Confirm that replies reach the intended support address. Do not assume that an address on the site’s domain is allowed to send until the provider verifies it. Keep credentials server-side and rotate them if exposed.

Test the transport and real templates

Send a provider test from FluentSMTP, then trigger representative Onact messages on staging: account recovery, workspace invitation, contact acknowledgment, subscription notification and newsletter confirmation. Use controlled recipients and the provider’s test facilities where available. Check the actual HTML, links, plain-text readability and sender information. A successful wp_mail result means the message was handed to the configured mailer. Provider acceptance and inbox arrival are further stages. Inspect provider and FluentSMTP logs for rejection, authentication, rate limiting or suppression. Avoid printing credentials or full private message bodies into shared diagnostic output.

Check background work

Queued newsletters, automation and some notifications depend on WordPress jobs. Configure hosting cron to invoke due events reliably. Review the operator’s pause switch, batch size and daily budgets. A site with few visits can otherwise delay scheduled work even when SMTP itself is correctly configured. Do not increase every retry or budget to hide a failing provider. Resolve authentication, sender policy or recipient problems first. Retries should remain bounded and deduplicated. Separate transactional troubleshooting from marketing consent so an email test does not subscribe a user to campaigns.

Before launching live delivery

Use actual staging recipients you control, confirm unsubscribe and preference links, and review the operator identity and postal footer. Remove QA-only mail-capture components when moving to a real delivery environment. Keep any captured local mail out of Git and release artifacts. Document the chosen provider and the exact staging checks performed without recording secrets. The assistant can explain setup but cannot inspect provider credentials, guarantee inbox placement or configure the owner’s account. A working local queue is useful evidence, not certification of a live mail service.

Continue with related help

• Administrator controls, content import and safe maintenance

Search the help center · Current plans and limits · Contact support

Still need a hand?

The site assistant can find related guides. For an account-specific issue, use the support form and include the page URL and exact error, without passwords or payment details.

Contact support ↗