WordPress is often the application that creates a message, not the service that ultimately sends it to the recipient. A plugin name or a “sent” notification does not identify the IP evaluated by SPF or the domain in a DKIM signature. Follow one real application event across the boundary between WordPress, its transport and the receiving mailbox.
Identify who owns each stage
Start with the event: a password-reset request, order notification or contact-form submission. Record the plugin or code path that creates the message, the configured From address, the transport plugin if present, and whether it uses local PHP mail, remote SMTP or a provider API. WordPress’s mail handbook explains that plugins can replace the default sending route with third-party services.
Inspect configuration through authorized administration without copying credentials into a ticket. Record the service name, account or project label and sending domain, but keep API secrets and SMTP passwords out of the evidence file. Also check for fallback behavior. A plugin may be configured correctly for its main route while a separate job or fallback uses the hosting server.
Do not confuse application success with delivery
WordPress documents that a true wp_mail() return value means the sending method processed the request without an error, not that the recipient received the message. Similarly, a provider accepting an API call establishes a different stage from final delivery.
Correlate the application event with a transport or provider identifier and, where available, a delivery or bounce event. Keep timestamps in a consistent timezone. If the provider has no record of the event, investigate the application and plugin path before changing the provider’s DNS. If it accepted the event but the receiver rejected it, collect the full SMTP diagnostic and authentication evidence.
Configure authentication at the actual sender
For a remote SMTP or API service, use that service’s current domain-authentication flow. Publish its generated DKIM TXT or CNAME records exactly and activate the domain where required. Determine the envelope domain and whether the product supports a custom bounce or return-path domain. Do not invent a WordPress-wide SPF include; WordPress is not one universal outbound mail network.
For a hosting-server route, work with the host or mail administrator to identify the real public sending infrastructure and supported DKIM signer. Adding the website’s IP to SPF without proving that it sends the mail can authorize the wrong system. Maintain one appropriate SPF policy at the evaluated envelope domain and account for the lookup limit.
For DMARC, choose a From address under a domain the organization is authorized to send for. A contact-form visitor’s address normally belongs in Reply-To, not as a forged From identity. Configure an aligned authenticated path for the organization’s From domain and coordinate policy with other legitimate senders. Reply-To does not establish DMARC alignment.
Work through a synthetic event trace
Illustration only, not an executed WordPress or provider test:
- Stage: Order event; Example evidence label: order-test-42; What it establishes: Application requested a notification.
- Stage: Plugin submission; Example evidence label: transport-event-42; What it establishes: Selected transport handled the request.
- Stage: Provider acceptance; Example evidence label: provider-message-42; What it establishes: Sending provider accepted the event.
- Stage: External receipt; Example evidence label: Redacted raw headers; What it establishes: Final From, envelope, DKIM and DMARC results.
Suppose the delivered message uses From orders@example.com, a provider-owned envelope domain, and a passing d=example.com signature. DKIM can supply aligned DMARC authentication even if SPF is unaligned. If the fallback instead sends unsigned mail from a hosting IP not authorized for the envelope domain, the same application event can produce a different result. Test the fallback deliberately only within an approved scope.
Leave a maintainable handoff
Assign separate application, transport and DNS owners. Store the configuration version, generated public records and redacted successful and failed test evidence. Exercise password resets and other critical events after plugin upgrades, hosting migration, provider changes, From-address changes or key rotation. Monitor actual bounces and failures instead of relying on a green WordPress status.
On retirement, disable unused transport access and remove obsolete DNS authorization only after checking shared dependencies. Do not remove a provider’s records solely because one plugin was replaced if other applications still use that sender.
Separate four failure locations
Use the event trace to distinguish no application event, no transport submission, provider rejection and final-recipient failure. Record unknown when a stage has no reliable log. Do not infer provider rejection from an absent inbox message or final receipt from a successful method return. Preserve the original identifiers across the handoff so application and mail owners investigate the same event.