N1 Nex1on

Mail on a Nex1on site: how to set up sending and check it, and why emails do not arrive

Three ways to send, SMTP setup, a one-press check, the “Sent emails” log with the reason for a failure, and what to do so that mail does not land in spam.

“Emails do not arrive” is the most common trouble of the owner of a new site. A password reset, address confirmation, two-step sign-in, notifications about requests, the newsletter: all of it is email. Until mail is set up, part of the site silently does not work. Below: how to set up sending, how to check it with one press, and how to tell from the log where the talk with the mail server broke off.

What rests on email #

  • a password reset and confirming an email address;
  • two-step sign-in and emails about a sign-in from a new browser;
  • inviting people to the site;
  • notices to the owner: messages, requests, reports of trouble on the site;
  • the newsletter to subscribers.
Without working mail there is nothing to restore a password with: nobody can send the link. That is why mail is worth setting up before the launch, not after the first complaint.

Three ways to send #

Open “Settings → Mail”. The first field, “Transport”, chooses one of three options:
  • Do not send, log only. Messages are put as files into the storage/mail folder and reach nobody. Good for a check and for a test site. While this one is chosen, the site sends nothing to anyone. Beware: the files are whole emails, with working password-reset links and sign-in codes, so do not leave this transport on a production site; files older than the term (“Keep “to a file” emails, days”, 7 by default) are deleted automatically.
  • The server's mail() function. The message is handed to the hosting itself. On most hostings it works with no setup, but mail from a shared server often lands in spam.
  • SMTP server. The site signs in to a mailbox itself and sends through it. The most reliable: if you have a choice, take it.

Step 1. Set up SMTP #

The SMTP details are taken from the hosting panel or from the mail provider: there you create a mailbox (for example no-reply@yoursite.com) and get the server name. Enter them under “Settings → Mail”:
  • SMTP host: the address of the mail server, for example smtp.yoursite.com.
  • Port and encryption go as a pair: port 587 with “tls” (switching to encryption by STARTTLS) or port 465 with “ssl” (encryption from the first byte). “No encryption” (port 25) is fit only for an internal network.
  • Username and password: the mailbox details; most often the username is the full mailbox address. A saved password is not shown again: leaving the field empty keeps it as it is.
  • Sender address and name: better on your own domain, because mail from a foreign address goes to spam.
  • Verify TLS certificate: keep it enabled on a production site. Disable only for a trusted local test server: the mailbox password travels over SMTP.
A separate switch, “Send in the background”, is about speed: the message goes out after the page has been handed to the visitor, so nobody waits for the conversation with the mail server, which takes seconds.

Step 2. Check sending #

Save first, then check: the check uses the settings that are already saved. In the “Mail check” block enter an address and press “Send a test”: one ordinary message goes out. It arrived: mail works (look in “Spam” too). It did not: open “Site health”, where you can see where the talk with the mail server broke off. The check changes nothing but this message.

Step 3. Read the “Sent emails” log #

The log shows what went out and what did not, with the reason: to whom, when, the subject, the method and the result “Sent” or “Not sent”. Message bodies and the links in them are never stored, and records are kept for the number of days set by “Keep the mail log, days” (zero means no log). A message that did not go can be sent again with “Retry from the queue”. The reason is written in general words: the method, the server's three-digit reply and the class of trouble. Here is what they mean:
  • auth failed (for example “smtp 535 auth failed”): the server did not accept the username or password. Check them, and check whether the mailbox needs a separate “app password”.
  • connection failed or timeout: the site could not reach the server. Check the address and the port; hostings often block outgoing connections on some ports, so try another pair of port and encryption or ask support.
  • tls error: the encryption or the certificate did not match. Check the pair of port and encryption (587 with “tls”, 465 with “ssl”) and the server name; do not switch the certificate check off on a production site.
  • recipient rejected: the server refused the recipient: the address does not exist or is closed.
  • sender rejected: the server did not accept the sender address; most often it must belong to this mailbox or to your domain.

Step 4. So that mail does not land in spam #

A delivered message does not yet mean it ends up in the inbox. Three things settle almost everything:
  1. Send from an address on your own domain, not a foreign one.
  2. In the domain's DNS and at the mail provider set up SPF, DKIM and DMARC: they tell receiving servers that mail from your domain is genuine. Your mail provider will tell you where exactly they are turned on.
  3. Do not add outside links and addresses to the text of the “protected” emails (password reset, address confirmation, sign-in code): that turns the message into a way to deceive your people.

Your own email texts #

The emails the site sends on its own are edited under “Email templates”: for each one you can write a subject and a text of your own in any language of the site, and empty means the built-in text goes out. Substitutions in curly braces (the site name, the person's name, the link address and others; the list is shown on the email's page) are replaced with real values when sending. Emails with links and sign-in codes are protected: a changed text of such an email is a way to deceive your people, so saving asks for your password, and the owners get a notice.

What to check #

  • A transport is chosen and it is not “log only”: in the storage/mail folder emails lie whole, with working links and sign-in codes.
  • The test message reached the inbox, not “Spam”.
  • The sender address is on your domain.
  • SPF, DKIM and DMARC are set up in DNS.
  • A password-reset email reached a test account and its link works.
  • The “Sent emails” log has no red “Not sent” for the last days.

If something goes wrong #

  • The check passed but people get no emails. Open the log: an email to people may fail for another reason (the recipient's address is closed). If the log is empty, check the queue under “System health”: with background sending, emails go through the queue.
  • The password stopped working. It may have been changed at the mail provider; enter the new one under “Settings → Mail”.
  • Emails go out but into spam. Go back to step 4: an address on your own domain, SPF, DKIM, DMARC.
  • After moving to another hosting mail is silent. Sending is switched to “to a file” when restoring from a copy: set it up again.
  • You want to see what is sent at all. On a test site choose “do not send, log only”: the emails lie as files in storage/mail.

What next #

Once mail works, turn on two-step sign-in for the owner and set up alerts about trouble on the site: email is the channel through which the site itself tells you that something is wrong with it.
Share: Telegram WhatsApp

Read also

Discussion

Comments

No discussion yet

No one has commented yet. Be the first.

Report this post