Transactional Emails

<div class="prose prose-hyva max-w-none"><p>How to load a default template as a starting point, work with variables, and activate your customized version in the right store view.</p><p>Every system email (order confirmation, invoice, shipment, credit memo, password reset, newsletter) is based on editable templates under <em>Marketing &gt; Communications &gt; Email Templates</em>.</p> <h3>Creating a new template</h3> <p>Click <strong>Add New Template</strong>. In the <strong>Load default template</strong> dropdown, pick the default template you want to customize (e.g. "Order Confirmation Template" for new orders) and click <strong>Load Template</strong> – the default template's HTML source appears in the editor as your starting point instead of you having to build one from scratch.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/loaddefault11kategorie.png}}" alt="load" /> <h3>Template editor</h3> <p>The editor has two levels: the visible HTML code in the large text field, plus two fields above it, <strong>Template Name</strong> (an internal name, shown only in the backend) and <strong>Template Subject</strong> (the actual subject line, which also supports variables). The <strong>Insert Variable</strong> button inserts dynamic placeholders at the cursor position, e.g. <code>{{var order.increment_id}}</code> for the order number or <code>{{var customer.name}}</code> for the customer's name – which variables are available depends on the underlying default template.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/template11kategorie.png}}" alt="template" /> <h3>Preview before saving</h3> <p>The <strong>Preview Template</strong> button renders the email with sample data in a new tab – so you can spot layout issues (missing closing tags, broken tables) immediately, without triggering a test order first.</p> <h3>Activating your custom template</h3> <p>A saved custom template only takes effect once you select it in the corresponding dropdown under <em>Stores &gt; Configuration</em> in the relevant section (e.g. <em>Sales &gt; Sales Emails</em> for order emails, <em>Customers &gt; Customer Configuration</em> for account emails) – separately per <strong>store view</strong> if you sell in multiple languages. Skip this step and the new template just sits there saved; the default template keeps getting sent.</p> <p><strong>Practical tip:</strong> never edit the core default template files directly in the filesystem – a Magento update will overwrite them. Going through <em>Email Templates</em> in the backend survives updates untouched.</p></div>

<div class="prose prose-hyva max-w-none"><p>Which email gets sent automatically at which order step, and where to configure each one individually.</p><p>Along the order lifecycle, Magento sends four independent email types, each with its own configuration section under <em>Stores &gt; Configuration &gt; Sales &gt; Sales Emails</em>.</p> <h3>Order confirmation</h3> <p>Triggered as soon as an order is successfully placed (status changes to "pending" or "processing"). Group <strong>Order</strong>: <strong>Enabled</strong>, <strong>New Order Confirmation Email Sender</strong> (which sender identity, see the next subchapter), <strong>New Order Confirmation Template</strong> (for registered customers), and a separate <strong>New Order Confirmation Template for Guest</strong> (for guest orders, often including a note about creating an account).</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/order11kategorie.png}}" alt="order" /> <h3>Invoice</h3> <p>Sent when an invoice is created in the backend under <em>Sales &gt; Orders</em> (see the "Creating Invoices" chapter) – not automatically with every order, only at the actual invoicing step. Group <strong>Invoice</strong> with the same three fields (sender, registered template, guest template).</p> <h3>Shipment confirmation</h3> <p>Triggered when a shipment is created (see the "Shipping and Delivery" chapter), usually including the tracking number if one was entered. Group <strong>Shipment</strong>, with equivalent fields.</p> <h3>Credit memo</h3> <p>Sent when a credit memo is created (see the "Credit Memos and Refunds" chapter). Group <strong>Credit Memo</strong>, with equivalent fields.</p> <h3>Sending yourself a copy</h3> <p>Each of the four groups also offers <strong>Send Order/Invoice/Shipment/Credit Memo Email Copy To</strong> (one or more comma-separated internal email addresses) and <strong>Send Email Copy Method</strong> (Bcc or a separate copy email). This way your fulfillment team can automatically get a copy of every order confirmation, for example, without having to watch the backend.</p> <h3>Asynchronous sending</h3> <p>The <strong>Asynchronous sending</strong> option (group <strong>Email Sending Options</strong> at the very top of the page) moves the actual email delivery into a cron job instead of triggering it synchronously in the same request as the order – recommended if your mail server is slow or occasionally unreachable, so an email timeout can never block a successful checkout.</p></div>

<div class="prose prose-hyva max-w-none"><p>Where the sender name and address for each email identity live, and why actual delivery depends on your server configuration.</p><p>Magento strictly separates the <strong>sender identity</strong> (the name + email address shown in the "From" field) from the technical delivery path of the email.</p> <h3>Store Email Addresses</h3> <p>Under <em>Stores &gt; Configuration &gt; General &gt; Store Email Addresses</em> you maintain up to five named identities: <strong>General Contact</strong>, <strong>Sales Representative</strong>, <strong>Customer Support</strong>, plus two freely nameable <strong>Custom Email 2</strong> and <strong>Custom Email 3</strong>. Each consists of a name field and an email address field.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/storeemail11kategorie.png}}" alt="store" /> <h3>Assigning identities to email types</h3> <p>In the respective configuration sections (Sales Emails, Customer Configuration, Newsletter) you pick via a dropdown which of these five identities is used as the sender for that email type – e.g. "Sales Representative" for order confirmations, "Customer Support" for password reset emails. That way customers can tell at a glance from the sender name what an email is about, without reading the subject line.</p> <h3>Store view scoping</h3> <p>All five identities are configurable per store view – a bilingual store can use "Kundenservice" in its German store and "Customer Support" in its English store, each with a matching sender address, without needing separate templates.</p> <h3>Actual delivery: sender address isn't the same as deliverability</h3> <p>Important to understand: this configuration only determines what shows up in the email's "From" field – not whether the email actually gets delivered. Magento itself doesn't run its own mail server; it hands emails off to whatever PHP <code>mail()</code> function or configured SMTP transport your hosting/server operator has set up. For receiving mail servers (Gmail, GMX, Outlook) not to flag the email as spam, the actually sending domain needs valid <strong>SPF</strong> and ideally <strong>DKIM</strong> records – simply changing the sender address in the backend without matching DNS records can mean emails are "sent" but never delivered. If deliverability problems persist, switching to a dedicated transactional email service instead of the server's own mail sending is worth considering.</p></div>