vCore Digital
Back to blog
WordPress emails landing in spam

Why WordPress emails are landing in spam

Websites depend heavily on email functionality across multiple use cases. When these emails end up blocked or in spam folders instead of reaching recipients, it creates significant business problems. This guide explores both straightforward solutions and more technical approaches to ensure WordPress emails reach their destinations successfully.

The “Plugin” Approach

The simplest method involves using a third-party SMTP service paired with a WordPress plugin. Sendinblue offers an attractive option, positioning itself as “an all-in-one marketing platform” with a perpetual free tier allowing 300 daily emails.

Integration with WP Mail SMTP by WPForms involves five straightforward steps:

  1. Install and activate the plugin
  2. Select your preferred SMTP service
  3. Generate an API key and configure sending details (domain, from name, from email)
  4. Review additional options as needed
  5. Complete the setup wizard

This approach eliminates technical complexity but may face restrictions in certain corporate environments.

The “Expert” Approach

When third-party services aren’t viable, configuring DNS authentication protocols provides an alternative solution.

Email Flow Overview

When sending an email from WordPress, the message travels from your outbound mail server through the internet to the recipient’s inbound server. However, the inbound server validates the sender by checking the Return-Path header, which often triggers spam classification. Three authentication standards help prevent this:

SPF (Sender Policy Framework)

SPF is an email authentication method protecting domains against spoofing and preventing messages from being marked as spam. It operates through DNS TXT records specifying which mail servers can send email for your domain.

A typical SPF record reads:

example.com. IN TXT "v=spf1 a mx -all"
  • v=spf1 - SPF version identifier
  • a - Authorizes servers with A DNS records matching the sender domain
  • mx - Authorizes servers with MX DNS records
  • -all - Rejects non-listed addresses; use ~all to mark as potential spam instead

For Microsoft Office 365:

example.com. IN TXT "v=spf1 a mx include:spf.protection.outlook.com -all"

Critical limitation: multiple SPF TXT records can cause validation failures. Consolidate all rules into a single entry.

DKIM (DomainKeys Identified Mail)

DKIM detects email spoofing by affixing digital signatures to outgoing messages. The receiving system verifies emails using the sender’s public key published in DNS, confirming message integrity and that header contents haven’t been modified.

Unlike SPF, DKIM encrypts only email headers, not the full body.

Microsoft Office 365 requires two CNAME DNS entries:

selector1._domainkey.example.com.  3600  IN  CNAME  selector1-example-org._domainkey.example.onmicrosoft.com
selector2._domainkey.example.com.  3600  IN  CNAME  selector2-example-org._domainkey.example.onmicrosoft.com

After publishing records, activate DKIM in Office 365’s administration panel under Administration > Exchange > Security > DKIM. Sendinblue provides required DNS entries after configuring a domain in the Senders and IPs section.

Important caveat: SPF and DKIM alone don’t guarantee delivery - look at these as instruments to help improve the decision making process on the recipient side.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC enables domain owners to protect against spoofing by publishing authentication policies in DNS. Receiving servers authenticate incoming email based on these instructions, determining whether messages should be delivered, quarantined, or rejected based on the domain owner’s specifications.

DMARC extends both SPF and DKIM capabilities, allowing administrators to specify which mechanism(s) to employ, how to validate the From field, and how to handle failures.

A DMARC DNS entry example:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:<email for reports>; sp=none; aspf=r;"
  • v=DMARC1 - Protocol version
  • p=none - Action for failing emails (use during setup; alternatives include reject or quarantine)
  • pct=100 - Percentage of emails to process; start with lower values like pct=10 when implementing rejection policies
  • rua=mailto:<email> - Report destination address

Providers supporting DMARC send XML reports to the specified email address, containing sender IP information and SPF/DKIM validation results. Third-party services like Postmark can translate these technical reports into digestible formats.

Final Thoughts

Email represents a critical business component. Proactive testing before site launch, proper DNS configuration, and selecting a reliable SMTP provider constitute the foundation for reliable email delivery.

Testing Resources: