Sign Up

More Than A Third of Swiss Companies Have Misconfigured Email Security

A recent Cyway study found a large number of Swiss companies have misconfigured email security. The often underestimated risk of misconfigured DMARC and how to fix it.

Cover Image for More Than A Third of Swiss Companies Have Misconfigured Email Security

Executive Summary

In a recent assessment, we measured the state of email security - specifically DMARC - in Switzerland. Institutions such as the NCSC [1] and FINMA [2] keep reporting email as a major attack vector. Alarmingly, we found that over a third of companies had inadequate configurations in place, often leaving organisations unnecessarily exposed, and allowing attackers to misuse their domains in spoofing attacks.

Only 32% of companies have DMARC fully enabled for their main email domain.

41% are in a state for which we recommend immediate action.

DMARC Policy Distribution

DMARC protects organizations from impersonation attacks - and thereby significantly reduces the risk of spoofing attacks. There is no reason not to have DMARC in place today.

Results Overview

Disabled policies

A DMARC policy p=none means that DMARC policy application is disabled for the domain. While SPF still is validated and DMARC reports are generated, the organization misses out on significant protection through DKIM signing and both SPF and DKIM alignment verification.

This policy setting is meant to be used temporarily in rollouts to generate visibility while making sure email continues to be delivered without business disruption. However, when left in place for too long, it can become a risk to the business - especially if a misconception of "we have DMARC in place and are therefore protected" creeps in.

DMARC policies p=none offers little to no protection and one must not develop a false sense of security.

Typical DMARC rollout timelines are 1-2months. With DMARC being an industry standard for years, there is little reason not to have it in place.

Transitional policies

A little under a third of companies (27%) have a DMARC policy p=quarantine configured. This too is a transitional policy, intended to be used briefly before transitioning into a full p=reject policy. It instructs receiving mail servers to quarantine emails failing DMARC rather than to reject them.

While we recommend transitioning to a reject policy as quickly as possible, typically 1-2 months, a p=quarantine policy offers significantly better protection than a p=none policy, as DMARC validations are actually applied. Users are much less likely to fall for spoofed messages they first need to release from quarantine.

Missing policies

16% of companies did not have any DMARC policy in place at all, 8% of which also did not have any SPF policy in place, or had an SPF policy set to disabled (SPF ?all/+all). This leaves the domains of these organisations highly susceptible to spoofing attacks.

Companies without DMARC but with a stringent SPF policy in place do get some protection, as sender domains are bound to specific server IPs. However, spoofing of the HEADER FROM field, the field displayed in email clients, and hence the most frequently attacked field, remains unprotected.

Conclusion

While 32% of organisations have DMARC fully enabled and another 27% have at least a transitional policy in place, 41% of organisations have insufficient DMARC configurations and are thereby unnecessarily exposed to spoofing attacks.

SPF and DMARC Policy Matrix

From a security economics perspective, the results are particularly striking: DMARC is a well-established, low-cost control with a very high risk-reduction potential, yet it is still not consistently deployed. This suggests that prioritization and attention, rather than budget or complexity, are the main limiting factors. In a time where many organizations invest heavily in advanced detection and response, these findings highlight how much risk often remains in the fundamentals.

We urge organisations on the right side of the matrix to prioritize a DMARC implementation as soon as possible.

Implementing DMARC

Implementing DMARC is a relatively simple process and can be divided into three steps:

  1. Visibility: Add a DMARC policy to your DNS records and start monitoring the reports
  2. Hardening: Based on the reports, identify senders and account for them in your policies
  3. Enable: Transition to a full p=reject policy

Many tools and services exist that can help you with this process. You can meaningfully improve your security posture with a minimal investment of time and effort.

Methodology

We assessed the main domains of the 207 companies in the SIX Swiss All Shares Index [3]. SPF and DMARC policies were retrieved over public DNS and evaluated with respect to their policy action. As DKIM cannot conclusively be assessed externally, we focused on SPF and DMARC and relevant misconfigurations that can already be identified by inspecting them alone. We chose this approach as it reflects the low effort high gain approach cybercriminal groups take in identifying their targets for ransomware attacks.

Questions & Answers

What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC [4]) is a protocol that allows organizations to verify the authenticity of email messages. It is a standard part of the email authentication framework and is used to protect against email spoofing and phishing attacks. DMARC is built on top of SPF and DKIM. It leverages results from SPF and DKIM, together with additional alignment checks to verify the authenticity of email messages.

Next to message authentication, DMARC also allows for reporting of authentication failures to the organization. This is useful for identifying and addressing issues with email transmission and can for example support the business in asserting marketing and sales messages are delivered without interruption. B2B email deliverability benchmarks [5] show that proper DMARC configuration has a significant impact on email deliverability.

As many internet technologies, DMARC has taken its time to gain adoption. However, it has now reached a maturity level at which it can be considered table stakes. Businesses should not unnecessarily risk attacks by not having DMARC in place.

What is SPF?

Sender Policy Framework (SPF [6]) is a domain-based email authentication protocol that allows organizations to verify the authenticity of email messages. It is a standard part of the email authentication framework and is used to protect against email spoofing and phishing attacks. While it is a important foundational component to email security, it is not sufficient on its own, but should be combined with DKIM and DMARC.

What about DKIM?

DomainKeys Identified Mail (DKIM [7]) is a key component of email security. It is a digital signature that is added to email messages for authentication purposes. Because of the way DKIM works, it is not possible to assess its setup conclusively externally. Looking at DMARC and SPF suffices, however, to identify the most significant misconfigurations. Naturally, implementing DKIM is part of the process in rolling out DMARC for an organisation. Once rolled out, it can effectively be monitored based on the DMARC reports.

How does DMARC interplay with other email protections?

DMARC gives the sending organisation a way to instruct receiving mail servers on how to handle emails that fail authentication. It is the receiving mail server, however, that ultimately decides whether and how what policy is applied, including potential additional local policies. Email providers often integrate additional protections to identify and block fraudulent or malicious email traffic, but DMARC gives them an additional, very robust, signal to do so.

My provider already verifies DMARC, so why should I publish a DMARC policy?

By publishing a DMARC policy, you are giving email servers receiving mail from your domain a way to verify the legitimacy of such messages. Verification, on the other hand, is the process of asserting incoming messages are legitimate on your end. As such, it might seem like DMARC policy publishing is not very important to the security of your organisation and mostly benefits others. However, publishing a DMARC policy gives you several important benefits:

  • Visibility into the authentication status of your messages: This allows you to track deliverability and identify misconfigurations, as well as to detect spoofing campaigns where your domain is being misused
  • Better deliverability of your messages: By virtue of your domain being more strongly protected, receiving mail servers grant you higher reputation scores, which helps keep your emails out of junk folders. In fact, Google (since 2024) [8] and Microsoft (since 2025) [9] both require DMARC to be in place for email campaigns to be accepted.
  • Protect your customers and partners: Without a DMARC policy in place, your customers and partners might be exposed to spoofed messages from your domain. This can damage your reputation as well as lead to damages. Setting DMARC in place improves your third party risk scoring.
  • Also direct spoofing protection: While most of your internal mail might not be routed over the public Internet, and hence might not need to be protected from spoofing, some fraction of it often is (think for example of SaaS applications that are used internally, for example for CRM, ERP, HR, etc.). A fraction is enough for attackers to leverage that potential gap to also spoof your domain toward your own internal users. With a DMARC policy in place, you can close that gap.

Other Phishing Vectors & What about Artificial Intelligence?

Several phishing vectors that do not rely on impersonating the target organisation's domain exist, for example email attacks using sibling domains, or also attacks over other channels, such as SMS or phone calls, increasingly leveraging also cloned voices. While such attacks need additional and different measures to prevent or detect them, DMARC is still fundamentally relevant as attackers often take the path of least resistance when attacking.

As DMARC is a well established technology providing high gain at little effort, we maintain that it is a good starting point for securing communication channels. Other additional measures can and should be taken in a layered approach.

References

  1. NCSC Weekly Review 17: https://www.ncsc.admin.ch/ncsc/en/home/aktuell/im-fokus/2025/wochenrueckblick_17.html
  2. Finma Risk Monitor 2025: https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/finma-publikationen/risikomonitor/20251117-finma-risikomonitor-2025.pdf
  3. SIX Swiss All Shares Index: https://www.six-group.com/en/market-data/indices/switzerland/equity/swiss-all-share.html
  4. DMARC RFC: https://datatracker.ietf.org/doc/html/rfc7489
  5. B2B Email Deliverability Benchmarks 2025: https://thedigitalbloom.com/learn/b2b-email-deliverability-benchmarks-2025/
  6. SPF RFC: https://datatracker.ietf.org/doc/html/rfc7208
  7. DKIM RFC: https://datatracker.ietf.org/doc/html/rfc6376
  8. Google DMARC Requirement: https://blog.google/products-and-platforms/products/gmail/gmail-security-authentication-spam-protection/
  9. Microsoft DMARC Requirement: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730