Password resets, order confirmations, contact form notifications. This mail matters more than newsletters, somebody is waiting for it, and sent directly from a web server it is the least reliable mail there is.
Why direct sending fails
Mail sent by a website using the server's built-in mail function leaves from an address shared with every other account on that server, carrying whatever reputation those accounts have earned. It is frequently sent without any authentication. And it produces no record beyond a line in the server's log.
The result is the failure that gives no warning: the message is accepted and then filed as spam. Your log says delivered. The recipient never saw it. Nothing bounces, so nothing tells you.
A user who did not receive a password reset assumes your site is broken, and contacts support, or does not.
What a relay changes
A transactional mail service accepts your message and sends it from addresses maintained specifically for the purpose, signed, with reputation actively managed.
More usefully, it reports what happened to each individual message: delivered, bounced, rejected, or accepted. That converts "some of our email does not arrive" from a guess into a list you can read.
Most such services have a free allowance that covers a small site entirely.
Connecting the site to it
Two routes. Authenticated SMTP is universal and works with any application. An API is faster and usually gives better reporting, and requires a library.
SMTP is the right default:
Host: smtp.provider.com Port: 587 Security: STARTTLS Username: (from the provider) Password: (from the provider)
Port 587 with STARTTLS is the modern arrangement. Port 465 is also common. Port 25 is frequently blocked outbound and should not be used from a website.
In WordPress this is a plugin's configuration screen. There is more on the same problem from the symptom end in fixing WordPress email not sending.
Authorise the relay in DNS
This is the step that gets missed, and skipping it makes delivery worse rather than better.
Your SPF record lists who may send for the domain. If the relay is not on it, mail arriving from the relay claiming to be from your domain is unauthorised, which is exactly what a forgery looks like.
example.com. IN TXT "v=spf1 include:_spf.provider.com include:_spf.yourhost.com -all"
One SPF record only. Two records for the same domain is an error and the usual outcome is that neither is honoured.
The relay will also give you DKIM records to add. Add them. The signature is what survives forwarding, and without it a forwarded message loses its authorisation. Understanding SPF, DKIM and DMARC walks through both.
Keep the credentials out of the code
SMTP credentials can send mail as your domain. Treated carelessly they end up in a repository, or in a theme file that is publicly readable.
Put them in configuration outside the web root, or in the application's environment. And use a key created for this application alone, so it can be revoked without affecting anything else.
Use a sender address that exists
Sending from [email protected] when no such mailbox exists causes two problems: sender verification may refuse it, and replies vanish.
People reply to transactional mail constantly, whatever the address says. Use an address that receives, and read it. There is more on pointing it at someone without creating a mailbox in setting up email forwarders.
Keep the mailboxes separate from this
A relay handles mail your site sends. It is unrelated to where your mailboxes live, and the two are configured independently.
A site can send through a relay while its mailboxes are hosted anywhere, splitting DNS between website and email providers goes into the arrangement, including the local-delivery trap that makes your own form's mail land in an unread mailbox.
Test the ones that matter
After setting it up, actually run a password reset, place a test order, and submit the contact form, to an address at a large mail provider rather than to your own domain.
Then read the relay's log and confirm each message was delivered rather than merely accepted. That distinction is the entire reason for doing this.
Keep the relay from becoming a single point
Routing all application mail through one service means an outage there stops password resets and order confirmations.
Most libraries support a fallback: a second relay, or the server's own mail as a last resort. Configure one, and make the failure visible rather than silent, mail that quietly falls back to an unauthenticated path is mail that will be filtered.
The alternative, and frequently the better one, is to queue rather than fail. A message that cannot be sent now should be retried in a few minutes rather than dropped, and the application should record that it is pending. Why scheduled tasks do not run goes into making that retry actually happen.
Separate the streams from the start
Transactional mail and marketing mail should not share a relay identity, even at low volume.
Password resets have very high engagement and almost no complaints. Marketing has the opposite profile. Sharing an identity means the second gradually degrades the deliverability of the first, and the mail people actually need is the one that suffers.
Most services support separate sending identities or subdomains for this. Setting it up at the beginning costs nothing; separating them later means warming a new identity from scratch. Warming up a new sending domain sets out that work.
Watch the reporting rather than assuming
The reason to use a relay at all is that it tells you what happened. That only helps if somebody looks.
Three figures are worth checking monthly: the delivery rate, the bounce rate, and whether any recipients marked messages as spam.
A bounce rate that has climbed usually means addresses in the application's database that no longer exist. A user list that is not being cleaned. Complaints on transactional mail usually mean something is being sent that recipients did not expect, which is a product question rather than a delivery one.
Both are visible in the relay's dashboard and invisible from the application. Understanding bounces and delivery codes deals with acting on them.
Test what a failure looks like
Before relying on it, break it deliberately: use wrong credentials and submit a form.
What you want to know is whether anything reports the failure. A site that silently discards mail when the relay refuses it is a site where the first indication is a customer saying they never received a reset, weeks later, with no record.
The correct behaviour is that the failure is logged and, for anything important, retried. Confirming that once is the difference between a relay you have configured and a relay you can rely on.