Separate form submission from email delivery
A form can save or acknowledge a submission even when the notification email fails. First confirm whether the browser receives a successful response and whether the form plugin logs the entry. This tells you whether the failure occurs before or after WordPress creates the message.
Do not repeatedly change DNS records until you know which layer is failing.
- Submit a test with a unique subject or message.
- Check the form plugin entry/log if available.
- Review PHP or plugin errors for the submission request.
Use authenticated SMTP where appropriate
Many hosting servers restrict or poorly identify unauthenticated PHP mail. An SMTP provider gives WordPress a defined server, port, encryption mode and authenticated sender.
The From address should normally belong to a domain or mailbox authorized by that provider. Using the visitor's email address as the From address can cause authentication failures; use it as Reply-To instead.
- Confirm host, port and encryption match the provider.
- Use the correct mailbox username.
- Keep credentials outside public code repositories and page source.
Check SPF, DKIM and DMARC
SPF tells receiving systems which servers may send for the domain, DKIM adds a cryptographic signature and DMARC defines how aligned failures should be handled and reported. The exact records depend on the mail provider.
Do not publish multiple independent SPF TXT records for the same hostname. Combine authorized senders according to your provider's instructions.
- Look up the provider's exact DNS instructions.
- Confirm DKIM selectors exist after setup.
- Use a DMARC policy appropriate for your current authentication maturity rather than jumping blindly to rejection.
Test the mailbox path
A successful SMTP send does not guarantee inbox placement. Check spam, quarantine, forwarding rules and mailbox filters. Test both an address on the same domain and an external mailbox such as Gmail or Outlook to narrow the routing issue.
If only one recipient domain fails, inspect the bounce or SMTP response instead of changing WordPress globally.
- Test at least two recipient domains.
- Inspect bounce messages for error codes.
- Check whether the destination mailbox is over quota or filtering the sender.
Protect forms from abuse
Once delivery works, add proportionate spam controls. Honeypots, sensible rate limits and challenge systems can reduce automated submissions. Overly aggressive blocking can create a new problem by rejecting real enquiries.
Never expose SMTP passwords in JavaScript, HTML or public repositories. Server-side environment configuration is the safer place for secrets.
- Rate-limit repeated submissions.
- Validate and sanitize server-side.
- Log enough information to diagnose failures without storing unnecessary sensitive data.
Document the working configuration
After fixing the form, record the mail provider, From address, Reply-To behavior, DNS dependencies and which plugin performs the SMTP handoff. Future migrations are easier when this information is not rediscovered under pressure.
Retest the form after hosting, DNS or mailbox changes because all three can affect delivery.
- Keep a non-secret configuration note.
- Retest after migrations.
- Update the mailbox password in the server environment when credentials change.
Use the related free tools for diagnosis, or describe the specific website problem in the project form. Keep passwords out of the enquiry.
Discuss a focused project ↗