[ Sending-service guides ]
Authenticate email sent through BigCommerce: configuration and verification
Distinguish BigCommerce’s built-in store mail from custom SMTP before changing authentication or DNS.
By the EmailAuth research team · 3 min read
[ Key points ]
- Classify built-in store mail separately from custom SMTP.
- Website pointing does not establish who hosts authoritative DNS.
- Use harmless notification tests without charges or fulfillment.
[ Takeaway ]
Use harmless notification tests without charges or fulfillment.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Match DNS to the actual relay
Built-in and custom SMTP are different routes.
Next steps
- Check authoritative nameservers.
- Review the existing SPF policy.
- Inspect received alignment.
CISO / SecOps
Preserve domain protection
A setup example is not permission to weaken policy.
Next steps
- Review DMARC changes explicitly.
- Keep SMTP secrets out of tickets.
- Test all material store routes.
Founder / Non-technical
Protect transactional communication
Authentication work must not create real orders accidentally.
Next steps
- Name the store operator.
- Approve a harmless notification test.
- Plan a return to the previous sending mode.
[ FAQs ]
Frequently asked questions
Does this cover my newsletter integration too?
Only if it actually uses the store sending route. An external marketing platform has its own authentication setup.
Does BigCommerce sign built-in store mail?
Its documentation says it does. Still inspect the signing domain and alignment in the message you receive.
What changes with custom SMTP?
The actual relay provider’s authentication instructions become relevant; built-in store signing is not a substitute.
Where do I edit DNS when using BigCommerce nameservers?
The documented location is Settings > Email & DNS records > Web Hosts.
Does an A record pointing to my store move DNS hosting?
No. Check the authoritative nameservers to identify the service controlling the zone.
Should I replace my reject policy with the blog’s p=none example?
No. Preserve the existing approved policy unless its owner deliberately authorizes a change.
Must I place a real order to test?
No. Prefer an approved preview or sandbox workflow and avoid customer charges or fulfillment side effects.
When should store authentication be checked again?
After changes to SMTP mode, From identity, message workflow or authoritative DNS hosting.
[ Sources ]
Sources
- Changes to Google and Yahoo Email Authentication
Sections Do I need to take action? · DKIM Record · SPF Record · DMARC Record
- RFC 7208
Sections §2.4 Checking authorization · §3.2 Multiple DNS records · §4.6.4 DNS lookup limits
- RFC 6376
Sections §3.5 DKIM-Signature header · §3.6.2 DNS binding · §6 Verifier actions
- RFC 9989
Sections §4.4 Identifier alignment · §4.10 DNS tree walk · §5.3.5 Determine DMARC pass or fail
[ Glossary ]
Glossary
- SPF
- DNS authorization for the SMTP envelope-sender domain, subject to protocol limits.
- DKIM
- A signature verified using a public key at a selector under the signing domain.
- DMARC alignment
- The required relationship between the visible From domain and a passing SPF or DKIM authentication domain.
- Authoritative DNS
- The delegated DNS service responsible for the published zone answers.
- Selector
- The DKIM identifier used with the signing domain to locate the public key.
Enterprise provenance
Why top financial institutions and governments retired their email security dashboards.
Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.
EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.
SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption