DMARC in 2025/2026: What Google, Yahoo, Microsoft and the BSI Now Require From Your Domain
For years DMARC lived on the IT backlog: nice to have, never quite urgent. That era is over. Between the bulk sender programs of Google and Yahoo, Microsoft tightening its rules for Outlook.com and the BSI naming SPF, DKIM and DMARC as state of the art, a recommendation has turned into a de facto requirement. If your domain still sends without an aligned, enforcing DMARC policy, you are paying for it in deliverability and in exposure to spoofing.
This guide bundles two things rarely combined cleanly in German speaking guidance: the concrete sender requirements of the three big mailbox providers and the BSI recommendation around TR-03182 and p=reject. You get the timeline, what SPF, DKIM and DMARC do together, and how to become compliant without breaking legitimate mail flow.
DMARC in 2025/2026 at a glance
TL;DR: DMARC is no longer optional. Since February 2024 Google and Yahoo require bulk senders to publish DMARC and align SPF or DKIM. Microsoft enforced equivalent sender requirements for Outlook.com from 5 May 2025, and Gmail moved toward hard rejection of non compliant bulk mail in November 2025. The BSI treats SPF, DKIM and DMARC as state of the art and recommends an enforcing policy of p=reject in TR-03182, which feeds into NIS2 compliance in the DACH region. The path to compliance runs from p=none over p=quarantine to p=reject, guided by aggregate reports.
A domain that authenticates properly is no longer ahead of the curve. It is doing the minimum that Google, Yahoo, Microsoft and the German regulator now expect. The real question is not whether to do DMARC, but how to reach an enforcing policy without blocking your own newsletters, invoices and ticket replies.
From recommendation to de facto requirement
The shift was driven by the mailbox providers, not by a new law. Google and Yahoo deliver mail to a very large share of all inboxes worldwide, so when they demanded authentication from bulk senders in early 2024, they set a global baseline. Spoofing thrives on unauthenticated domains, because anyone can forge the visible From address. SPF, DKIM and DMARC close that gap, so the providers made them a condition of good deliverability. The result reaches every organisation sending email, well before any regulator gets involved.
The timeline of requirements
The requirements did not arrive all at once. They stacked up over roughly two years, and each step raised the bar.
| Date | Who | What changed |
|---|---|---|
| February 2024 | Google and Yahoo | Bulk senders must publish DMARC and align SPF or DKIM, keep a low spam rate and offer one click unsubscribe |
| 5 May 2025 | Microsoft (Outlook.com) | Equivalent sender requirements enforced: SPF, DKIM and a DMARC record become a condition for reliable delivery to Outlook.com and Hotmail addresses |
| November 2025 | Google (Gmail) | Move toward hard rejection of non compliant bulk mail, so messages without proper authentication are bounced rather than merely filtered |
The direction is unmistakable. Each provider started with filtering, then moved toward outright rejection. A domain that was tolerated in 2024 may be rejected by late 2025.
What SPF, DKIM and DMARC do together
These three records are often lumped together, but each plays a distinct role and they only protect you as a set.
- SPF, the Sender Policy Framework, is a DNS record listing which mail servers may send for your domain. A receiver checks whether the connecting server is on that list.
- DKIM, DomainKeys Identified Mail, adds a cryptographic signature to each message. The receiver verifies it against a public key in your DNS, proving the message was authorised and not altered in transit.
- DMARC, Domain based Message Authentication, Reporting and Conformance, requires that SPF or DKIM align with the visible From address the recipient actually reads, tells receivers what to do on failure through a policy, and asks them to send aggregate reports.
On their own, SPF and DKIM validate envelope details recipients never see. DMARC ties authentication to the From address and adds the reporting loop that turns it into a working tool: you finally see who is sending in your name. The deeper mechanics are on the DMARC product page and in our DMARC record guide.
The BSI recommendation and TR-03182
In Germany the regulator has been clear for some time. The BSI, the Federal Office for Information Security, treats SPF, DKIM and DMARC as state of the art for email authentication. Its Technical Guideline TR-03182 describes how to deploy them securely and points beyond a passive setup toward an enforcing DMARC policy of p=reject. A record sitting permanently at p=none satisfies the letter of the mailbox provider rules but not the BSI recommendation, because it never actually blocks spoofed mail.
This matters beyond a single guideline. In the DACH region the NIS2 directive and the corresponding sections of the BSIG expect secured communication and protection against domain abuse as part of appropriate technical measures, and the same logic applies to the GDPR state of the art clause in Article 32. An enforcing DMARC policy is a concrete, auditable control that improves deliverability and strengthens your compliance position at once, which is why it has moved from the backlog to the must do list.
How to become compliant: from p=none to p=reject
The single biggest mistake is jumping straight to p=reject. Do that before you understand your own mail flow and you will silently bounce legitimate newsletters, invoices and helpdesk replies. The safe path is staged, and the aggregate reports drive every step.
Stage 1, publish SPF and DKIM. Cover every system that legitimately sends in your name: mailbox provider, marketing tools, CRM, ticket system, billing platform. Each must be authorised in SPF or sign with DKIM.
Stage 2, start DMARC at p=none with reporting. A record at p=none changes nothing about delivery, but asks receivers to send aggregate reports to an address you control. This is pure observation, with no risk to mail flow.
Stage 3, analyse the reports. They reveal every source sending under your domain, including ones you forgot and ones you never authorised. You use them to close gaps until all genuine traffic passes SPF or DKIM in alignment.
Stage 4, raise the policy. Once legitimate mail passes cleanly, move to p=quarantine, where failing mail lands in spam. After a stable observation period, move to p=reject, where failing mail is refused outright. This is the enforcing state the BSI recommends and the strongest protection against spoofing of your domain.
The reporting step is the part most teams underestimate, because the raw XML is hard to read and the volume is high. That is exactly where tooling earns its place.
Conbool DMARC: report aggregation and a guided rollout
The hardest part of DMARC is not publishing a record. It is making sense of the flood of aggregate report XML so you can reach p=reject with confidence instead of guessing. Conbool DMARC is built for exactly that: it collects the aggregate reports for your domain, turns the raw XML into a readable view of who sends in your name, and shows which sources already align and which still fail. The path to enforcement becomes a managed process rather than a leap of faith, with the reports backing every move from p=none to p=quarantine to p=reject.
Authentication is only one layer. It pairs naturally with inbound protection through Conbool MailGuard, which adds phishing protection and defence against CEO fraud that an enforcing DMARC policy on its own does not cover. To see where your domain stands today, the free email security check gives you a baseline before you start.
Frequently asked questions
Has DMARC been mandatory since 2024?
There is no single law that names DMARC as universally mandatory. In practice it has become a de facto requirement. Since February 2024 Google and Yahoo require bulk senders to publish a DMARC policy and to align SPF or DKIM, and Microsoft followed for Outlook.com. A domain without DMARC risks that legitimate mail to large mailbox providers is filtered or rejected, which makes the standard effectively unavoidable for any organisation that sends email.
What exactly do Google, Yahoo and Microsoft require?
The core requirements are aligned. A sender must publish valid SPF and DKIM records, sign outbound mail with DKIM and publish at least a DMARC record with policy p=none. SPF or DKIM must align with the visible From domain. For bulk senders the providers also expect a low spam rate and a working one click unsubscribe. Google and Yahoo applied these rules from February 2024, Microsoft enforced equivalent sender requirements for Outlook.com from 5 May 2025, and Gmail moved toward hard rejection of non compliant bulk mail in November 2025.
What does the BSI recommend for email authentication?
The BSI treats SPF, DKIM and DMARC as state of the art for email authentication. Its Technical Guideline TR-03182 describes their secure deployment and points toward an enforcing DMARC policy of p=reject rather than a passive p=none. In the DACH region this feeds directly into compliance frameworks such as NIS2 and the corresponding sections of the BSIG, where secured communication and protection against domain spoofing are expected as part of appropriate technical measures.
How do I make my domain compliant with DMARC?
You move through three stages. First publish SPF and DKIM, then add a DMARC record with p=none and a reporting address so you collect aggregate reports without affecting delivery. Next analyse those reports to identify every legitimate sending source, including marketing tools and ticket systems, and fix any alignment gaps. Once all genuine traffic passes, raise the policy to p=quarantine and finally to p=reject. The reports are the key, because they show whether enforcement is safe before you switch it on.
What happens without DMARC, SPF and DKIM?
Without these records your domain can be spoofed freely, which makes phishing and CEO fraud in your name far easier. Legitimate mail also suffers, because large mailbox providers increasingly filter or reject messages from domains that do not authenticate. You lose deliverability, you lose visibility into who sends in your name and, in a regulated DACH environment, you weaken your position on appropriate technical measures under frameworks such as NIS2 and the GDPR state of the art clause.
Conclusion
DMARC has crossed the line from recommendation to requirement for two reinforcing reasons. The mailbox providers made it a condition of deliverability, and the BSI made it a marker of state of the art. A domain that authenticates with an enforcing p=reject policy reaches inboxes reliably and is far harder to spoof. A domain that does not is quietly losing mail and leaving its name open to abuse.
The next step is yours. Check where your domain stands with the free email security check, then see how Conbool DMARC turns the flood of report XML into a guided path from p=none to p=reject.
Further reading:
