Emails

The email object in a form’s config controls what gets sent when a submission arrives. There are two channels: a notification to you, and a confirmation back to the person who submitted.

"email": {
  "from": { "email": "[email protected]", "name": "Example Contact" },
  "notification": {
    "enabled": true,
    "to": ["[email protected]"],
    "subject": "New enquiry from {name}"
  },
  "confirmation": {
    "enabled": true,
    "toField": "email",
    "subject": "Thanks for contacting us"
  }
}

Notification

The email that tells you a submission came in.

• enabled — turn it on with true.
• to — an array of recipient addresses. Required when the notification is enabled.
• cc and bcc — optional arrays of extra recipients.
• subject and body — optional. If you leave them empty, a translated default is used.

Recipients must be plain, fixed email addresses. You cannot use a field value like {email} as a recipient. That would turn your form into an open relay for spammers. The only supported way to email the person who submitted is the confirmation channel below.

Confirmation (autoresponder)

The email sent back to the visitor, confirming you received their message.

• enabled — turn it on with true.
• toField — the name of the field that holds the visitor’s email address, for example "email". That field should have the email validation rule; the editor warns if it does not.
• bcc — optional array, if you want a blind copy of every confirmation.
• subject and body — optional, same as the notification.

Subjects and bodies

If you write nothing, both channels use a clear default subject and body in the site’s language. Leaving them empty is often the best choice, because the copy then follows the site’s language automatically.

When you do write a subject or body, you can drop in values from the submission using curly braces:

Placeholder	Becomes
{fieldname}	The value of that field, for example {name} or {email}
{id}	The submission’s ID
{form_id}	The form’s ID
{submission_url}	A link to the submission in the admin

A placeholder that does not match anything is replaced with “(not provided)”, never left as raw {text}.

Whatever you write in the body, OctaForms also appends a tidy summary of all the submitted fields below it, so you never have to list every field by hand. Long textarea values are laid out as readable blocks rather than crammed into a table.

HTML layout (developer)

Developer

The email is wrapped in a layout you can override per theme by adding an HTML file at <theme>/octa-forms/email/layout-notification.html or layout-confirmation.html, with a {{content}} placeholder where the message goes.

Sender address

The from object sets who the email appears to come from. Leave it empty to use your site’s default sender.

Set the sender to an address on your own domain. If you send from a domain you do not control, or one without proper mail setup, your emails will likely land in spam. The editor warns when the sender domain is not your site.

Never put the visitor’s address in from. The correct place for “replies go to the visitor” is handled by the confirmation channel and Reply-To, not by faking the sender.

Attachments

If your form has a file field, the uploaded file is attached to your notification email under its original name. You get the actual file in your inbox.

The confirmation email deliberately does not send the file back to the visitor. They uploaded it, so they already have it, and echoing files back is a spam and abuse risk.

Webhooks never receive the file’s bytes, only its name, type and size. See Webhooks.

“Sent” is not “delivered”

This trips people up, so it is worth stating plainly. When WordPress reports an email as sent, it only means your server’s mail transport accepted it. It says nothing about whether it reached the inbox.

For reliable delivery, use an SMTP plugin and set up SPF and DKIM for your sending domain. See Email deliverability.