How to prevent WordPress password reset emails from going to spam

A password reset message is one of the most important emails a WordPress site sends. If it lands in junk, a customer, staff member, or administrator may assume the reset process is broken. The problem is usually not the reset form itself. It is more often related to the way WordPress hands mail to the server, the reputation of the sending domain, or the receiving provider’s filtering rules.

WordPress commonly sends mail through PHP’s mail() function via wp_mail(). That can work on a small development site, but it provides limited control over authentication, delivery records, and sender identity. A reliable setup uses authenticated SMTP or a transactional email service, correct DNS records, a consistent From address, and testing across providers used by Australian businesses and households.

Check how WordPress is sending mail

The first step is to identify the path taken by a password reset email. WordPress calls wp_mail(), but wp_mail() is only a wrapper. Depending on the hosting environment, the message may be passed to a local mail transfer agent, PHP mail, an SMTP server, or a plugin connected to an external provider.

Install a reputable SMTP plugin and inspect its test-email feature. Common options include FluentSMTP, WP Mail SMTP, Post SMTP, and similar tools that support authenticated connections. Send tests to different addresses, such as Gmail, Outlook, a business Microsoft 365 account, and an Australian ISP mailbox. A message reaching one provider does not prove that every provider accepts it.

Check the site’s error logs and mail logs if a test fails. A successful response from wp_mail() only means WordPress accepted the message for processing; it does not guarantee delivery to the recipient’s inbox. Some hosts disable PHP mail, throttle outgoing messages, or reject mail that uses an address unrelated to the hosting account.

Use a proper SMTP or transactional service

For production sites, authenticated SMTP is generally safer than relying on the web server’s default mail function. An SMTP plugin stores the connection details and routes messages through a provider that can authenticate the sender, retry temporary failures, and show delivery events. Services such as Amazon SES, Mailgun, Brevo, Postmark, and SendGrid are commonly used for transactional WordPress email.

Choose a From address on the same domain as the website, such as wordpress@example.com or no-reply@example.com. Avoid using a visitor’s email address in the From field, especially for contact forms. That practice can trigger SPF and DMARC failures because the message is sent by your server while claiming to come from another domain.

Keep the From name and address stable. A sudden change from a branded address to a personal Gmail account can make a password reset message look suspicious. Set a separate Reply-To address when replies should go to support staff. The technical sender should remain aligned with the authenticated domain.

Australian businesses often use Microsoft 365 or Google Workspace alongside WordPress hosting in Sydney, Melbourne, or Brisbane. If the website sends through a separate provider, document that arrangement and ensure it is authorised in DNS. This prevents an organisation’s mail policy from treating legitimate WordPress messages as unauthorised third-party mail.

Configure SPF, DKIM and DMARC

Sender Policy Framework, or SPF, identifies the servers allowed to send mail for a domain. Your DNS should contain an SPF record that includes the SMTP or transactional provider used by WordPress. There must be one effective SPF record for the domain; publishing several separate SPF TXT records can cause a permanent SPF error.

DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to outgoing messages. The email provider normally gives you a selector and a TXT record to add to DNS. Once published, the provider signs messages and the receiving server can verify that the content came from an approved source and was not changed in transit.

DMARC tells recipient systems what to do when SPF or DKIM alignment fails. Begin with a monitoring policy such as p=none, review the reports, and then consider a stricter policy once legitimate senders are accounted for. A basic policy may look like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

The correct record depends on your provider and reporting setup, so do not copy a generic value without checking the documentation. DMARC alignment matters because a message can pass SPF while still failing DMARC if the authenticated domain does not match the visible From domain.

DNS changes may take time to propagate, particularly when a domain is managed separately from the hosting account. Use a DNS inspection tool and the SMTP provider’s verification screen before testing again. If your domain uses a .com.au address, confirm that the DNS zone you edit is the authoritative zone registered with your domain provider, not an inactive zone inside the web host.

Improve the reset message and WordPress settings

The password reset email should be plain, direct, and recognisable. Use the site name, explain why the recipient received the message, and include one clear reset link. Avoid excessive capitalisation, misleading urgency, attachment files, URL shorteners, and marketing language in a security-related message.

WordPress generates the reset link with a time-limited key. Do not replace it with a permanent link or expose the user’s password in an email. A custom template can improve branding, but it should preserve the original reset URL and security behaviour. Test the link while logged out, on a mobile device, and in a private browser window.

Make sure the website URL and home URL use the correct HTTPS address in Settings → General. Mixed HTTP and HTTPS values can produce confusing links, redirects, or browser warnings. If the site recently moved from staging to production, search for old staging URLs in options, templates, and email customisations.

A security plugin, membership plugin, or WooCommerce extension may alter the reset process. Review filters such as retrieve_password_message and custom mail functions if the email body is unexpectedly changed. For troubleshooting, temporarily disable non-essential mail customisations on a staging copy rather than editing WordPress core files.

If you keep detailed test notes, a development notebook can help record SMTP settings, DNS changes, plugin versions, and the results from each mailbox. Never place SMTP passwords, API keys, reset URLs, or customer information in those notes.

Test delivery from the recipient’s perspective

Run a complete test from the actual WordPress login screen instead of sending only a generic SMTP test. Request a reset for a real test account, wait for the message, click the link, choose a new password, and confirm that the account can log in. Repeat the process after changing the From address or DNS records.

Use test mailboxes at Gmail, Outlook, Microsoft 365, and an Australian provider such as Telstra or Optus where possible. Check the spam and junk folders, then inspect the message headers. Look for Authentication-Results entries showing SPF, DKIM, and DMARC results. The visible result in the mailbox is useful, but the headers reveal why a provider made its decision.

Check the sending IP and domain reputation if messages are delivered but filtered. A shared hosting IP may have a poor reputation because of other customers. In that case, moving WordPress mail to a reputable transactional provider can make a significant difference. Sending large batches of newsletters through the same channel as password resets can also damage the reputation of critical transactional mail.

Test with Australian time zones in mind when investigating delays. A support team working in AEST may mistake a provider queue or rate limit for a failed message if testing occurs late at night or during a hosting maintenance window. Record the time in UTC as well as local time when comparing WordPress logs with provider events.

Keep security, privacy and compliance in view

Password reset mail contains a sensitive account link, even though it should not contain the existing password. Treat the message as security-related. Use HTTPS throughout the site, protect the WordPress login area, keep plugins updated, and avoid logging full reset URLs. Application logs and SMTP plugin logs should mask tokens where possible.

Australian organisations should consider the Privacy Act 1988 and the Australian Privacy Principles when selecting an email provider and retaining delivery data. Provider dashboards may store recipient addresses, message content, IP addresses, or event history outside Australia. Review the provider’s data-processing terms and your privacy notice, particularly for health, education, financial, or government-related websites.

The Spam Act 2003 is primarily associated with commercial electronic messages, and a password reset requested by a user is generally a transactional security message rather than promotional content. Still, keep reset emails strictly functional. Do not insert product promotions, unrelated newsletter content, or cross-selling blocks that could blur the purpose of the message.

Use rate limiting and abuse controls on the reset form. Attackers can submit another person’s address repeatedly, causing nuisance messages and potentially damaging your sending reputation. Generic responses such as “If an account exists, instructions have been sent” help prevent account enumeration. A security plugin, web application firewall, or hosting-level rule can limit repeated requests by IP address and account identifier.

Practical deliverability checklist

A consistent maintenance routine prevents a small mail configuration change from becoming a support incident. Re-test after changing hosting, DNS, SMTP credentials, the site domain, a security plugin, or the WordPress email template.

Use the following checklist for a live WordPress website:

• Send mail through authenticated SMTP or a transactional provider rather than depending on PHP mail().
• Use a stable From address on the website’s own domain and configure Reply-To separately.
• Publish one valid SPF record and enable DKIM signing with the provider’s supplied DNS values.
• Start monitoring DMARC reports and tighten the policy after every legitimate sending source is aligned.
• Test password resets with Gmail, Outlook, Microsoft 365, and at least one Australian mailbox.
• Review message headers, provider event logs, WordPress logs, and spam-folder placement after each configuration change.
• Rate-limit reset requests, keep reset links protected, and avoid recording tokens or sensitive credentials in logs.

A password reset email that consistently reaches the inbox is the result of several aligned systems: WordPress, the hosting environment, DNS, the SMTP provider, and the recipient’s mail service. Once those systems share the same authenticated domain and the message remains focused on account recovery, spam placement becomes much easier to diagnose and prevent.