Zum Inhalt springen
Proactive security updates
E-Mail-Zustellbarkeit

DMARC 2026: Reliable Email Delivery for Online Shops

Bulk-sender rules from Google, Yahoo and Microsoft: SPF, DKIM and DMARC decide the delivery of shop mails - and how to raise DMARC safely to p=reject.

13 min read DMARCSPFDKIME-Mail-ZustellbarkeitTransaktionsmails

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.

DMARC 2026: Reliable Email Delivery for ShopsFrom monitoring to enforcement - so transactional mail reaches the inboxThree building blocks in DNSSPFauthorized sending servers (DNS TXT record)DKIMcryptographic signature per messageDMARCties SPF and DKIM together via alignment (DMARC.org)The DMARC rollout pathAggregate reports (rua) reveal every sending sourcep=nonemonitorp=quarantinespam folderp=rejectblockWithout clean authenticationSPF, DKIM or DMARC fail - messages getrejected or sorted into the spam folderOrder and shipping mails are lostWith SPF + DKIM + DMARCAuthentication passes and alignment matches -transactional mail reaches the inboxDeliverability stays stable5,000 per daybulk-sender threshold (Google)0.30%max. spam rate at Gmail (Google)Feb 2024Gmail/Yahoo enforcement (Google)May 2025Outlook enforcement (Microsoft)

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?

Transactional mails are automatically triggered messages around a process: order confirmation, payment confirmation, invoice, shipping and tracking notification, password reset or account change. They are indispensable to the business flow and expected by the customer - which is why losing them to the spam folder weighs especially heavily.

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.

RequirementGoogle and YahooMicrosoft Outlook
Thresholdfrom 5,000 messages per day (Google sender guidelines)from 5,000 messages per day (Microsoft sender requirements)
SPF and DKIMrequiredrequired
DMARCat least p=noneat least p=none
Spam ratebelow 0.30 percent (Google sender guidelines)keep low, list hygiene
On violationfiltering or rejectionjunk, then rejection 550 5.7.515 (Microsoft sender requirements)
In force sinceFebruary 2024 (Google sender guidelines)5 May 2025 (Microsoft sender requirements)

Smaller shops are affected too

The 5,000-message threshold looks high, but order, shipping and newsletter mails add up faster than expected, and the limit refers to individual receiving providers. Independently of that, the large providers increasingly treat clean authentication as a trust signal even for smaller senders. A correct SPF, DKIM and DMARC setup is therefore not a question of size but of basic hygiene.

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

Many failed DMARC checks are not due to missing SPF or DKIM but to the checked domain not matching the visible sender address (DMARC.org). Anyone using external services for shipping, payment or newsletters must integrate each of these senders cleanly into SPF and DKIM - otherwise the chain breaks at a point that is barely noticeable in daily operation.

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.

  1. Fully set up SPF and DKIM records for all sending systems
  2. Publish DMARC with p=none and a report address (rua)
  3. Evaluate aggregate reports over several weeks and integrate every legitimate source
  4. Switch to p=quarantine and watch whether real mail is wrongly sorted out
  5. Raise to p=reject only after stable reports
  6. Re-check after every change to sending, DNS or service providers

Aggregate reports are required reading

The rua reports are machine-readable XML files that summarize, per receiving provider, how many messages passed or failed SPF, DKIM and DMARC. Without their ongoing evaluation, a switch to p=quarantine or p=reject is flying blind - which is why report monitoring belongs permanently in maintenance and not only in the initial setup.

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.

Managed Service Agency

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

This article is based on data from: Google sender guidelines (email sender guidelines for bulk senders), Microsoft sender requirements (Outlook requirements for high-volume senders), BSI Technical Guideline TR-03182 (Email Authentication), DMARC.org (specification and deployment recommendations for SPF, DKIM and DMARC) and Bitkom (Cybercrime 2025 and Digital Commerce 2025). The figures cited can vary by industry, shop size, services used and infrastructure.