Sending Email from Your Own Domain

This guide explains which address your instance sends email from, how to send from an address at your own domain, and how to check that email arrives. It is for developers who write email templates in app/emails/.

The Default Sender

A production instance can always send email from no-reply@insites.site. You do not need to set anything up. Use it while you build, and for any instance without a domain of its own.

Each production instance has its own email sending account. Its sending record is its own, so a complaint about email from one instance does not stop other instances from emailing that person.

The recipient sees the name you put before the address, such as My Site <no-reply@insites.site>. Replies go to the address you set as reply_to, because no-reply@insites.site has no inbox.

Sending from Your Own Domain

To send from an address such as hello@acme.com, the domain must be connected to the instance with email notifications on, and its email records must be found. Connecting a domain does not change the From address of any email by itself. You choose the address.

1. Connect the domain to the production instance in the Console. See Instance Domains.
2. Make sure the email notification records are published.
   • If Insites hosts your DNS, Insites publishes them for you.
   • If you keep your own DNS provider, add the email records there. Email notifications is on by default in the wizard. If you turned it off, turn it on later on the domain page.
3. Wait until the domain shows Email notifications live on the Domains tab. Insites checks the records for you.
4. Add a sender at the domain on the Email Senders card, for example hello@acme.com. See Email Senders.
5. Use that address as the From address in your email templates.

The Email Records

On your own DNS provider, the email group in the Connect Domain wizard lists the records to add. There are three CNAME records. They let the instance’s sending account send as your domain, and they sign each email so receiving servers trust it. The wizard shows each record’s host and value, with copy buttons.

If the domain has no DMARC record yet, the list also has a TXT record at _dmarc with the value v=DMARC1; p=none;. It is marked Recommended. A policy of none never blocks your mail. If the domain already has a DMARC record, the list does not add a second one, because receiving servers ignore a domain with two.

The records do not change where you receive email. The wizard never lists MX records.

If the Records Go Missing

If you keep your own DNS provider, Insites checks the email records every day.

• If a check cannot find them, the domain shows records missing and a number of days left. Email still sends from the domain for three days. Add the records again in that time.
• If the records are still missing after three daily checks, the domain’s senders in the Console send from no-reply@insites.site instead, with the same name. A From address you type into a template is not changed, so read it from INSITES_EMAIL_SENDERS (below). Add the records again, and email moves back to the domain.
• If the domain’s DMARC policy is quarantine or reject, there is no grace period. The domain’s senders move to no-reply@insites.site at the first check that cannot find the records.

The instance address and the SSL certificate are not affected by the email records.

The From Address in Email Templates

Set the From address with from in the front matter of the email template. Use one of these:

• no-reply@insites.site, or
• an address at a domain connected to this instance whose email notifications are live.

Do not use an address at a domain the instance cannot send as, such as a personal email address or a domain that is not connected. The email is refused and does not arrive.

app/emails/order_confirmation.liquid

---
to: '{{ data.to }}'
from: '{{ data.from }}'
reply_to: '{{ data.reply_to }}'
subject: Your order is confirmed
---
<p>Thank you for your order.</p>

Reading the Senders You Set in the Console

Insites copies the instance’s senders from the Console to a constant on the instance named INSITES_EMAIL_SENDERS. It is a JSON value like this:

{
  'default': 'no-reply',
  'senders': {
    'no-reply': { 'from': 'no-reply@insites.site', 'name': 'Acme' }
  }
}

The real value uses JSON double quotes. default is the id of the default sender. Each sender has a from address and a name. If a sender’s domain cannot send right now, its from is no-reply@insites.site, so the address in the constant is always one the instance can send from.

Read it with context.constants and pass the address to your email. This example uses the default sender, and falls back to no-reply@insites.site if the constant is not there:

{%- liquid
  assign from = 'no-reply@insites.site'
  assign raw = context.constants.INSITES_EMAIL_SENDERS
  if raw != blank
    assign senders = raw | parse_json
    assign sender = senders.senders[senders.default]
    if sender.from != blank
      assign from = sender.from
      if sender.name != blank
        assign from = sender.name | append: ' <' | append: sender.from | append: '>'
      endif
    endif
  endif

  assign mail = {}
  assign mail.to = email
  assign mail.from = from
  assign mail.reply_to = 'orders@acme.com'
-%}
{%- graphql sent, tpl: 'order_confirmation', d: mail -%}
mutation ($tpl: String!, $d: HashObject) {
  email_send(template: { name: $tpl }, data: $d) { is_scheduled_to_send }
}
{%- endgraphql -%}

Note: Do not set INSITES_EMAIL_SENDERS yourself. Insites writes it, and puts it back if it is changed. Change senders in the Console instead.

Note: A comma in a sender name can split the From line into two addresses. Keep sender names free of commas, or use the address on its own.

Staging Instances

• A staging instance cannot connect a domain, so it cannot send from your own domain. It has no Email Senders card.
• A staging instance sends email from no-reply@staging.insites.site.
• A staging instance does not send email to real people. Each email goes only to the test email recipients set in your instance settings, with the intended recipient shown in the subject line. Until you set test recipients, you receive nothing. See Staging vs. Production.

Test your From address on the production instance before launch.

Checking Delivery

• Check the answer. is_scheduled_to_send: true means the email was queued. It does not prove the email arrived.
• Check the From address. It must be no-reply@insites.site or an address at a domain whose email notifications are live. Any other address is refused.
• Check the domain. If you keep your own DNS provider, open the domain page in the Console. The Email notifications group shows each record as Found or Not found. Select Check now to check again.
• Check the senders. On the Email Senders card, a domain that cannot send says so on its heading, and its senders send from no-reply@insites.site.
• On staging, check the test recipients. Real recipients never get staging email.
• Check the spam folder of a test inbox, and send to more than one email provider.

Related

• Instance Domains
• Email Senders
• Creating an Email Notification
• Pre-Launch Checklist