Storefront email

Grade school

Your store needs a helper that carries its emails to your customers. That helper is called a sending service.

The best choice is for you to have your own sending service account, like having your own mailbox key. If you want, YPB can help and do it for you instead.

High school

There are two ways to run your storefront’s email. We recommend the first.

• You own it (recommended). You open an account with a sending service such as SendGrid or Brevo, verify your domain, create the account’s key yourself and enter it into your site. You control it and pay the provider directly if you go beyond their free tier.
• YPB helps (optional courtesy). YPB sets up your branded email and DNS with you and sends your storefront email through credentials YPB manages. You don’t get a login to that sending account.

Either way, your inbox stays with your mailbox provider, and your sender name, address and branding are yours.

College

Ownership decides who controls the sending account, its credentials, its reputation history and its bill.

• Customer-owned (default): you hold the provider relationship. You authenticate your domain in your own account, create a scoped key and install it in your storefront’s mail plugin yourself, or have your own administrator do it. Provider plan charges are yours.
• YPB-assisted courtesy: for organization storefront owners who prefer not to run it, YPB configures branded sending and DNS with you and sends through YPB-managed credentials. It currently has no separate charge; YPB may charge for it in future and will tell you before any change takes effect.

Postgraduate

The model allocates control, liability and portability. A customer-owned account keeps domain reputation, suppression lists, logs and credentials within your organization, so changing platforms later doesn’t strand your sending history. The YPB-assisted courtesy trades that control for convenience: YPB operates the credential lifecycle and provider relationship on your behalf, while the brand identity, domain and DNS authority remain yours.

The courtesy currently carries no separate fee. It isn’t a permanent entitlement: YPB reserves the right to charge in future and will notify customers before a change takes effect. It’s also distinct from what your membership currently includes (see Service & support).

Developer

WooCommerce mail goes through WordPress wp_mail(); a mailer plugin (typically WP Mail SMTP) replaces the default PHP transport with the provider’s API or SMTP. Customer-owned means the provider account, domain-authentication objects and the credential stored in the plugin are created and rotated by the customer. The credential is entered directly into WordPress (or supplied as wp-config.php constants), never through a ticket.

Under the YPB-assisted courtesy, YPB installs and configures the mailer with a YPB-managed, send-only credential. Internal key naming, custody and rotation details aren’t published.

Grade school

Your store emails should come from an address with your store’s own name in it, like hello@brand.example, not a free address like @gmail.com.

It’s like wearing your team’s uniform: customers know it’s really you.

High school

Your storefront’s From and Reply-To addresses must be on your business domain, for example orders@brand.example and support@brand.example. The same applies to whoever contacts YPB for member support.

Free personal addresses (@gmail.com, @outlook.com, @hotmail.com, @yahoo.com and similar) can’t be used for these. Google Workspace or Microsoft 365 set up on your own domain is perfectly fine.

Don’t have one yet? Sign up for Google Workspace or Microsoft 365 using your domain, or check whether your domain or hosting company offers mailboxes. Then add the mail records they give you to your DNS.

College

Two reasons: identity and deliverability. A sending service can only authenticate mail for a domain you control; you can’t publish DKIM or DMARC records for gmail.com. Mailbox providers such as Gmail and Yahoo reject or distrust mail that claims to be from their consumer domains but is sent through someone else’s servers.

For support, a business address lets YPB recognise the request as coming from your organization. It helps with identification, but it doesn’t grant access to your account on its own: signed-in support also requires your verified organization membership.

This applies to your organization’s identities only. Shoppers who receive order emails can use any address.

Postgraduate

The policy ties sender identity to a domain whose DNS the organization controls. DMARC evaluates alignment between the visible From domain and the domains authenticated by SPF or DKIM. Consumer webmail domains publish strict DMARC policies, so a storefront sending “as” them through a third-party service will fail alignment and may be rejected.

For support intake, a branded domain is a necessary signal, not a sufficient authorization: tenant access is decided by a verified identity mapped to the organization, never inferred from an email domain alone.

Developer

Required: From and Reply-To mailboxes on a customer-controlled domain with working MX. Rejected for organization identities: free consumer domains such as gmail.com, googlemail.com, outlook.com, hotmail.com, live.com, yahoo.com, icloud.com and aol.com. Accepted: Google Workspace or Microsoft 365 tenants on the custom domain.

Support intake checks the address server-side and still requires a verified identity mapped to the organization; the domain is never used to infer membership. Public help pages stay open to everyone.

Grade school

When someone buys something, your store writes an email. A plugin hands that email to your sending service. The sending service delivers it to the customer.

High school

YPB storefronts run on WordPress with WooCommerce. WooCommerce writes the email (order received, order completed, password reset and so on) and WordPress sends it. On its own, WordPress sends mail in a way many inboxes treat as suspicious, so a mail plugin — usually WP Mail SMTP — hands each message to a proper sending service instead.

This is transactional email: messages triggered by what a customer does. Newsletters and marketing campaigns are separate.

College

WooCommerce builds each message from its email templates and your settings, then calls WordPress’s mail function. WP Mail SMTP intercepts that call and delivers through the mailer you choose: a provider’s web API (SendGrid, Brevo, Mailgun and others) or an SMTP server. API mailers are generally preferred because they authenticate with a scoped key and give better error reporting.

Which mailers are available depends on the plugin’s edition and version — some require a paid WP Mail SMTP licence. WooCommerce itself doesn’t choose the provider.

Postgraduate

Transport and presentation are separate layers. WooCommerce controls templates, triggers and recipient logic; the mailer controls transport, authentication to the provider and the envelope sender. A transport change doesn’t alter templates, and a template change doesn’t affect deliverability. Each layer is verified independently: provider acceptance isn’t delivery, and delivery isn’t proof of correct branding or reply routing.

Developer

Flow: WooCommerce WC_Email → wp_mail() → pre_wp_mail/PHPMailer hooks → WP Mail SMTP mailer → provider API (for example POST https://api.sendgrid.com/v3/mail/send, which returns 202 Accepted) or SMTP submission on port 587 with STARTTLS. Check the site’s outbound HTTP policy (for example WP_HTTP_BLOCK_EXTERNAL) allows the provider’s exact API host; a blocked request never reaches the provider. See the WP Mail SMTP mailer guide.

Grade school

The sender is who the email says it’s from. Reply-To is where answers go. Your inbox is where you read them. The sending service only sends — it doesn’t have an inbox.

High school

From name

The name customers see, such as Brand Example.

From address

An address on your domain, such as orders@brand.example.

Reply-To

Where replies go, such as support@brand.example. Someone must read it.

Your inbox

Your mailbox provider (for example Google Workspace or Microsoft 365). It doesn’t move.

Your sending service doesn’t receive mail, so never point your domain’s MX records at it.

College

These are four independent settings. The From address is authenticated by your sending service’s DNS records. Reply-To is a header telling mail apps where replies should go; if it’s missing, replies go to the From address. Inbound mail is routed by your domain’s MX records to your mailbox provider, which the sending service never touches.

Postgraduate

Keep outbound transactional sending and inbound mailbox routing as separate trust paths. MX governs where mail for your domain is delivered; SPF/DKIM for the sending service govern whether outbound mail is accepted as yours. Changing one shouldn’t require touching the other. A Reply-To on a monitored alias preserves the customer relationship while the From address can be a dedicated sender such as orders@.

Developer

WooCommerce: woocommerce_email_from_name, woocommerce_email_from_address (and Reply-To options where your version supports them). WP Mail SMTP: From Email / Force From Email and From Name / Force From Name — forcing overrides plugin-supplied senders. Verify the received headers (From, Reply-To, Return-Path) on a real test message; a stock plugin test may omit Reply-To.

Grade school

There are many sending services. SendGrid and Brevo are two popular ones. Pick one, and follow its guide.

High school

WP Mail SMTP works with many services. We have step-by-step guides for SendGrid and Brevo, for sending through Google Workspace or Microsoft 365 on your own domain, a guide for any other SMTP service, and a full list of supported services with links to each one’s official setup page.

Each service uses its own key and its own DNS records. There is no single setting or record that works for all of them.

College

Choose on deliverability tooling, pricing at your volume, domain-authentication method, log retention and whether the WP Mail SMTP mailer is in the free edition. For example, Amazon SES, Microsoft 365/Outlook and Zoho need a paid WP Mail SMTP licence. See the provider catalogue.

Postgraduate

API-based providers give scoped credentials, per-message event data and domain authentication without editing your apex SPF (for example SendGrid’s automated security). Generic SMTP relies on a username/password and offers weaker error semantics. Consider portability: a customer-owned account keeps suppression lists and reputation with your brand.

Developer

Mailer IDs, auth types and licence requirements are in the catalogue. Prefer API mailers with least-privilege keys (SendGrid: Restricted Access → Mail Send; Brevo: a v3 API key, not its SMTP key). For protocol and payload detail, see the developer guide.

Grade school

You add a few special notes, called DNS records, to your domain. They prove the sending service is allowed to send for you. Each service gives you its own notes.

High school

Your sending service gives you DNS records to add — usually for DKIM (a signature) and sometimes SPF or a verification code. Copy them exactly from your own account. Records from another business or from this page won’t work.

Keep your existing mail records: don’t change your MX records, don’t add a second SPF record, and don’t weaken an existing DMARC policy. The authentication guide explains each record.

College

Records are generated per provider account and domain. SendGrid typically issues three CNAMEs (a return-path subdomain plus two DKIM selectors); Brevo issues a verification TXT and DKIM record(s) and may suggest DMARC. If a provider offers to replace your existing DMARC record, decline and add its other records manually. See SPF, DKIM, DMARC and IPs.

Postgraduate

Delegating DKIM via CNAME lets the provider rotate keys without DNS edits; the return-path subdomain lets SPF pass on an aligned subdomain without consuming your apex SPF lookup budget. DMARC should be rolled out from monitoring to enforcement based on aggregate reports, never relaxed to mask a failure.

Developer

Example shapes only: em[NNNN].brand.example CNAME [provider target], s1._domainkey.brand.example CNAME [provider target], brevo-code TXT [value], _dmarc TXT v=DMARC1; p=none; rua=mailto:dmarc@brand.example. Values come from your provider account. Check every authoritative nameserver before verifying, and keep proxying off for mail records.

Grade school

Send yourself a test email. Check it arrived, looks right and that replying works.

High school

Check these one at a time — passing one doesn’t prove the next:

1. Domain verifiedYour sending service says your DNS records are correct.
2. AcceptedThe service took the message. That isn’t delivery yet.
3. DeliveredThe recipient’s mail server received it. It may still land in spam.
4. AuthenticatedThe received message shows SPF, DKIM and DMARC passing for your domain.
5. Looks rightLogo, links, totals and phone layout are correct.
6. Replies workA reply reaches your monitored mailbox.

College

Use WP Mail SMTP’s test email to confirm transport, then place a test order on a test copy of your site (not the live one) to check real WooCommerce templates. Open the received message’s original/source view to read the Authentication-Results header for SPF, DKIM and DMARC.

Postgraduate

Treat each gate as separate evidence. A provider 202/“accepted” state, a verified domain badge and an inbox screenshot each prove different things. Test through a lower environment whose mail is contained, so no real customer receives test messages.

Developer

Correlate the provider message ID with the recipient’s headers: look for dkim=pass header.d=brand.example, spf=pass smtp.mailfrom=em[NNNN].brand.example and dmarc=pass header.from=brand.example. Confirm Reply-To is present when expected. Never trigger queued or scheduled production jobs to “see if mail works”.

Grade school

If you switch sending services, set up the new one first, test it, then switch. Keep the old one ready in case something goes wrong.

High school

Moving from one service to another — for example from Brevo to SendGrid, or the other way — is safest in this order: set up and verify the new account, test it, switch the plugin in a quiet period, check real messages, and only then retire the old account.

If YPB currently sends your storefront email for you, YPB will contact you before changing anything about how it’s sent.

College

Before switching, list every way your site sends mail: the mail plugin, contact forms, and any plugin that talks to a provider directly. Verify the new provider’s DNS alongside the old one’s (they can coexist), switch the mailer, and keep the old credentials unused but valid for a short rollback window.

Postgraduate

Run providers in parallel at the DNS layer but not at the transport layer: two active mailers risk duplicate sends. Carry over suppression and unsubscribe lists where relevant, and don’t let queued retries fire through the new route before you’ve checked them.

Developer

Inventory wp_mail filters, must-use plugins, direct provider SDK calls and Action Scheduler hooks before cutover. Authenticate the new provider’s DKIM selectors (distinct selector names avoid collisions), switch WPMS_MAILER or the UI mailer, then revoke the old key only after confirming nothing still uses it.