Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Classify each store message
References: RFC 6376 §6.
A store can depend on transactional notifications, staff mail and marketing integrations at the same time. Begin by listing the message types you actually need to protect and the service sending each one. This guide covers BigCommerce store mail. An external newsletter platform or ordinary employee mailbox needs its own authentication configuration, even when all three use the same visible domain.
The first branch is whether the store uses built-in sending or custom SMTP. BigCommerce's authentication guidance says that its outgoing store mail is already DKIM-signed, with a separate setup responsibility when custom SMTP is used. That statement does not disclose the signing domain of every message or prove alignment with your particular From address. Inspect a received message rather than treating the existence of a signature as sufficient evidence.
Find the authoritative editor
References: RFC 1034 §4.2.
The provider distinguishes domains pointed by A or CNAME from domains using its nameservers. For its nameserver-hosted case, the documented location is Settings > Email & DNS records > Web Hosts. With A or CNAME pointing, the DNS remains outside that storefront connection. Check the actual authoritative nameservers instead of assuming the registrar is always the DNS operator.
A website resolving to BigCommerce does not prove that BigCommerce hosts the zone. Record the authoritative service, account owner and existing mail records before making changes. Avoid switching nameservers merely to obtain access to a convenient editor. A full DNS migration affects more than this authentication task.
Apply the correct sending authorization
References: RFC 7208 §3.2, RFC 7208 §4.6.4, RFC 9989 §4.10.
For built-in store sending, BigCommerce's guidance names include:_spf.bigcommerce.com. Review the existing applicable SPF TXT policy and integrate the authorization without discarding other legitimate senders. Do not publish a second SPF policy at the same owner. Evaluate the combined policy’s ten-term SPF limit across evaluated include, a, mx, ptr, exists and redirect terms, including nested processing and retain its intended final all mechanism.
For custom SMTP, use the actual relay provider's current domain-authentication instructions instead of assuming BigCommerce's include or built-in signing covers that relay. Record the SMTP provider, sending account and approved identity without putting credentials in a change ticket. Use a supported secure channel if another administrator must configure secrets.
The BigCommerce article gives a monitoring DMARC example. That is not a reason to replace an established quarantine or reject policy. Check the existing policy and the other services sharing the From domain. DMARC evaluates alignment, so preserving a policy while adding a new legitimate sender requires proving the new route aligns, not simply making the DNS editor accept the record.
Test without creating a real order
References: RFC 9989 §5.3.5.
Original test plan: have the store operator choose an approved notification preview or sandbox workflow that exercises the intended mail route. Do not create a paid order, charge a customer or trigger an actual fulfillment merely to generate a message. If a harmless route is unavailable, agree on the operational test procedure first.
Retain the received message's From domain, envelope sender, DKIM d= and s= and trusted authentication results. Compare the route with the store's configured sending mode. A passing aligned SPF or DKIM result supports DMARC; a delivery notification alone does not. Test each materially different store message path rather than assuming one password-reset or preview message represents everything.
Recover and document ownership
Illustrative failure: the store switches to a custom relay, but the team updates only BigCommerce's SPF include. The relevant fix is the new relay's identity configuration, not repeated edits to a policy for the old route. Pause the affected change and restore the last approved store sending mode if necessary.
Keep the prior DNS values and sending settings privately. Recheck after an SMTP migration, From-address change or DNS-provider move. This guide is based on first-party documentation reviewed on 8 November 2026. No store, paid transaction, DNS record or delivered notification was tested here.