Objective
Configure one authenticated WordPress mail transport, verify sender authorization and SPF/DKIM/DMARC results, and prove delivery using real application notifications.
- Reply-To works as intended, aligned SPF or DKIM supports DMARC, and temporary verbose logs are disabled.
Prerequisites
- Record the site, active mail integration, provider, From, envelope sender and Reply-To, plus one timestamped failing or baseline notification. Save the existing transport and DNS settings. Define success as delivery of the relevant form, password-reset or other application message to an approved test mailbox.
- The WP-CLI example requires the intended WordPress installation. The OpenSSL example is for a POSIX shell and a provider supporting STARTTLS on port 587; it verifies the hostname and chain using the configured trust store. Replace the quoted sample names. DNS observations do not by themselves establish message authentication or delivery.
Step-by-step procedure
Establish the baseline and scope
Record the site, active mail integration, provider, From, envelope sender and Reply-To, plus one timestamped failing or baseline notification. Save the existing transport and DNS settings. Define success as delivery of the relevant form, password-reset or other application message to an approved test mailbox.
- The intended target, prior configuration and service-specific success criteria are recorded.
Configure one transport and an authorized sender
Choose one maintained SMTP integration or a reviewed PHPMailer hook, and remove competing transport settings. Use the provider's required authentication and TLS mode with a dedicated sending identity. Set From to an address that identity is allowed to send as. A successful login does not authorize an arbitrary From address.
- One transport and a permitted sender are selected; credentials are kept out of public code and logs.
Keep form visitors in Reply-To
Use a stable authorized From address for contact-form messages. Put the validated visitor address in Reply-To when replies should reach that visitor. Check the form plugin's actual headers and reject newline/header injection. Keep the SMTP login, visible From, envelope sender and Reply-To distinct when reading a rejection.
- The received message has the intended From and Reply-To without impersonating the visitor's domain.
Check the actual envelope-sender domain
Inspect the received Return-Path and provider trace to identify the domain evaluated by SPF. Authorize the chosen sender using the provider's DNS instructions and preserve other legitimate senders in the same SPF policy. Check the published record and lookup limits; querying the site domain alone may miss a separate return-path domain.
- The message's SPF result is interpreted for the actual envelope domain.
Publish and verify the provider's DKIM selector
Enable signing through the sending provider and publish its exact selector record, which may be TXT or CNAME. Replace selector1 and example.com in the example with the real selector and signing domain. Verify the received DKIM-Signature and authentication result. A DNS answer alone does not prove that the message was signed or that verification passed.
- The received message has a valid signature for the intended signing domain and selector.
Check alignment on a received message
Compare the visible From domain with the domains that passed SPF and DKIM. DMARC needs a passing aligned SPF result or a passing aligned DKIM result, subject to the domain's alignment mode. Inspect Authentication-Results added by the receiving system and retain the provider trace. Do not weaken the published policy to disguise a sender mismatch.
- A representative received message passes DMARC through an identified aligned mechanism.
Separate TLS, authentication and delivery
From an authorized diagnostic host on the relevant outbound path, use the POSIX OpenSSL example for SMTP STARTTLS on port 587 only when supported by the provider. It checks the peer name and reports trust failures against the configured CA store. It sends no credentials or message and does not test WordPress authentication. Implicit TLS on port 465 requires the provider's different transport settings.
- TLS reachability is recorded separately from authenticated submission and mailbox delivery.
Keep only the evidence needed for delivery
During a controlled test, retain the time, recipient, provider/message identifier and sanitized error category. Correlate these with a received message or provider delivery trace. Restrict and expire diagnostic logs; avoid retaining passwords, access tokens and message bodies unnecessarily. Disable temporary verbose debugging and record who owns credential renewal.
- Useful delivery evidence remains without leaving verbose logs or credentials exposed.
Validate the complete service
One intended mail transport is active and the sending identity is allowed to use the configured From address. Record the full acceptance results below before extending the change.
- A real application notification reaches an approved test mailbox; its trace and authentication headers explain delivery.
- Reply-To works as intended, aligned SPF or DKIM supports DMARC, and temporary verbose logs are disabled.
Examples, targets and evidence limits
The WP-CLI example requires the intended WordPress installation. The OpenSSL example is for a POSIX shell and a provider supporting STARTTLS on port 587; it verifies the hostname and chain using the configured trust store. Replace the quoted sample names. DNS observations do not by themselves establish message authentication or delivery.
Observe active plugins from the intended WordPress installation using WP-CLI
wp plugin list --status=activePOSIX shell: observe STARTTLS with explicit server-name and trust checks; this sends no mail or credentials
openssl s_client -starttls smtp -connect 'smtp.example.com:587' -servername 'smtp.example.com' -verify_hostname 'smtp.example.com' -verify_return_error </dev/nullObserve a sample SPF domain; substitute the actual envelope-sender domain
nslookup -type=TXT 'example.com'Observe a sample DKIM TXT selector; use the provider's actual selector and follow CNAMEs if required
nslookup -type=TXT 'selector1._domainkey.example.com'Observe the visible From domain's DMARC policy
nslookup -type=TXT '_dmarc.example.com'Validation
The procedure is validated when:
- One intended mail transport is active and the sending identity is allowed to use the configured From address.
- A real application notification reaches an approved test mailbox; its trace and authentication headers explain delivery.
- Reply-To works as intended, aligned SPF or DKIM supports DMARC, and temporary verbose logs are disabled.
Rollback
- Restore the recorded transport, sender and DNS configuration if the new path fails acceptance; allow for DNS caching.
- Keep only one intended mail integration active and retest an essential notification after restoration.
- Revoke a new credential only after confirming it is no longer needed; disable temporary logging.
Troubleshooting / common errors
- TLS failure: verify provider hostname, mode, port, certificate chain and the diagnostic host trust store; do not disable validation.
- Authentication or sender rejection: correlate the exact provider response with the permitted identity and sender; do not weaken tenant policies globally.
- Submission succeeds but no inbox message: inspect provider trace, recipient filtering, bounces and received headers. A true wp_mail return value is not proof of mailbox delivery.
Official references
Keep the previous state, chosen targets, diagnostic times and observed outcome with the change record.