An order confirmation that lands in the spam folder is more expensive for an online shop than it looks: the customer is unsettled, contacts support or cancels - and may well order elsewhere next time. Since Google and Yahoo introduced binding rules for bulk senders in early 2024 and Microsoft followed in May 2025, it is no longer the content of a message alone that decides its delivery, but the technical sender check made up of SPF, DKIM and DMARC. If one of these is missing or faulty, it is precisely the business-critical transactional mails - order, payment and shipping confirmations - that end up in spam or are rejected outright. This guide shows how to set the DNS records correctly, how to raise DMARC step by step from p=none to p=reject, and why evaluating the aggregate reports as part of ongoing security updates matters so much.
Why Shop Mails End Up in Spam in 2026
E-commerce runs on trust, and trust also grows from the seemingly trivial question of whether an email arrives at all. 96 percent of internet users in Germany bought something online in the past twelve months (Bitkom, 2025), and when choosing a shop 51 percent name security and trust as a very important criterion (Bitkom, 2025). Every order confirmation that fails to arrive works directly against that trust.
Unlike a newsletter, a transactional mail is not optional. It confirms a purchase, delivers a payment request, an invoice, a tracking number or a password reset token. If it lands in spam, a concrete problem arises immediately: the customer thinks the order failed, the payment link is not seen, the return is delayed. The result is support tickets, payment shortfalls and cancellations - costs that go far beyond the technical effort of clean authentication.
The backdrop to the new rules is a real threat landscape. 61 percent of internet users fell victim to cybercrime in the past year, 36 percent were defrauded during an online purchase and for 30 percent attackers obtained personal data via message, mail or phone call through phishing (Bitkom, 2025); the average loss was 219 euros (Bitkom, 2025). Forged sender addresses - emails that appear to come from a reputable shop - are a central tool in these attacks. This is exactly where email authentication comes in: it lets receiving servers verify whether a message really originates from the domain it claims.
What counts as a transactional mail?
The New Rules from Google, Yahoo and Microsoft
Google and Yahoo went first. Since February 2024, both have enforced binding requirements for so-called bulk senders - senders that send more than 5,000 messages per day to Gmail addresses (Google sender guidelines). These senders must set up SPF and DKIM and additionally publish a DMARC record with at least the policy p=none (Google sender guidelines). Two further obligations apply: the spam rate reported in Postmaster Tools must stay below 0.30 percent, with a value below 0.10 percent recommended (Google sender guidelines), and marketing and subscribed messages must offer a one-click unsubscribe that is honored within two days (Google sender guidelines).
Microsoft followed in May 2025. Since 5 May 2025, domains that send more than 5,000 messages per day to Outlook, Hotmail and Live addresses face the same three pillars of SPF, DKIM and DMARC (Microsoft sender requirements). Non-compliant messages were initially routed to the junk folder; for persistently non-compliant senders, rejection with error code 550 5.7.515 is provided for (Microsoft sender requirements). With that, the three largest mailbox providers have effectively established a common minimum standard that no growing shop can bypass.
| Requirement | Google and Yahoo | Microsoft Outlook |
|---|---|---|
| Threshold | from 5,000 messages per day (Google sender guidelines) | from 5,000 messages per day (Microsoft sender requirements) |
| SPF and DKIM | required | required |
| DMARC | at least p=none | at least p=none |
| Spam rate | below 0.30 percent (Google sender guidelines) | keep low, list hygiene |
| On violation | filtering or rejection | junk, then rejection 550 5.7.515 (Microsoft sender requirements) |
| In force since | February 2024 (Google sender guidelines) | 5 May 2025 (Microsoft sender requirements) |
Smaller shops are affected too
SPF, DKIM and DMARC Explained Clearly
The three building blocks interlock but check different things. Once you understand them, it quickly becomes clear why none is enough on its own and why only their interplay produces a robust sender check.
SPF - who may send
The Sender Policy Framework is a DNS TXT record that defines which servers may send email on behalf of your domain. The receiving server checks whether the sending IP address is on that list.
DKIM - unchanged in transit
DomainKeys Identified Mail adds a cryptographic signature to every message. The public key sits in DNS; with it the recipient verifies that the mail really comes from the domain and was not altered in transit.
DMARC - the bracket
DMARC connects SPF and DKIM via so-called alignment and defines what happens to messages that fail the check (DMARC.org). It additionally requests reports that make every sending source visible.
The often overlooked point is alignment. It is not enough for SPF or DKIM to somehow pass - the domain checked in the process must also match the visible sender address (DMARC.org). This alignment is exactly why an email can fail DMARC despite a valid SPF or DKIM signature, for instance when a payment or shipping provider sends on behalf of the shop without being correctly integrated.
Alignment is the real sticking point
The Path from ==p=none== to p=reject
Jumping straight to the strictest setting is the most common mistake. DMARC is deliberately designed as a staged path: from pure monitoring through an intermediate stage to full enforcement (DMARC.org). It begins with p=none. At this stage nothing happens to delivery - the receiving server takes no action but sends aggregate reports back to the address stored in the record. These reports show for the first time in full which servers actually send in the name of the domain, and they uncover forgotten or unintegrated sources.
Once all legitimate senders are identified and integrated into SPF and DKIM, p=quarantine follows. Now DMARC asks receiving servers to move unauthenticated messages to the spam folder (DMARC.org). This stage is the first real protection against abuse of your own domain and at the same time a safety net: should a legitimate source still have been missed, its mail lands in spam instead of vanishing, and the error becomes visible in the reports.
At the end stands p=reject. Unauthenticated messages are already rejected during delivery (DMARC.org). Only this stage effectively protects the brand against forgeries, because a phishing mail sent in the name of the shop no longer reaches the recipient at all. The path there should not be rushed, however: every step up requires that the reports no longer show any legitimate source as failing.
- Fully set up SPF and DKIM records for all sending systems
- Publish DMARC with p=none and a report address (rua)
- Evaluate aggregate reports over several weeks and integrate every legitimate source
- Switch to p=quarantine and watch whether real mail is wrongly sorted out
- Raise to p=reject only after stable reports
- Re-check after every change to sending, DNS or service providers
Aggregate reports are required reading
Securing delivery is part of a bigger picture. Locking out forged senders also protects customer communication against fraud attempts - a concern that combines with protecting the payment page against skimming attacks at checkout and with orderly CVE and patch management into a coherent security concept.
BSI TR-03182: the German framework
For the German-speaking region, Technical Guideline TR-03182 from the Federal Office for Information Security provides a clear framework. Its stated goal is to promote the adoption of SPF, DKIM and DMARC and thereby protect email recipients from identity abuse, spam and phishing (BSI, TR-03182 Email Authentication). The guideline describes the three methods as a coherent bundle and recommends a DMARC policy of at least the quarantine level (BSI, TR-03182 Email Authentication).
Formally, TR-03182 is aimed first at authorities and operators of critical infrastructure, but the state of the art it describes serves as guidance for all organizations that send email. For an online shop this means the bulk-sender rules of the large providers and the official framework point in the same direction. Whoever operates SPF, DKIM and DMARC cleanly and raises the policy step by step not only meets the requirements of Gmail and Outlook but also follows a recognized German guideline.
Why Authentication Breaks Silently
The most unpleasant property of email authentication is that it fails quietly. A configuration set up correctly once does not stay correct forever, because the environment around it changes constantly. The shop switches newsletter services, a new payment provider sends receipts, DNS is migrated, an SPF record exceeds a technical limit, or a DKIM key is rotated and the new public part is not stored in DNS. In all these cases the messages suddenly no longer pass the check - without any error message appearing in the shop.
New sending service
An additional service for newsletters, receipts or support sends in the name of the domain but is not listed in SPF and DKIM - its mails fail DMARC.
DNS migration or change
When switching providers or reconfiguring, TXT records are lost or not carried over, so SPF or DMARC is simply missing.
Rotated DKIM key
If the signing key is renewed but the new public key is not published in DNS, the DKIM check fails for all messages.
Overloaded SPF record
SPF allows only a limited number of DNS lookups. Too many integrated services exceed this limit, and the record becomes invalid.
Because none of these breaks becomes visible in the shop itself, it often goes unnoticed for weeks - until support tickets or a drop in open rates raise suspicion. This is precisely why the one-time setup is only the beginning; what matters is the ongoing monitoring of the reports, which makes such a break visible within a few days.
Email authentication that no one monitors is like a smoke detector without a battery: on the day it matters, no one raises the alarm.
Ongoing Monitoring Instead of One-Time Setup
From these properties follows the actual core: email deliverability is not a task you complete once but an ongoing process. In a maintenance contract it can be represented as a fixed part of ongoing security updates. The DNS records are regularly reconciled against actual sending, the aggregate reports are evaluated, and every change to services or infrastructure triggers a fresh check. This continuous care is part of our maintenance services.
With that, email authentication fits the same logic as the rest of a shop's ongoing monitoring. Just as availability, TLS certificates and security patches are continuously watched, deliverability belongs in the fixed maintenance rhythm too. An SLA maintenance contract can bindingly record who evaluates the reports, at what cadence checks happen and how quickly a detected break is addressed.
Evaluate reports
The rua reports are read and evaluated regularly, so new or failing sending sources stand out early.
Safe stage increases
The path from p=none through quarantine to p=reject is accompanied and taken only after stable reports.
Check after changes
After every change of services, DNS or infrastructure, authentication is verified anew.
Brand protection
Once enforcement is reached, forgeries sent in the name of the shop no longer reach recipients.
Delivery in view
Conspicuous changes in delivery and spam classification are detected before they hit revenue.
Documented state
Configuration and changes are recorded traceably - a basis for audits and operations.
- Set up SPF, DKIM and DMARC for all sending systems and check alignment
- Publish DMARC with a rua report address and evaluate the reports regularly
- Raise the policy step by step from p=none through quarantine to p=reject
- Re-verify after every change to sending, DNS or service providers
- Continuously watch spam rate and delivery
- Document configuration and adjustments
Securing delivery is therefore not a one-off project but a building block in ongoing operations - closely interlocked with the rest of maintenance, from server hardening through accessible design under the BFSG to the orderly handling of incidents. A shop whose order and shipping confirmations reliably arrive protects not only its revenue but also the trust that ranks among the most important criteria for 51 percent of online shoppers (Bitkom, 2025).
Sources and studies