Shop email deliverability: setting up SPF, DKIM and DMARC

An order confirmation that fails to arrive produces no error in the shop. The order sits in the database, the payment is booked, your own mail server logs a clean handover – and two days later the customer gets in touch because nothing showed up. The failure happens behind your own infrastructure, at the receiving mailbox providers, and it leaves no trace visible inside the shop. The filtering pressure is documented by the providers themselves: Gmail states that it blocks close to 15 billion unwanted messages every day (Google, The Keyword). Against that noise, a transactional email gets through only with verifiable sender proof. SPF, DKIM and DMARC provide it – if they fit together. This article shows how the three interlock in the hosting setup of an online shop and where a record that has grown over the years typically breaks.

When the order confirmation disappears quietly

The filters a shop email has to pass are not a precaution but a response to volume. Germany's Federal Office for Information Security counted the traffic in the federal government networks: with an average of 712,000 incoming messages per day, the monthly average spam share stood at 51 percent (BSI Lagebericht 2025). 73 percent of the spam messages were cyber attacks: 58 percent fraudulent and 15 percent extortion messages (BSI Lagebericht 2025). Among the fraudulent messages, phishing accounted for 93 percent, including 49 percent finance phishing (BSI Lagebericht 2025). A mailbox provider that sees such distributions treats an unsigned message carrying a well-known trade name in the sender field as what it statistically tends to be.

During the reporting period, an average of around 712,000 emails arrived in the government networks each day. The monthly average of the daily spam rates was 51 percent.

BSI, The State of IT Security in Germany 2025

The same authority estimates the attack surface in Germany at a minimum of 150 million active email addresses (BSI Lagebericht 2025). The damage is measurable: the FBI's Internet Crime Complaint Center recorded reported losses of 3,046,598,558 US dollars for business email compromise in 2025 alone, and phishing or spoofing remained the most frequently reported crime type with 191,561 complaints (FBI IC3 2025). The Anti-Phishing Working Group observed 3.8 million phishing attacks during 2025, and in the fourth quarter attackers appeared under 866 different brand names (APWG Q4 2025). Brand abuse is the norm rather than the exception: anyone running a recognised shop domain has to assume it will surface in the sender field of other people's messages – and that filters will carry that experience over to your own order confirmation as long as nothing makes it distinguishable.

How well the mechanisms work in the field can be read from analysed message streams. More than 93 percent of the messages examined passed the SPF check, while for DMARC the figure was 86.5 percent, with 4.2 percent failing (Cloudflare Radar). The distance between the two figures is largely due to messages without a DMARC policy, and that is where the binding to the visible sender address is missing: SPF is in place, DKIM may be in place, but the alignment with it is not checked. In 2025, an average of 5.6 percent of the analysed messages were malicious, and deceptive links were the most common attack pattern at 52 percent, up from 43 percent the year before (Cloudflare Radar 2025). An email with an order number, an amount and a status link looks formally identical to an attack – the difference lies in the authentication, not the wording.

SPF: the allow list that quietly becomes invalid

SPF is a TXT record in the DNS of the sending domain. It lists the servers permitted to send on behalf of that domain, and the receiving server compares the IP address of the connection against it. What gets checked is not the address the customer sees in the mailbox but the envelope sender from the SMTP dialogue. That distinction is the reason a shop with an impeccable SPF record can still fail DMARC. For day-to-day operations it means the record has to cover every source that sends in the domain's name – shop system, ERP, newsletter platform, ticketing system, invoicing. Anyone connecting a new interface to a third-party system almost inevitably extends the list of sending servers.

• ip4 and ip6 name individual addresses or networks directly and trigger no further DNS query – the cheapest way to add a fixed sending path.
• include points to another provider's SPF record and adopts its authorisations. Each of these references costs at least one query, and nested references cost more.
• a and mx resolve names to addresses and likewise cost one query each. In records grown over years they often remain out of habit, long after those servers stopped sending.
• all closes the record. -all rejects everything else outright, ~all marks it softly; without a closing term the statement stays incomplete.
• redirect moves the entire evaluation to another domain and is easily overlooked in shops when the target zone is later rebuilt.

An SPF evaluation may trigger at most ten terms that query the DNS; going beyond that does not produce a worse result but an evaluation error (RFC 7208, Section 4.6.4). Queries that come back empty count towards the total: two of them are the permitted maximum, and only from the third one on should the evaluation end in a permerror (RFC 7208). On top of that, the receiver may abort the evaluation after a time limit which should allow at least 20 seconds (RFC 7208). The limit is rarely exceeded when the record is created, but months later, when a provider extends its own include record by one level. The shop changed nothing and suddenly sends unauthenticated. Microsoft points senders to the same threshold: above ten lookups an SPF check may fail (Microsoft Tech Community).

; Sending domain of the shop
shop.example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.20 ip4:198.51.100.21 include:dispatch.example.net -all"

; Separate subdomain for bulk sending
mail.shop.example.com. 3600 IN TXT "v=spf1 include:newsletter.example.net -all"

; Domain that never sends: block it explicitly
static.example.com. 3600 IN TXT "v=spf1 -all"

Two moves defuse the lookup limit for good. First, add known fixed addresses as ip4 or ip6 instead of pulling them in through a reference; that saves one query per source. Second, give domains that do not send at all their own record with a hard block instead of leaving them unregulated. Zone maintenance therefore belongs on a schedule like any other maintenance task on the shop system – with a fixed date and a documented state, not as a reaction to a complaint.

DKIM: signature, key length and rotation

DKIM works differently from SPF: instead of authorising a sender address, the sending server signs selected header fields and the message body with a private key. The matching public key sits as a TXT record under a selector in DNS, for example sw1._domainkey.shop.example.com; the receiver fetches it and recomputes the signature. Because the signature travels with the message rather than the connection, it survives forwarding as long as no intermediate system alters the text. That makes DKIM valuable for shops: order confirmations are frequently forwarded automatically into shared mailboxes, to accounting, to a connected point-of-sale system or to the tax adviser.

The numbers are unambiguous and leave little room. For RSA the rule reads: keys below 1024 bits are not permitted, and at least 2048 bits are intended (RFC 8301). The BSI additionally caps the length, limiting it to 2048 bits for practical reasons of interoperability (BSI TR-03182). Very long keys blow up the response size in DNS and are no longer evaluated cleanly by some receivers. A shop choosing between 1024 and 2048 bits takes 2048 – and checks afterwards whether the record is delivered as one string or breaks apart.

The second point is regularly overlooked in practice: a DKIM key is not a permanent state. The BSI requires renewal every six months; anyone who does not follow that has to document the deviation (BSI TR-03182). The change is only clean with two selectors. The new key is published while the old one still signs; the sending path then switches to the new selector; and the old record disappears only when no message in flight needs it. This sequence belongs in the same operating documentation as the deletion concept with its retention periods.

DMARC: from observation to policy

DMARC closes the gap that SPF and DKIM leave open. Both check values the customer does not get to see: the envelope sender and the signing domain. DMARC requires at least one of these to match the visible sender address – that is alignment – and tells the receiver how to handle messages where it does not. Since May 2026 this is no longer an informational document: RFC 9989 obsoletes the earlier RFC 7489 and RFC 9091 and puts DMARC on the standards track (RFC 9989). For shops that changes less in the record than in how binding the statement is.

; Entry point: observe without endangering delivery
_dmarc.shop.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@shop.example.com; adkim=r; aspf=r"

; Interim state: suspicious mail into the junk folder
_dmarc.shop.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@shop.example.com; adkim=s; aspf=r"

; Target state: rejection, reporting still active
_dmarc.shop.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@shop.example.com; adkim=s; aspf=s"

Two details of the new edition matter for shops with many subdomains. The policy is located through a tree walk that is capped at eight DNS queries (RFC 9989, Section 4.10). Place the policy high up rather than counting on it being found from five levels down. And the reporting address is not optional: under the BSI requirement, a DMARC policy has to designate at least one RUA address (BSI TR-03182). Without that address the shop operates blind – it does not learn which systems send in its name and which of them fail.

1. Take inventory. Note every source that sends in the domain's name: shop system, ERP, payment provider, ticketing, invoicing, marketing platform.
2. Start with p=none and collect reports. Four to six weeks usually captures seasonal flows such as return labels or annual statements.
3. Close the gaps. Every source gets either an SPF authorisation or a DKIM signature, ideally both, and in every case alignment with the visible sender domain.
4. Move to p=quarantine. From here unaligned mail lands in the junk folder instead of the inbox; the reports immediately show what was missed.
5. Go to p=reject. Only once the reports have shown no legitimate failures for several weeks. The BSI recognises exclusively quarantine and reject as a protective policy (BSI TR-03182).

What the large mailbox providers require

The standards describe how the mechanisms work. What a shop actually has to deliver is defined by the receivers. Since 1 February 2024, senders dispatching more than 5,000 messages per day to Gmail accounts fall under stricter requirements (Google Workspace Admin Help). For a shop in operation the threshold is not high: order confirmation, payment receipt, dispatch notice, return label and review request add up to five messages per order, so a thousand orders a day reach the limit without a single marketing message.

Two further requirements concern the process more than the technology. Large senders have to offer one-click unsubscription and process unsubscribe requests within two days (Google, The Keyword). How strongly such requirements work is already visible in the step before them: after Gmail made some form of authentication a requirement in 2022, the number of unauthenticated messages reaching recipients dropped by 75 percent (Google, The Keyword, October 2023). The unsubscribe logic belongs cleanly separated from the transactional path; how that interacts with a marketing automation setup decides the complaint rate.

Alignment, subdomains and the case of the sending service

Alignment is where most shops fail even though SPF and DKIM technically pass. DMARC knows two levels of strictness. Relaxed alignment accepts a shared organisational root; strict alignment demands identical domains. A shop dispatching through a service provider whose envelope sender sits on a foreign domain passes SPF – and fails DMARC, because the checked domain does not match the visible one. The way out is a dedicated sending subdomain whose envelope sender and DKIM signature both sit under the shop domain.

A separate subdomain has a second advantage that weighs more in daily operations than the technology: it separates reputation. Receivers judge transactional mail and marketing flows differently, and a campaign with a poor complaint rate should not drag the order confirmation down. The usual split is one subdomain for transactional sending and a second for marketing, each with its own SPF record and DKIM selector. If you would rather have the current state assessed independently first, our shop check provides the framework.

These four queries take less than half a minute and answer the questions that matter. Does the SPF record exist exactly once? Two records on the same domain are an evaluation error, not a compromise. Is the DMARC policy still set to observation although the rollout plan should have been completed long ago? And does the DKIM selector still deliver a key at all, or was it removed during the last provider change? Folded into the regular logfile analysis, a silent failure surfaces in days rather than quarters.

Transport encryption and the reports nobody reads

Authentication says who sent a message. It says nothing about whether the transport was encrypted. MTA-STS closes that gap: the domain publishes a policy instructing the sending server to deliver only over a validated TLS connection. The policy is cached, and the standard sets an upper bound of 31,557,600 seconds for that, roughly one year (RFC 8461). For operations this means two things: a certificate change has to take the policy into account, and a faulty policy keeps working against you for as long as the caches hold it. Publication therefore starts in testing mode and only goes enforcing once the reports have been evaluated.

The DMARC reports sent to the RUA address are the real operational value of the mechanism. They arrive as compressed XML files and list, per receiving organisation, which IP addresses sent in the domain's name, how many messages that was and whether SPF, DKIM and alignment passed. Reading them reveals three things at once: forgotten sending sources, forged senders and alignment errors after a system change. Unread, they leave you with a record but no control. Ten minutes a week is enough in quiet periods; after any change to the cloud infrastructure or a sending path, the next reports deserve a second look.

Separating marketing and transactional mail cleanly

Deliverability is not purely a technical question. An order confirmation is contractual information and may be sent without separate consent. As soon as it carries product recommendations, discount campaigns or a review request, the classification shifts. Under German competition law, advertising by electronic mail without express consent is not deemed an unreasonable nuisance only where four conditions are met together: the address was obtained in connection with the sale of goods or a service, it is used for the trader's own similar goods, the customer has not objected, and the customer is clearly informed of the right to object both when the address is collected and on every use (Gesetze im Internet, UWG).

• Transactional mail and marketing flows run over separate subdomains with their own reputation.
• The notice about the right to object appears when the address is collected and in every marketing message, not solely in the privacy policy.
• An unsubscribe takes effect with one click and is processed within two days (Google, The Keyword).
• The objection is stored technically where every sending system reads it – not only inside the marketing platform.
• The order confirmation stays free of marketing elements; the design of a transactional email follows a different logic than a campaign.

Deliverability as an operating task

German online retail most recently turned over 92.3 billion euros, and the online share of total retail stood at 13.5 percent (HDE Online-Monitor 2026). Every order confirmation in the junk folder generates a service enquiry, an avoidable cancellation or a delayed payment. The effort falls once during setup and afterwards as a small recurring task: rotate the selector, review the reports, add new sending sources, remove old ones. In regular operations – alongside patch levels, backups and IT security in e-commerce – it removes the one failure mode invisible from inside the shop. We set this chain up as part of shop hosting and take over the ongoing maintenance; an initial conversation clarifies which sending sources already exist.