BigCommerce SPF, DKIM and DMARC setup, step by step

BigCommerce automatically DKIM-signs outgoing mail sent through its native store-email service. You do not need to generate a native BigCommerce DKIM key or add a selector from a tutorial. For native SPF authorization, BigCommerce specifies include:_spf.bigcommerce.com, which belongs in the applicable single SPF policy, not in a second record. A store using custom SMTP instead needs the selected relay's authentication configuration.

Automatic signing does not establish which domain appears in every signature or prove alignment with your store's From address. Finish by checking a harmless store-generated sample at a trusted receiver. Keep the existing DMARC policy while you establish the actual authenticated identities. These distinctions follow BigCommerce's current Email in BigCommerce documentation and authentication guidance.

This guide covers native store-generated email and BigCommerce's optional custom SMTP connection. No customer account, DNS change, email delivery or commercial transaction was tested for this guide.

1. Identify the sending route and the right addresses

Record the store, storefront, message type, intended From address and current sending mode before editing anything. BigCommerce's native mail, an external newsletter integration and an employee mailbox are different senders, even when they display the same domain. BigCommerce does not provide a hosted mailbox service; its email-forwarding feature is also separate from outbound authentication.

Check Settings → Miscellaneous → Use SMTP Server. Use my default mail settings identifies the native branch; Let me specify my own SMTP server details selects a custom relay. Inspect the existing selection without changing it merely to follow this guide.

Several addresses have different purposes:

• Settings → Store Profile contains the store email used for customer-facing store messages. Verify the intended From and reply destination in received mail.
• Administrator's Email, under Settings → Miscellaneous, receives system notifications and the custom SMTP connection test.
• The signed-in user account's email address receives the transactional-template test. It is not necessarily the Administrator's Email.
• Settings → Order notifications controls merchant notifications and customer status-message triggers. A contact-form recipient is another separate setting.
• With Multi-Storefront, contact information can be storefront-specific in Channel Manager. Inventory those identities rather than assuming the global Store Profile email applies everywhere.

Use an approved domain you control. Owning a Gmail or Yahoo mailbox does not give you authority to publish authentication records for gmail.com or yahoo.com. Do not change an established customer-facing address simply to make a test appear successful. See store email addresses and transactional-email settings.

Access and a safe change window

The documented DNS permissions are Manage Settings to access settings and Manage DNS Records to change DNS. Transactional-template viewing/editing requires Store Design; the customer-notification guide also identifies Read Channels for template management. Enabling or disabling templates requires Manage Settings. Arrange appropriate access, not a broader role change as a troubleshooting shortcut.

Save the existing DNS values, effective DMARC policy, sending-mode selection and storefront address inventory privately. Keep SMTP credentials out of screenshots, articles and support tickets. Identify the store operator who can approve a route change and the DNS owner who can approve changes shared with other senders. The access requirements are documented in Managing DNS, Customizing Transactional Emails and Customer Order Notifications.

2. Find the authoritative DNS service

A website pointing to BigCommerce by A or CNAME record does not transfer DNS authority. Check the domain's actual delegation and identify the account operating that zone. The registrar may be the DNS provider, but it need not be.

If BigCommerce actually hosts the authoritative zone, its editor is Settings → Email & DNS records → Web Hosts. If the zone remains elsewhere, edit the records at that authoritative service. Do not switch nameservers just to obtain the BigCommerce editor. With Multi-Storefront, BigCommerce's DNS editor covers only the default native storefront; check the external DNS arrangements for additional storefronts. BigCommerce DNS documentation

These read-only commands are a starting point. Replace every angle-bracket placeholder with the actual domain or server; confirm child-zone delegation with the DNS administrator rather than assuming an apex lookup identifies every record's authority.

dig NS '<STORE_DOMAIN>'
dig @'<AUTHORITATIVE_SERVER>' TXT '<SPF_OWNER>'
dig TXT '<SPF_OWNER>'

The authoritative and recursive answers should eventually agree after relevant caches expire. The TXT query must show the intended single SPF policy, alongside any unrelated TXT records that legitimately share the owner. No answer or a different answer means you should investigate authority, owner spelling and caching before adding another record.

Leave the automatic storefront A record, inbound MX records, forwarding recipients, NS delegation, DNSSEC and other services unchanged. Adding SPF authorizes sending; it does not require rerouting incoming mail or moving the website.

3. Configure native BigCommerce SPF without losing other senders

For native store mail, the documented authorization is:

include:_spf.bigcommerce.com

This is a mechanism to incorporate into a complete SPF policy, not a complete TXT value by itself. BigCommerce says new stores receive an SPF record automatically, but verify the record at the actual authoritative provider. An automatic configuration claim does not establish that an externally hosted zone has been updated. Native SPF instructions

Check the evaluated identity first

SPF checks the SMTP envelope sender, normally shown by the trusted receiver as smtp.mailfrom, not automatically the visible From address. The delivered Return-Path is useful supporting evidence. A null envelope uses the relevant HELO identity. Adding an include to your apex cannot repair SPF evaluated against a different, provider-controlled envelope domain.

Follow BigCommerce's store-domain authorization guidance, but record the actual envelope identity during testing. If it differs, determine which policy the receiver evaluated and who controls it. Do not invent a native custom Return-Path setting or publish records in a domain you do not own. SPF identity rules

Merge, rather than replace

1. Query the applicable owner's existing TXT records. Identify the one beginning v=spf1, including any redirect dependency and existing legitimate senders.
2. Add include:_spf.bigcommerce.com only where the native route requires it, without duplicating an existing inclusion. Keep one v=spf1 policy at that owner.
3. Preserve authorized mechanisms and the approved final qualifier. If the existing policy uses redirect, reconcile the policy deliberately: adding an all mechanism causes redirect to be ignored.
4. Evaluate the combined policy's maximum of ten evaluated DNS-dependent terms: include, a, mx, ptr, exists and redirect, including nested evaluation. This is not ten textual includes or ten total DNS packets. Resolve excess complexity with the policy owner; do not replace dynamic provider includes with a one-time copied IP list.

BigCommerce's prose example contains +a +mx and ends in ~all; its DNS-editor screenshot ends in -all. Neither example authorizes an arbitrary qualifier change. a authorizes addresses resolved for the relevant A/AAAA name, and mx authorizes the addresses of its mail exchangers. A storefront/CDN address or inbound mailbox service is not automatically an approved outbound sender. Inventory the actual resolved destinations before retaining, adding or removing these mechanisms. Qualifiers produce SPF results; they do not guarantee a receiver's delivery decision. SPF policy, lookup and processing rules

If no SPF policy exists, establish the legitimate sender inventory first. For an owner used only for this native route, with no existing redirect or other senders and an explicitly approved softfail policy, a minimal illustrative value is:

v=spf1 include:_spf.bigcommerce.com ~all

Do not paste that example over a multi-sender policy or adopt its qualifier without approval.

Publish in the correct editor

In BigCommerce-hosted DNS, edit the existing SPF TXT row. Use Add another only when the needed record is absent. The documented fields are Type, Fully Qualified Host, Value and Time to live, followed by Save.

• Set Type to TXT.
• Enter the full owner, such as example.com, in Fully Qualified Host. BigCommerce explicitly requires the domain here, not @.
• Put the complete approved SPF policy in Value, once. Do not concatenate two complete v=spf1 policies.
• Preserve an appropriate TTL. The documented default is 86400 seconds; BigCommerce generally advises against values below 900 seconds. Neither value promises a fixed propagation time.

At an external DNS host, follow its owner convention. For full owner example.com, a relative-name editor may use @; for mail.example.com inside zone example.com, it may use mail. In a separately delegated mail.example.com zone, that same full owner is the child zone's apex. Verify the resulting full name to avoid example.com.example.com. Actual BigCommerce DNS fields

4. Understand what native DKIM does and does not prove

BigCommerce's current help page states that it signs all outgoing store emails with DKIM keys and requires no additional configuration. Its official authentication announcement confirms that a store using native delivery does not need to add a DKIM record. There is no documented native customer-key generation step, selector to copy or signing toggle in these instructions. Current native DKIM statement · Official corroboration

That is not a promise that every signature uses your brand domain. Obtain the actual d= signing domain and s= selector from a newly received message. DKIM verification looks up the public key at s._domainkey.d; use those actual values, not a guessed default selector or the visible From domain by assumption. A signature's presence alone does not prove it passes. DKIM DNS binding

If native DKIM passes for a provider domain but does not align with your From, record that accurately. An aligned SPF pass might still satisfy DMARC. It would not establish branded DKIM success. The public documentation reviewed does not establish native customer-specific signing-domain or envelope controls, so do not infer either guaranteed support or permanent impossibility. Investigate the actual account capabilities with BigCommerce if those identities do not meet your requirements, or evaluate an approved, correctly authenticated custom SMTP route.

Do not generate a public/private key pair yourself and expect BigCommerce to start using it. Never publish or share a private signing key.

5. Optional custom SMTP: configure the actual relay

Skip this section if you are keeping native delivery. Switching SMTP changes the sender responsible for store mail, not just a DNS setting. BigCommerce's custom SMTP settings are shared across all storefronts within the store. Approve the impact on every storefront and From address before switching. The connection must be secure; TCP port 25 is not allowed. Custom SMTP requirements and scope

First obtain the selected relay's current account-specific authentication instructions and permitted From identities. Complete its documented DNS verification and signing activation. Its exact SPF owner, selectors, record types, complete values, envelope behavior and activation requirements govern this route. BigCommerce's native include or automatic signing is not evidence that an unrelated relay is configured correctly. An employee mailbox is also separate; see the Microsoft 365 authentication guide if that is your mailbox service, without assuming every tenant permits application SMTP submission.

For relay-issued DKIM records, map full owners to the correct parent or separately delegated child zone. Preserve existing selectors and any _domainkey NS delegation. A record inside an already delegated namespace belongs at its actual authoritative service. If an issued CNAME owner conflicts with TXT, A, AAAA, MX or another CNAME, stop and reconcile the conflict instead of deleting shared records. A CNAME cannot coexist with those records at the same owner. CNAME constraints

Where the relay requires literal CNAME answers, publish DNS-only aliases, not HTTP-proxied records. Check applicable per-record, whole-zone, apex and same-zone flattening behavior. Turn off an applicable per-record flattening control when available and ensure relevant zone behavior does not hide the issued alias. Do not disable unrelated zone features globally. If mandatory behavior cannot preserve the required CNAME response, stop and coordinate a supported configuration with the DNS host and relay. Do not invent a switch or remove a delegation.

Then follow BigCommerce's documented connection sequence:

1. Open Settings → Miscellaneous → Use SMTP Server and select Let me specify my own SMTP server details.
2. Enter SMTP Hostname, SMTP Username, SMTP Password and SMTP Port from the chosen service's approved connection instructions. Do not guess a port or use a sample hostname. BigCommerce's hostname-field instructions specify the starttls:// prefix for a server supporting SSL/TLS; confirm the compatible secure connection with the relay rather than treating that field convention as a universal SMTP URL format.
3. Check that Administrator's Email is an approved, controlled recipient. With permission to send the test, click Test SMTP Settings. That test goes to this address, not the template editor's user-account address.
4. Save the approved settings. Then test a transactional template through the saved route and inspect authentication. A successful connection test does not establish that every storefront From is authorized or DMARC-aligned.

Keep the last approved sending mode available for a controlled rollback. Do not remove the native SPF include or old relay records until the sender inventory proves no active route still needs them.

6. Preserve DMARC and check its actual alignment requirements

Check the intended visible From domain's direct DMARC record and any applicable inherited policy before making changes. Preserve established p, subdomain policy, alignment settings and authorized report destinations. An absent _dmarc record on a child does not prove the child has no policy. BigCommerce's monitoring example is not permission to replace quarantine or reject with none. DMARC policy discovery and alignment

Only if no direct or applicable inherited policy exists, the domain owner approves, and a monitoring plan is appropriate, a first-policy baseline can be:

Type: TXT
Full owner for From domain example.com: _dmarc.example.com
Relative owner inside zone example.com: _dmarc
Value: v=DMARC1; p=none

These are illustrative domains. For From domain shop.example.com, the full owner is _dmarc.shop.example.com; its relative owner is _dmarc.shop in parent zone example.com, or _dmarc in a separately delegated shop.example.com zone. BigCommerce's Fully Qualified Host field takes the full owner. Do not publish a second policy or create a child override merely to bypass inherited protection.

The minimal example does not request reports. If adding rua, use an authorized destination with an agreed review and retention process. A report destination in a different Organizational Domain from the policy domain requires the report-generating receiver's DNS authorization check. A destination within the same Organizational Domain is excepted. Use the reporting service's exact authorization instructions when needed. That protocol check does not replace the owner's approval to share report data. RFC 9990, section 4

DMARC passes when at least one authenticated path both passes and aligns: SPF's evaluated envelope domain or a DKIM signing domain. Relaxed alignment allows the same Organizational Domain; strict aspf=s or adkim=s requires an exact domain match for that respective path. A child signing or bounce domain is therefore not a universal strict-alignment solution. Keep the approved From unchanged while testing. DMARC identifier alignment

7. Send a harmless sample and inspect the received identities

You do not need to create a real order, charge a card, resend a customer's invoice or trigger fulfillment to obtain an initial store-email sample.

1. Open Marketing → Transactional Emails and select the relevant global or storefront context.
2. Open the template's action menu (…) → Edit template.
3. Use Preview to inspect randomly generated example content. Do not edit, enable, disable or reset the template merely to test authentication.
4. Confirm your user account's email address is a valid, controlled test inbox. With approval for that send, choose Send test email in the upper-right corner. It sends the sample to this user-account address. The email test uses the storefront's default language, even though Preview can display other configured languages.
5. Open the received message's raw headers. Record the sending mode, storefront context, template and time alongside the evidence below.

These are BigCommerce's documented preview and test controls. A preview alone sends nothing and supplies no authentication evidence. A sample validates only the route it actually exercises. For materially different notifications, integrations or storefront identities, arrange further approved harmless tests. Do not substitute a paid order or customer-facing operational event.

Establish which authentication results are trustworthy

Use results produced inside the actual receiving service's known processing boundary, with its documented handling of externally supplied Authentication-Results. Confirm with the receiving administrator which gateway or mail service performed the checks and how it removes, ignores or separates untrusted incoming result fields. A familiar authserv-id string or a header near the top is not sufficient proof. Ignore attacker-supplied or otherwise untrusted result fields; if provenance is uncertain, obtain the receiver's authenticated message trace rather than declaring a pass. Authentication-Results trust boundary

Record the following for each material route. These are evidence fields, not promised BigCommerce identities:

For a newly configured branded DKIM route, acceptance requires the intended sender's signature to pass and align with the intended From, plus trusted dmarc=pass. A DMARC pass supplied only by SPF does not prove branded DKIM is working. A rewritten provider From does not satisfy the original brand-identity objective.

For native BigCommerce mail, distinguish automatic DKIM signing from that stricter branded-DKIM objective. A verified provider-domain signature plus aligned SPF can yield valid DMARC, but still leaves branded DKIM unestablished. If neither path aligns, do not weaken DMARC; investigate the actual sender identities and supported configuration.

Diagnose SPF fail, temperror and permerror independently even when aligned DKIM supplies DMARC pass. Check the actual envelope owner, temporary DNS failures, duplicated policies and lookup limits respectively, rather than adding more includes to the visible From domain. Authentication success is not a guarantee of inbox placement.

If a DKIM result needs investigation, query the exact public owner derived from the received signature:

dig TXT '<ACTUAL_SELECTOR>._domainkey.<ACTUAL_DKIM_SIGNING_DOMAIN>'

Compare the answer with the relevant provider's configuration and the receiver's result. A published key is DNS evidence, not proof that the sender used its matching private key. Do not modify provider-owned DNS. Keep raw messages private; redact customer data, identifiers and unrelated headers before sharing diagnostic excerpts.

Troubleshooting and safe rollback

SPF is still wrong after a DNS edit

Confirm the evaluated smtp.mailfrom domain, authoritative zone and full owner. Check authoritative and recursive responses and relevant TTLs. A website A/CNAME pointing to BigCommerce does not make the BigCommerce DNS editor authoritative. Do not wait an arbitrary 72 hours while editing the wrong zone, or create a second SPF policy to force an update.

Native mail has no customer-domain DKIM signature

Current documentation confirms native signing, not the customer's exact signing domain. Inspect the actual native message and trusted results first. If the expected signature is absent or fails, retain the sanitized headers and route details for BigCommerce. If the signature passes but is unaligned, investigate alignment rather than inventing a selector. Custom SMTP is an optional approved route, not a required response to an outdated claim that native DKIM is unavailable.

The SMTP test succeeds but store messages fail

The connection test's Administrator's Email is distinct from the template test's user-account address. Check the saved sending mode, the relay's permitted From identities and signing configuration for every storefront. Shared SMTP settings can affect stores that use different customer-facing domains. Retest the saved transactional path rather than relying only on connection success.

An order notification never arrives

First ask whether the application generated it. Check the relevant Marketing → Transactional Emails template at both global and storefront levels and the chosen customer-status triggers under Settings → Order notifications. Order confirmation uses its separate Order Email template. API-created orders do not trigger the confirmation invoice, though status-change messages can still be sent. These documented behaviors are not evidence of an SPF failure. Do not change order status, enable every notification or reset custom templates as a DNS repair. Customer-notification troubleshooting

If a message was generated, inspect its bounce or recipient-side trace, the affected recipient domain and the trusted authentication result. Investigate filtering, reputation and mailbox issues separately. Do not blanket-allowlist BigCommerce, disable filters or ask customers to lower security controls.

A change affects another sender or storefront

Pause the rollout and restore only the approved DNS values or sending-mode settings changed in that rollout. Preserve shared SPF mechanisms, active selectors, forwarding and inbound mail routes. A DNS rollback also has cache timing; retest after it becomes visible. Do not use Reset to system default in the template editor as a mail-authentication rollback: it permanently deletes template customizations. Template reset warning

Keep an owner, change record and retest checklist. Recheck after SMTP migrations, DNS-provider moves, From-address changes, template-route changes or adding storefronts. Review legitimate sender evidence before tightening DMARC enforcement.

Sources and verification boundaries

• Email in BigCommerce: native SPF/DKIM, address roles, forwarding boundary and custom SMTP.
• Managing DNS: permissions, authoritative editing, full-host fields and Multi-Storefront limits.
• Changes to Google and Yahoo Email Authentication: official confirmation of native signing and the SPF include.
• Customizing Transactional Emails: permissions, preview, sample recipient, language limit and reset warning.
• Customer Order Notifications: sender addresses, storefront context, triggers and API-order behavior.

Publication/update dates were not established for the help-center pages. The announcement's February 1, 2024 date refers to mailbox requirements, not page publication. Actual account settings, issued relay records, DNS answers and received-message identities remain deployment checks. No test result, supported branded identity, ranking or delivery outcome is implied by this documentary guide.