Give the website's emails your business name and a real mailbox, send them through your own mail server with a login, and test every message the site sends, from password resets to order notices, in several inboxes.

A password reset from a stranger

A customer asks the website for a new password, waits, and asks again. Nothing arrives, so she phones the office, mildly annoyed.

Both emails are in her spam folder. The sender's name is WordPress, at an address on your domain that nobody in the office has ever seen.

Order notices and form confirmations often go the same way. The site sends them faithfully, and customers either never see them or do not recognise who sent them.

Where the name WordPress comes from

When nobody has told it otherwise, WordPress signs each email with the name WordPress and an address made from the word wordpress and your domain.

In most offices no mailbox exists at that address. A customer who replies to a receipt or a password email gets a bounce, or silence.

Each plugin that sends mail, for forms, a shop or memberships, may have its own sender settings too, so one site can send under three or four names.

What the site sends without being asked

Few owners know the full list. A WordPress site with a form and a shop typically sends most of these:

The first four reach customers, and the first matters most. A customer who cannot reset a password cannot get back in.

Why receiving servers doubt it

A receiving mail server checks whether the machine that delivered a message may send for the domain in the sender's address. The domain's owner publishes that list in a record called SPF.

Many business domains list only the office mail service. The web server is a different machine, missing from the list, so its messages fail the check.

Mail from the web server often carries a hidden return address at the hosting company's machine as well. Gmail, for one, shows that machine's name beside the sender, another sign that something does not match.

Failing the check does not always mean outright rejection. Each receiving server weighs the evidence, and an unfamiliar sender that fails it is often filed as spam.

A worked example

A scout group with about sixty young members runs a WordPress site for parents: a members area with logins, sign-up forms for camps and outings, and fees paid online.

Each spring, parents told the leaders their camp forms had gone nowhere. The confirmations were being sent, from a sender called WordPress, and many sat in spam folders.

The leader who looks after the site found three senders in use: WordPress for logins, a generic name for camp forms, and an old address for fee receipts.

All three now carry the group's name and one real address, which two leaders read. The site sends through that mailbox, logged in with its password, instead of straight from the web server.

Parents see a name they know, replies reach a leader, and the mail passes the receiving checks because it leaves from the server the domain lists.

Setting the sender name and address

Customers should see a name they know in the sender line: the business, not the software. Behind it should be a real mailbox that someone reads.

An address such as orders@ or office@ at your domain works well. An address that says no reply discourages the replies that often carry the most useful questions.

WordPress sets its default in code, so changing it takes a small addition to the site or a setting in a plugin. Form and shop plugins each have their own field as well.

Sending through the business's own mail

A sensible name fixes recognition but not the checks. For those, the site should send the way a staff member does: logged in to the business's mail server.

That is authenticated sending. The message leaves from the server your domain already lists, so it passes the same checks as the office's own email.

Where the site must send straight from the web server, the alternative is adding that server to the domain's SPF record. A domain may have only one such record, and a second one breaks both.

Both changes touch the domain and the mail settings together, which is why they belong with whoever looks after the site and the domain.

Form notices that pretend to be the visitor

Some forms send the office notice as if it came from the visitor, so that pressing reply reaches them. The visitor's own domain never listed your web server, so these fail outright.

The better setting sends the notice from your own address and fills the reply-to field with whatever the visitor typed. Replies still reach the visitor, and the check passes.

Testing every message the site sends

List every message, then make each one happen: reset a password, create an account, send a form, place a test order and cancel it.

Send them to an office address and to accounts at two or three of the large free email services, since each judges mail its own way.

For each, check the sender name, the address, the folder it landed in, and whether a reply reaches a person. The message details show whether the SPF check passed.

Repeat the test after updating the theme or plugins, because an update can quietly restore a default.

The counter-case

A simple site with no logins and no shop, whose only form notifies the office, sends very little, and only to people who already know the business.

The office's own notices can still land in spam, though, and a missed enquiry costs more than the fix.

For any site that writes to customers, the sender is part of the service. A receipt nobody recognises is a receipt nobody trusts.

Making the site's mail your own

  1. List every message the site can send.
  2. Choose one name customers will recognise.
  3. Use a real address that someone reads.
  4. Send through your mail server with a login.
  5. Put visitors in reply-to, never in the sender field.
  6. Test each message in several kinds of inbox.
  7. Test again after every update.

Step four changes how receiving servers see the site. A friendly name on mail that fails the check is still mail that fails the check.

Email that sends from the office but not on the road explains authenticated sending on the submission port, and why mail sent that way passes the checks made against your domain.

Frequently asked questions

Why do my website's emails say they are from WordPress?

WordPress signs its messages with its own name and an address at your domain unless someone sets a sender. Many sites never had one set when they were built.

Does the wordpress address at my domain exist?

Usually not. Nobody created that mailbox, so replies to receipts or password emails bounce or disappear. Use an address that someone in the office actually reads.

Why do these emails land in spam?

Receiving servers check whether the sending machine may send for your domain. A web server missing from the domain's SPF record fails that check, and its mail looks doubtful.

What is authenticated sending?

The site logs in to your business's mail server with a username and password, as a staff member's mail program does, so its messages leave from a server your domain lists.

Should form notices come from the visitor?

No. Send them from your own address, with the reply-to field set to the visitor's. Pressing reply still reaches the visitor, and the message passes the receiving checks.

How do I test the website's emails?

Trigger each one: a password reset, a new account, a form, a test order. Send them to several kinds of inbox and check the sender, the folder and the replies.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Customers missing emails from your website?

Name the messages your customers say they never received, and we will trace each one and set it up to come from you.

Start a Conversation