Why your website’s emails land in spam
A customer fills in your contact form and never hears back. An order confirmation lands in someone’s spam folder, or never arrives at all. Nobody tells you, because nobody knows the email existed. From your side, it just looks like a quiet week.
It’s one of the most common problems we fix, and the cause is nearly always the same: the email your website sends can’t prove it really comes from you.
How your website sends email
Out of the box, WordPress sends email through the web server itself. The message claims to be from you@yoursite.com, but it leaves from a server that has nothing to do with your email provider. To Gmail or Outlook, that looks exactly like someone forging your address, which is what spammers do all day.
Mailbox providers have also stopped giving the benefit of the doubt. Since February 2024, Gmail and Yahoo have required everyone who sends to their users to authenticate their mail, with stricter rules for bulk senders. Microsoft introduced similar rules for high-volume senders to Outlook in 2025. Mail that used to squeak through now goes to spam or is refused.
Three DNS records do the proving. They’re added wherever your domain’s DNS is managed.
SPF: who’s allowed to send
An SPF record lists the servers allowed to send email for your domain. The receiving server checks the sender against it.
yoursite.com TXT "v=spf1 include:_spf.google.com include:amazonses.com ~all"That one says Google Workspace and Amazon SES may send for this domain, and anything else should be treated with suspicion.
What goes wrong:
- Two SPF records. A domain can only have one. Add new senders to the existing record instead of creating a second.
- Too many lookups. SPF allows at most 10 DNS lookups, and every
includecounts, including the ones nested inside it. Add enough services and the whole record fails. - Forgotten senders. Your website, your newsletter tool and your invoicing app all need to be covered.
DKIM: a signature on every message
DKIM adds a cryptographic signature to each email. The sending service keeps a private key, and you publish the matching public key in DNS, at an address like selector._domainkey.yoursite.com. The receiving server checks the signature, which proves the message came from someone holding your key and wasn’t changed on the way.
You don’t write DKIM records by hand. Your email provider or sending service generates them, and you copy them into DNS exactly as given.
DMARC: the policy that ties them together
SPF and DKIM don’t check the address people actually see in the From line. DMARC does. It requires at least one of them to pass and match the From domain, and tells receiving servers what to do with mail that fails.
_dmarc.yoursite.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yoursite.com"p=noneonly monitors. Reports about who’s sending as you arrive at theruaaddress.p=quarantinesends failing mail to spam.p=rejectrefuses it outright.
Start with p=none, read the reports for a few weeks to find every service that sends as you, fix them, then tighten the policy. The reports are XML files, so use a free DMARC report reader. Jumping straight to p=reject is a reliable way to block your own invoices.
Fixing your website’s email
Once the records exist, the website has to send through a service they cover:
- Choose a sending service. Your email provider’s SMTP server works, or a transactional email service such as Amazon SES, Postmark, Resend or Mailgun. Transactional services are built for this and keep delivery logs, so you can see what was sent and what bounced.
- Connect WordPress to it with an SMTP plugin or the service’s own plugin, so WordPress stops sending through the web server.
- Send from your own domain. Never set the From address to the visitor’s email. Put their address in Reply-To instead, so pressing Reply still reaches them.
- Consider a subdomain such as
mail.yoursite.comfor website email. It keeps the website’s sending reputation separate from the mailboxes your team uses every day. - Test it. Send a form to a Gmail address, open the message, and choose Show original. You want to see SPF, DKIM and DMARC all marked PASS.
The chat on this website works the same way: messages are sent from our own verified subdomain, with the visitor’s address as the reply-to.
The contact form problem nobody sees
The most common cause we find is a form set up to send “from” the visitor’s own address. It seems to work when you test it with your own email. But when a customer with a Yahoo or AOL address uses it, your server is sending mail that claims to be from Yahoo. Those providers publish strict DMARC policies, so the message is refused before it reaches your inbox, and nobody ever knows.
A check you can do today
Look up your domain with any DNS lookup tool and answer three questions:
- Is there exactly one SPF record, and does it include every service that sends as you?
- Is there a DKIM record for each of those services?
- Is there a DMARC record at all?
If any answer is no, some of your email is probably being filtered already.
Getting DNS and email authentication right is part of our server and hosting management, and forms that stopped sending are a regular support job.