Ecommerce email marketing: check SPF, DKIM and DMARC

A store improving ecommerce email marketing may need to repair its sending identity before changing messages. Inventory each sending service, then read SPF, DKIM and DMARC results in received messages and connect failures to specific repairs. Authentication checks whether a service is authorized to send and its authenticated domain matches the identity customers see. Passing does not guarantee inbox placement.

Map the services behind your sending domains

Start with every service that sends email for the store, not just the provider used for promotional campaigns.

Order confirmations and marketing messages may travel through different systems even when their visible sender addresses look identical, so trace every stream rather than only promotional email. For each stream, record the following in an email marketing checklist:

Klaviyo, Mailchimp, and Omnisend are examples of email service providers to identify in this inventory; Shopify, WooCommerce, and BigCommerce are examples of ecommerce platforms whose connections should be traced. Record the store's actual setup rather than assuming the platform and marketing provider use the same sender configuration.

Keep the Reply-To address separate in the inventory. It helps customers reach you, but it is not the identity SPF or DMARC uses to authenticate the message. Record it as a reply path, not as an authentication domain, alongside the visible From and envelope-sender details.

Read the results in a received message

Send a test through the actual stream you are checking. Use a directly received copy for the initial investigation, because forwarding can change SPF results and complicate diagnosis. Check each sending stream separately, since one stream's result does not establish the result for another.

In Gmail, open the message's menu and choose Show original, then inspect authentication results and original headers. Read the receiving service's Authentication-Results header rather than assuming a provider's setup screen proves authentication succeeded. This keeps the diagnosis tied to the received message rather than account configuration alone.

A passing SPF result does not automatically mean DMARC passes. The service might be authorized to send for its own envelope domain without authenticating the store's visible From domain, so read SPF alongside DMARC rather than treating the SPF result as a complete authentication verdict.

Likewise, DKIM can pass using a provider's signing domain while remaining unaligned with the store's From domain. DMARC needs a passing, aligned result from SPF or DKIM; both mechanisms do not have to pass. Alignment can allow an organizational-domain match or require an exact domain match, depending on the configured mode. Record domains and results together so a simple pass label does not conceal a mismatch.

Match each failure to a specific repair

Choose the repair according to the failure shown in the received message, and check the relevant sending domain before changing DNS. SPF, DKIM and DMARC can fail for different reasons, so use the recorded domains and results to identify the affected service and avoid making unrelated changes.

SPF fails for the envelope-sender domain

Check the SPF record for the domain identified in the received result, not automatically the visible From domain. Confirm the sending service is authorized using that provider's domain-setup instructions, because the received SPF result identifies the envelope-sender domain being checked for that message.

If the provider requires an SPF change, update the existing SPF record rather than publishing another SPF record at the same hostname. Preserve authorization for other legitimate services while making the correction; replacing the record with instructions for only the newest provider can break an older stream.

DKIM is missing or fails

Check whether the message contains a DKIM-Signature header. Its d= value identifies the signing domain, while its s= value identifies the selector used to locate the verification record. These header values show which domain and selector to compare with DNS.

Inspect the DNS entry at <selector>._domainkey.<signing-domain> and compare it with the provider's instructions. Providers may require TXT or CNAME records, so copy the required hostname and value exactly rather than borrowing another store's configuration. Keep the record details with the affected stream's inventory.

A missing signature points toward signing configuration. A failed signature needs further investigation: if DNS is correct, ask the provider to examine signing and any message changes after signing rather than replacing keys blindly. This helps keep a DNS repair focused on the failure shown in the received message.

SPF or DKIM passes, but DMARC fails

Compare the authenticated domains with the visible From domain. A provider-domain pass without alignment is not the same as authenticating the store's identity, even when the SPF or DKIM result itself shows a pass. Check the domains together before changing the sending configuration.

Check the sending service's custom or branded sending-domain setup and complete its required DNS verification. Then send another message through that same stream and inspect the received result again; a successful account connection alone is not proof that the mismatch is repaired.

The DMARC record is missing or unclear

Inspect the TXT record at _dmarc.<From-domain> and record its policy and alignment settings before changing anything. The DMARC record policy p=none requests no DMARC-based quarantine or rejection, while p=quarantine and p=reject request stronger handling of messages that fail DMARC.

Do not move to stronger enforcement until legitimate sending streams have been identified and checked. If aggregate reporting is configured, the rua tag identifies its destination; confirm that the destination is controlled by the store or its authorized reporting service before relying on the reports.

Retest every affected stream

After a DNS or provider-setting repair, repeat the received-message check for each service that uses the affected domain. A promotional message passing authentication does not prove that order confirmations or another provider's messages also pass. Check each stream independently using received messages, rather than relying on account status alone.

The four-week cycle below can organize a contained investigation: inventory domains and capture headers in the first week, repair confirmed configuration problems in the second, verify real sends in the third, and recheck affected streams in the fourth. A known broken sender does not need to wait for its scheduled week before being corrected or limited.

Measure accepted messages separately from authentication results. Acceptance means the receiving system accepted the message; it does not prove inbox placement, and authentication success does not explain every bounce or delivery problem. Keep the measures distinct when reviewing the effect of a repair. Before expanding sending again, confirm:

Authentication repairs do not make suppressed recipients eligible to receive marketing. If SPF, DKIM and DMARC now pass but delivery problems remain, keep those as a separate investigation rather than repeatedly changing working DNS records. Preserve the before-and-after headers so the next operator can distinguish a repaired identity problem from a different sending problem.