For email sent by your Shift4Shop store, enable the DKIM module, retrieve its generated public TXT record, and publish that exact record in authoritative DNS. Keep the module enabled even when another company hosts your DNS. Shift4Shop documents include:spf.protection.shift4shop.com for its store-sending service. Add an applicable authorization to the domain’s existing single SPF policy, not as a second SPF record. Then test the actual store message and its intended sender identity.
These instructions cover native store-generated messages and the built-in newsletter route on an existing custom domain. They do not configure an external newsletter platform or the mailbox service that receives your business email. Authenticating one sender does not configure the others. Shift4Shop DKIM and bounceback documentation · Native newsletter configuration.
The provider describes the DKIM feature as introduced in version 9. This is a documentary configuration guide, not a test of your store, DNS or delivered mail.
On this page: Before changing anything · 1. Confirm the store’s intended From address · 2. Enable native DKIM and retrieve the issued record · 3. Handle SPF without creating a second policy · 4. Verify DNS, signing and alignment separately · Troubleshooting by evidence · Frequently asked questions
Before changing anything
Record the custom domain, the precise native message type you are commissioning, its intended visible From address and who controls authoritative DNS. Obtain approval to change the store and the specific DNS records. Keep a copy of the current record set and the store’s DKIM state for comparison.
| Situation | Appropriate next step |
|---|---|
| Native store mail using a custom domain | Use the store’s DKIM module and generated record, then verify the native message |
| Domain DNS hosted by Shift4Shop | Inspect the generated record through the store’s Manage DNS controls and confirm it is publicly authoritative |
| Domain DNS hosted elsewhere | Obtain the generated record from Shift4Shop, publish it with the authoritative provider and keep the module enabled |
Store uses only a temporary *.s4shops.com or *.3dcartstores.com address |
The documented custom-domain DKIM feature does not apply; establish an approved custom-domain plan first |
| Mail comes from an external marketing application or your business mailbox | Authenticate that actual sending provider separately; do not assume this module signs its messages |
A registrar, web host and DNS host can be different companies. A record visible inside Shift4Shop will not be published to the world if another DNS service is authoritative. You do not need to move nameservers or replace your mailbox MX records merely to publish an issued DKIM TXT record. The provider explicitly supports external DNS. Custom-domain and external-DNS requirements.
1. Confirm the store’s intended From address
Shift4Shop’s newsletter guide places the global sender address at Settings > General > Store Settings, in Invoice Information > Email. Check that this is the approved sender address associated with the store’s domain before changing authentication. The source warns that a sender address that does not reflect the store domain is replaced with a platform address. That is not successful authentication of your intended brand.
Do not put a customer’s address in the visible From field to imitate that person, and do not change a business sender address just to obtain a passing test. If your actual configuration needs a different sending domain or product route, resolve its support and signing requirements first. Record the actual delivered From later rather than assuming the configured value survived unchanged. Provider sender-address instructions and rewrite warning.
2. Enable native DKIM and retrieve the issued record
With the responsible owner’s approval:
- Open the Shift4Shop Online Store Manager.
- Go to Modules and search for DKIM.
- Select Enable, then Save.
- Open Settings > General > Store Settings.
- In Store Information, choose Manage Domain & Store URL and select Manage DNS for the correct custom domain.
- Inspect the generated DKIM TXT record. Copy its complete owner name and complete public-key value from your account, including all key material.
The older DKIM article calls the entry point Manage DNS directly; the more detailed newsletter guide shows Manage Domain & Store URL, followed by the domain’s Manage DNS link. If your account differs, locate the supported domain controls or ask Shift4Shop rather than editing another domain’s record.
The provider identifies a generated owner beginning cartdkimk._domainkey. followed by the store domain. Treat that as a documented locator, not permission to manufacture a key or override the current account’s issued values. The source’s screenshots contain illustrative domains and a blurred key in the highlighted example. Neither is a deployable record. Module, generated TXT and DNS navigation.
If Shift4Shop hosts authoritative DNS
Confirm the generated TXT record exists for the intended domain and is returned by its authoritative nameservers. Do not add another copy simply because the interface has an Add New Record button. Inspect the owner and public value against the issued record.
If another service hosts authoritative DNS
Create the issued TXT record at that service. Leave the DKIM module enabled in Shift4Shop: the module controls the store’s signing function, while DNS makes the matching public key available. Publishing a key alone does not prove that outgoing messages are signed.
Map the full issued owner to your DNS editor’s input format. For example, an editor that appends the zone might require only the relative portion, while another accepts the full name. Verify the final public name so the domain is not appended twice. If a child domain or _domainkey subzone is delegated, publish in the zone authoritative for that owner.
If a different record or active key already occupies that name, stop and reconcile it with the domain owner and Shift4Shop. Do not overwrite a working signer or delete unrelated selectors. Multiple unrelated services can use different selectors on the same domain. Copy only the public DNS record; private signing keys do not belong in DNS, tickets or shared screenshots. External DNS and retaining the enabled module.
3. Handle SPF without creating a second policy
Shift4Shop’s native-store guidance provides this authorization mechanism:
include:spf.protection.shift4shop.com
This is not a complete policy to paste over an existing record. First establish which domain the actual store route uses for its SMTP envelope sender, commonly shown as smtp.mailfrom in trusted receiver results. SPF evaluates that identity, not merely the address displayed in From. If the route uses a different envelope domain than expected, ask Shift4Shop which owner its authorization applies to before editing DNS. Provider include · SPF MAIL FROM identity.
For the applicable owner:
- Find the existing TXT policy beginning
v=spf1. Do not search only forv=spf1 include:; a valid policy can begin with an IP mechanism or useredirect=. - Preserve other legitimate senders, the intentional terminal qualifier and any carefully managed redirect design.
- If the Shift4Shop authorization is absent and required for this route, merge it into the same policy, separated from neighboring mechanisms by spaces.
- Do not add it after an
allmechanism, where it cannot authorize another sender. If the current policy delegates withredirect=, have its owner design the change rather than blindly appending a mechanism. Anallmechanism anywhere in the policy suppressesredirect; do not introduce one as a casual repair. - Evaluate the resulting policy’s DNS-querying terms, including nested includes, against SPF’s ten-lookup limit. Count the complete evaluation, not just the number of visible includes.
Important correction to the provider wording: its external-DNS section refers to “two separate SPF records” but shows the mailbox and store authorizations together. Publish only one SPF policy at an owner. Two separate v=spf1 TXT records there cause an SPF permanent error. Other unrelated TXT records can coexist. Do not copy the source’s placeholder or its visually joined include strings literally. SPF record selection · Lookup limit · Redirect behavior.
If Shift4Shop manages DNS, its guide describes inspecting an existing TXT entry’s details before editing. Do not leave the record owner at a default value unless it is confirmed to be the correct SPF owner. External DNS uses the same one-policy rule. Existing mailbox authorization is not a reason to remove the store sender, and adding the store is not a reason to remove your mailbox service.
4. Verify DNS, signing and alignment separately
Check the issued DKIM owner against authoritative DNS and a public resolver. Confirm the complete key matches the account’s issued value. A DNS tool may display a long TXT value in quoted chunks; check the resulting logical value rather than creating multiple independent key records. Check the applicable SPF owner for one valid policy and confirm the intended store authorization is effective.
Next, arrange a harmless, authorized test through the exact native store route. Do not place a paid order, change a real order’s status, send a live newsletter or contact customers simply to trigger a test. Use an approved test facility or coordinate a safe test with the store owner and Shift4Shop. A business-mailbox message is not a native-store test.
At a recipient you control, inspect the delivered message’s original headers:
| Evidence | Acceptance question |
|---|---|
Visible From: |
Is it the intended brand address, without a provider fallback rewrite? |
Intended store DKIM-Signature |
Which d= signing domain and s= selector did this actual native route use? |
| Receiver DKIM result | Does the intended store signature pass, rather than only some unrelated signature? |
| Receiver SPF result | What actual smtp.mailfrom domain was evaluated, and did it pass? |
| Receiver DMARC result | Does the trusted receiving system report dmarc=pass for the intended From domain? |
Use Authentication-Results produced inside the receiving service’s verified authentication boundary, not an arbitrary header supplied by the sender. Confirm with the receiving administrator or that service’s documentation how externally supplied authentication headers are removed, ignored or distinguished from its own evaluation. A plausible authserv-id or a header’s position is not proof of trust by itself. If that boundary cannot be established, ask the receiver’s administrator to identify its authoritative result before accepting the test. A selector lookup, enabled checkbox or successful delivery cannot establish all these outcomes. Authentication-Results trust boundary.
A raw SPF or DKIM pass is not necessarily aligned with From. Under relaxed alignment, the authenticated identity and From share the same Organizational Domain. Under strict alignment, they must match exactly: DKIM compares its d= domain, while SPF compares the envelope domain. A child envelope domain is not automatically strict-aligned with its parent. DMARC can pass through either aligned authentication method, but commissioning this DKIM setup additionally requires the intended native store signature to pass and align. Do not accept a pass supplied only by another signer. DMARC identifiers and alignment.
For interpreting the distinction between a raw signature result and its policy contribution, see raw DKIM results versus aligned DKIM policy results.
Keep existing DMARC enforcement, alignment and reporting settings intact. A domain or parent policy already in force must not be weakened to hide a setup failure. Review existing authorized aggregate reports after controlled testing to check the real sending population; one message does not prove every store workflow works.
Troubleshooting by evidence
| What you observe | What to inspect next |
|---|---|
| Key appears in Store Manager but not public DNS | Verify authoritative DNS and publish the exact issued TXT there; do not move nameservers as a shortcut |
| No intended DKIM signature | Confirm the module remains enabled and that the message actually used the native route; ask support about activation if needed |
| DKIM fails | Compare actual selector/domain, full issued public key and authoritative owner; investigate message modification only after identity/key checks |
| DKIM passes but DMARC fails | Compare signing domain with the actual From and the published alignment mode |
SPF reports fail while DKIM supplies DMARC pass |
Check the actual envelope owner, sending host and authorized service; DKIM success does not repair a separate SPF failure |
SPF reports temperror |
Investigate temporary DNS lookup or resolver failures, then retest the same route; do not rewrite policy based on one transient result |
SPF reports permerror |
Check duplicate policies, syntax, include expansion, redirect and lookup budget |
| Message uses a platform From address | Resolve the documented sender-domain mismatch; do not count the fallback as brand-auth success |
| Authentication passes but mail lands in junk | Investigate reputation, content, consent and recipient filtering separately; do not weaken authentication |
Preserve existing suppressions and bounce handling. Do not remove a blacklist entry or disable filtering as an authentication test. The provider’s bounce-management section is a separate operational topic, not a prerequisite to enabling DKIM.
Escalate with the store route, custom domain, relevant DNS owners, timestamps, module state and sanitized receiver results. Exclude customer order details, credentials and private message content. Recheck after an approved domain change, key replacement or sending-route change; coordinate any old-key retirement with Shift4Shop rather than deleting records immediately.