Email authentication for e-commerce

17 May 2026 · 14 min read

An online shop sends more kinds of mail than almost any other business, and most of it is the mail a customer is actively waiting for. The order confirmation, the payment receipt, the "your parcel is out for delivery" notice, the password reset, the refund confirmation, the abandoned-cart nudge, the post-purchase review request, the back-in-stock alert: every one of these is a separate stream, frequently from a separate system, and every one of them has to land in the inbox at the exact moment the customer expects it. Email authentication for e-commerce is the discipline of making all of those streams provably yours, so that the mailbox providers deliver them and so that nobody else can forge them.

This is not a generic DMARC explainer. The hard part of authenticating a shop is not understanding SPF, it is that a typical store sends from five to fifteen different services at once, the transactional and marketing mail follow completely different paths, and a single missing record can quietly divert receipts to spam without anyone noticing until the support queue fills up. This article is about that specific shape of problem: protecting order, shipping and receipt mail, satisfying the Gmail, Yahoo and Microsoft bulk-sender rules that have applied since 2024, and getting your logo into the inbox with BIMI.

The e-commerce sending estate is the real problem

Before you touch a DNS record, write down every system that sends mail using your domain in the From address. For a shop this list is almost always longer than the owner expects. A representative estate looks like this:

The store platform itself (Shopify, WooCommerce, BigCommerce, Magento/Adobe Commerce) sending order confirmations, shipping notifications and account emails.
A dedicated transactional relay (Postmark, Amazon SES, SendGrid, Mailgun, SparkPost) if the platform has been wired to one for receipts and password resets.
A marketing/ESP platform (Klaviyo, Mailchimp, Omnisend, Brevo) for campaigns, flows and abandoned-cart sequences.
A reviews and loyalty service (Yotpo, Trustpilot, Okendo, LoyaltyLion) sending review requests and points updates.
A helpdesk (Zendesk, Gorgias, Freshdesk, Help Scout) replying to customers from support@yourdomain.com.
A 3PL, fulfilment or shipping carrier that emails tracking on your behalf.
Your own staff mail on Google Workspace or Microsoft 365.

Each of these is an independent sender with its own IP ranges, its own SPF include and its own DKIM keys. DMARC does not care how many there are; it cares that for every message, either SPF or DKIM passes and aligns with the domain in the visible From address. The job is to make all of these senders align, then lock the domain down so that anything which is not on the list gets rejected.

The single most useful thing you can do first is find out what is actually sending. Publish a DMARC record at p=none with reporting turned on, leave it for a couple of weeks, and read the aggregate reports. Every IP that has ever put your domain in a From line shows up. Run your current setup through the DMARC checker to see what you have today, then feed the XML into the DMARC report analyzer to turn it into a readable list of sources. Almost every shop discovers a sender it had forgotten about, usually the reviews app or an old fulfilment integration. This discovery step is covered in depth in reading your first DMARC report.

Transactional mail is the stream you cannot afford to break

There is a hierarchy of pain here. If a marketing campaign lands in spam, you lose some revenue and you are annoyed. If an order confirmation or a password reset lands in spam, you generate a support ticket, a chargeback risk and a customer who no longer trusts your emails. Transactional mail is the stream where authentication has to be bulletproof, because the customer is staring at their inbox waiting for it.

The technical trap with transactional mail is that the store platform and the transactional relay often disagree about which domain signs the message. Take the common Shopify-plus-relay pattern. Shopify can send order notifications itself, but it does not let you DKIM-sign customer notifications with your own domain on the standard plans; it sends them from a Shopify-controlled identity with the From address rewritten or with only Shopify's own alignment. Meanwhile your receipts might go through Postmark, which does sign with your domain the moment you verify it. The result is that two messages a customer thinks of as "from the shop" authenticate completely differently, and only one of them aligns.

The fix is to be deliberate about routing. Decide, per message type, which system sends it, and make sure that system signs with your domain:

For a relay like Postmark or Amazon SES, verify your domain and publish the DKIM CNAMEs they give you so that messages are signed d=yourdomain.com. See the provider-specific guides, for example Postmark and Amazon SES.
For SPF, set the relay's bounce/return path to a subdomain of yours where the platform supports a custom MAIL FROM, so SPF aligns as well as DKIM. Belt and braces matters here because forwarding breaks SPF, as explained in DKIM alignment and forwarding.
For platform-native mail you cannot sign yourself (some Shopify notifications, some carrier mail), either move that message type to a relay you control, or accept that it will rely on the platform's own alignment and confirm in your DMARC reports that it still passes.

A worked example of an aligned transactional message looks like this:

MAIL FROM (Return-Path): bounces@mail.yourdomain.com   (SPF checks mail.yourdomain.com)
From: Your Shop <orders@yourdomain.com>
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=pm; ...

SPF passes on mail.yourdomain.com, which relaxed-aligns with yourdomain.com. DKIM passes on d=yourdomain.com, which aligns exactly. DMARC therefore passes on two independent legs, which is exactly what you want for the mail you cannot afford to lose, because if one leg breaks in transit the other still carries it. If you are fuzzy on why one passing check is not enough, DMARC alignment explained and SPF vs DKIM, which aligns cover the mechanics.

Separate your transactional and marketing reputations

Shops should send transactional and marketing mail from different subdomains, and authenticate each independently. A typical split:

Receipts and order mail from mail.yourdomain.com or txn.yourdomain.com.
Marketing and flows from send.yourdomain.com or news.yourdomain.com via your ESP.

The reason is reputation. Marketing mail attracts complaints and unsubscribes; transactional mail almost never does. If they share a sending domain, a bad campaign can drag your receipts into spam folders. Splitting the subdomains keeps the reputations apart, and it lets you set a different DMARC subdomain policy for each if you want to ramp them at different speeds. The mechanics of subdomain policies are in the DMARC subdomain policy (sp) and subdomain DMARC records. Note that DMARC alignment is relaxed by default, so mail.yourdomain.com still aligns with a From of yourdomain.com; you do not have to change the visible address customers see.

Shipping and carrier mail: the sender you do not control

Tracking and delivery notifications are a special headache because they are frequently sent by a third party, a carrier or a fulfilment house, that puts your brand in the From line but sends from their infrastructure. If they send as noreply@yourdomain.com from servers you do not authenticate, those messages will fail DMARC the instant you enforce, and your "out for delivery" emails vanish.

You have three honest options, in order of preference:

Have the carrier send from their own domain, not yours. Many carriers will send tracking from tracking@carrierbrand.com with your shop name only in the display text. This sidesteps the problem entirely; it is their domain, their authentication.
Authenticate them as a sender on your domain, by adding their SPF include and publishing the DKIM key they provide, exactly as you would any other relay. Only do this if they support per-customer DKIM signing; many do not.
Route tracking notifications through your own relay, pulling tracking events via API and sending the email yourself from mail.yourdomain.com. This gives you full control and full alignment, at the cost of building the integration.

What you must not do is enforce DMARC while a carrier is still sending unauthenticated mail as you. Your aggregate reports will show the carrier's IPs failing alignment; that is your cue to fix the routing before you tighten the policy, not after. This is precisely the scenario reaching p=reject without breaking email is written to prevent.

The bulk-sender rules apply to most shops

Since February 2024, Gmail and Yahoo, with Microsoft following on Outlook.com, have enforced requirements for anyone sending more than 5,000 messages a day to their users. A moderately busy shop hits 5,000 in combined order confirmations, shipping notices and a single campaign without trying. Treat these rules as a hard floor, not an aspiration. The full breakdown is in the Gmail and Yahoo sender requirements and the dated summary in the 2024 to 2025 sender requirements; the short version for a shop is:

SPF and DKIM must both be set up and aligned. Not one or the other. Both, on your domain.
You must publish a DMARC record, even if it is only p=none to begin with. No DMARC record at all means rejection at the bulk-sender threshold.
One-click unsubscribe (RFC 8058, the List-Unsubscribe and List-Unsubscribe-Post headers) is mandatory on marketing and promotional mail. Your ESP should add this automatically; confirm it does.
Spam complaint rates must stay below 0.3%, ideally under 0.1%, measured in Google Postmaster Tools. This is a content and list-hygiene problem, but a shop with poor authentication tends to have worse complaint rates because legitimate mail gets mixed in with the spoofs.
Valid forward and reverse DNS on your sending IPs and a TLS connection for transport.

The crucial nuance for e-commerce: the 5,000-a-day threshold is per domain to that provider, and it counts all your streams together. Your transactional relay, your ESP and your reviews app all contribute to the same count against Gmail. You cannot satisfy the rules on the marketing stream and ignore the transactional one; every stream that uses your domain has to be authenticated and aligned. Check each stream individually with the SPF checker and DKIM checker, and confirm the unified picture with the DMARC checker.

A DMARC record that meets the floor and gives you reporting looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1; adkim=r; aspf=r

That is the starting point, not the destination. p=none satisfies the letter of the bulk-sender rule (a record exists), but it provides no protection against spoofing, which for a shop is the whole point of the exercise. The myth that p=none is a safe resting place is dismantled in the false security of p=none. You build this record with the DMARC generator and you plan the climb to enforcement using the enforcement journey.

Why shops are spoofed, and why p=reject is the goal

E-commerce brands are a favourite target for phishing precisely because customers are conditioned to act on shop emails. A fake "there is a problem with your recent order, click here to update your payment details" mail, sent from a spoofed orders@yourdomain.com, converts frighteningly well, because it arrives in the middle of a real buying relationship. If your domain has no enforced DMARC policy, anyone in the world can send that message with your exact From address and the mailbox provider has no instruction to stop it.

p=reject is the instruction. With an enforced policy, a spoofed message that does not carry your DKIM signature or come from your SPF-authorised hosts is rejected at the receiving server, before it reaches the customer. This is the difference between hoping customers spot the fake and making the fake undeliverable. For a shop, the spoofing you are blocking is not abstract; it is order-confirmation phishing, fake-refund scams and counterfeit "delivery fee" demands, all of which trade on your brand's credibility.

The path from p=none to p=reject for a shop is the careful one, because you have so many legitimate senders and you must not reject any of them. The disciplined sequence is:

Publish p=none with rua reporting and watch for a few weeks.
Use the aggregate reports to authenticate every legitimate sender you find: store platform, relay, ESP, reviews app, helpdesk, carrier. Fix alignment until reports show 100% pass for your real mail.
Move to p=quarantine, optionally with pct= sampling to ramp gradually, and watch again. Note that if mail still lands in the inbox at this stage it usually means the mailbox provider has overridden the policy, a wrinkle covered in DMARC quarantine but mail in the inbox.
Move to p=reject once reports are clean and stable.

Because the estate keeps changing (a shop adds a new app every quarter), this is not a one-time project. A new reviews integration or a switched ESP can reintroduce an unaligned sender overnight. That is why continuous monitoring with change alerts matters more for shops than for almost anyone else: you want to know the day a new IP starts sending as you, not the day a customer complains. The full requirements picture lives at the requirements page.

BIMI: putting your brand mark in the inbox

Once you are at enforcement, you can claim the prize that e-commerce cares about more than most: your logo, in a coloured circle, next to every message in supporting inboxes. That is BIMI (Brand Indicators for Message Identification), and it is genuinely valuable for a shop because it converts authentication into a visible trust signal at the exact moment a customer is deciding whether to open and click.

BIMI has hard prerequisites, and they are non-negotiable:

DMARC must be at enforcement. A policy of p=quarantine or p=reject is required; p=none will not display a logo. Gmail also requires the policy to apply to the whole domain with no weak pct sampling. This is why BIMI comes last: it is the reward for finishing the enforcement journey, not a shortcut.
A square SVG logo in the specific SVG Portable/Secure (SVG P/S, the Tiny 1.2 profile) format. A normal SVG export from your design tool will be rejected; it must be the constrained profile.
A Verified Mark Certificate (VMC) for Gmail and Apple Mail to actually show the logo. The VMC proves you own the trademark on the logo, which means the logo generally needs to be a registered trademark. This is a real cost and a real lead time, and for a small shop it is the main barrier. The trade-offs are laid out in do you need BIMI and the VMC glossary entry.

A BIMI record is a TXT record at default._bimi.yourdomain.com that looks like this:

v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/vmc.pem

The l= points to your SVG logo and the a= points to your VMC certificate. Both must be served over HTTPS. Before you commit to the certificate cost, validate the record and the logo format with the BIMI checker and the BIMI generator, and confirm the certificate side with the VMC checker. If your logo refuses to appear in Gmail after everything looks right, the usual culprits are catalogued in fixing a BIMI logo that will not show in Gmail.

For a shop, BIMI is worth doing after you reach p=reject, not as a vanity project before. The logo is only as trustworthy as the authentication behind it, and you cannot get the logo at all until the authentication is enforced. The sequence is the whole point: authenticate every sender, enforce the policy, then claim the brand mark.

MTA-STS: protecting the mail in transit

One more layer matters for a shop, and it is easy to overlook because it protects a different attack. SPF, DKIM and DMARC prove who sent a message. MTA-STS proves the connection delivering it was encrypted and not redirected. Without it, an attacker positioned on the network can strip the TLS from an inbound connection and read or tamper with mail destined for your shop, including password resets and order details.

MTA-STS publishes a policy that tells sending servers to require TLS and to refuse to deliver if a valid certificate is not presented. For an e-commerce brand handling customer data, this is part of basic transport hygiene. You set it up with a policy file and two DNS records, validate it with the MTA-STS checker, and the full walk-through is in the MTA-STS setup guide. If you hit the common "policy not found" error, that fix is documented too.

A practical order of operations for a shop

Putting the whole thing together, here is the sequence that gets an e-commerce domain from exposed to fully protected without breaking a single order email:

Inventory every sender. List the platform, relay, ESP, reviews app, helpdesk, carrier and staff mail. You cannot authenticate what you have not written down.
Publish p=none with reporting and read the aggregate reports for two to four weeks via the DMARC report analyzer.
Authenticate each sender so that SPF and DKIM both align on your domain, splitting transactional and marketing onto separate subdomains.
Fix the carrier and reviews-app gaps before enforcing, because these are the senders most likely to fail alignment.
Confirm you meet the bulk-sender floor: aligned SPF and DKIM, a DMARC record, one-click unsubscribe on marketing mail, complaint rate under 0.3%.
Ramp to p=quarantine, then p=reject, watching reports at each step.
Add MTA-STS for transport security.
Add BIMI with a VMC once you are at enforcement, to put your logo in the inbox.
Keep monitoring with change alerts, because the estate will change again.

The takeaway

Authenticating an online shop is less about understanding DMARC and more about wrangling a sprawling, constantly shifting estate of senders so that every order confirmation, shipping notice and receipt provably comes from you, and nothing else can. Get that right and you satisfy the Gmail, Yahoo and Microsoft bulk-sender rules as a side effect, you make order-confirmation phishing undeliverable, and you earn the right to show your brand logo in the inbox with BIMI. The work is methodical: inventory, monitor, align, enforce, then brand.

If you would rather not assemble all of this by hand across a dozen senders, that is exactly what DMARC Engine is built for. Start by running your domain through the DMARC checker and the BIMI checker to see where you stand, turn on monitoring with change alerts so a new sender never slips through unauthenticated, and let the done-for-you service take your shop safely from p=none to p=reject with no email outage. Your customers are waiting for that receipt; make sure it always arrives, and make sure only you can send it.