Swiss Email Security Report 2026

7 in 10 Swiss email domains do not effectively protect against sender spoofing

An analysis of published email protection settings across 2'459'127 .ch domains.

· Peter Hadorn

An email’s sender address can be forged. The message can then appear to come from a company, a public authority or someone the recipient knows. This makes fake invoices, payment requests and phishing links more convincing.

Key findings

For the sender-spoofing results, 1'700'148 .ch domains examined form the 100% base. They are configured to receive email.

  • 1'190'194 domains (70.01%) do not effectively protect against sender spoofing.
  • Only 226'957 domains (13.35%) request that emails with forged sender addresses be rejected.
  • The figures show whether a safeguard is published. They do not show that an organisation has been attacked or hacked.

Download data and charts.

DMARC: how does protection against sender spoofing work?

DMARC connects the visible sender address with the SPF and DKIM checks. SPF checks whether a server may send for a domain. DKIM checks a message’s digital signature. To pass DMARC, at least one of these checks must succeed, and the domain it authenticates must match the visible sender domain under the alignment rules. This relationship is called alignment.

The p= value lets the domain owner request how messages that fail DMARC should be handled. This helps prevent misuse of the domain as a sender. It does not prevent lookalike domains or forged display names.

DMARC: which protection policies are published?

p=reject requests rejection. It was detected for 13.35% of the email domains examined. p=quarantine requests suspicious handling, for example moving a message to spam. This value was published by 16.65%.

p=none requests no special handling based on DMARC. This applies to 12.91%. Other spam filters may still act. For 57.07%, no DMARC record was found. For about another 0.03%, the p= value was missing or its content was not recognised. Together they account for 57.10%.

DMARC: published protection policies

Base: 1'700'148 examined domains with a non-empty MX record. Each full bar represents 100%.

p=rejectRequest rejection when the DMARC check fails226'957 domains13.35%
p=quarantineRequest suspicious handling, for example delivery to spam282'997 domains16.65%
p=noneRequest no special handling based on DMARC219'494 domains12.91%
DMARC record missing or p value not recognised57.07% without a record. About 0.03% without a recognised p value970'700 domains57.10%

Published requests, not measured delivery. Records were not fully validated.

Download chart (PNG) · Vector graphic (SVG)

The 57.10% without a recognised protection policy and the 12.91% with p=none add up to 70.01%. The methodology explains what the scanner records and its limitations.

What did we examine?

2'459'127
.ch domains examined
2'316'512
analysed (94.2% of the complete domain list)
142'615
not evaluable (5.8% of the complete domain list)
1'700'148
configured to receive email (73.39% of analysed domains)

Source: SWITCH .ch zone snapshot. Domains without evaluable results are excluded from substantive percentages, not counted as unprotected. Unless stated otherwise, SPF, DKIM and DMARC percentages refer to domains with a non-null MX record.

Show detailed table
Counts, denominators, populations and measurement limits.
MetricResultCountComparison baseGroup examinedWhat the figure means
No effective block against forged senders70.01%1'190'1941'700'148configured to receive emailNo supported rule detected, or a rule requesting neither quarantine nor rejection.
p=reject: Request rejection when the DMARC check fails13.35%226'9571'700'148configured to receive emailPublished request to reject messages. Actual delivery was not tested.
SPF record present86.75%1'474'9061'700'148configured to receive emailRecord detected. References to other SPF lists were not fully checked.
DKIM selector detected20.15%342'5081'700'148configured to receive emailSearch used known names. Other records may remain undetected.
DNSSEC: DS record for authenticating domain information53.84%1'247'3132'316'512analysedRecord presence only; no cryptographic DNSSEC validation or functional DANE test.

SPF and DKIM: sending authorisation and digital signatures

SPF lists the servers allowed to send email for a domain. It can explicitly exclude all other servers or describe them as probably unauthorised. -all produces Fail for other servers, while ~all produces Softfail. These are SPF check results, not guarantees of rejection by the recipient. SPF alone does not fully protect the sender address that readers see. References to other SPF lists were not fully checked.

For 19.33%, no all mechanism was detected. That does not automatically make the setting incorrect: redirect= can point to another domain’s SPF rule. If both all and redirect= are absent and no other mechanism matches, the result is Neutral. SPF then confirms neither authorisation nor lack of authorisation.

DKIM is a digital signature for email. It helps recipients check which domain signed a message and whether the signed content is unchanged. Finding a DKIM key requires a name called a selector. The scanner queried known selectors used by email providers. It found a record for 20.15% of the email domains examined. Because this search does not cover every possible selector, the actual share may be higher.

SPF and DKIM: detected settings

Base: 1'700'148 examined domains with a non-empty MX record. Each full bar represents 100%.

SPF record presentAuthorised sending servers are published1'474'906 domains86.75%
SPF -all: FailOther servers are described as unauthorised571'967 domains33.64%
SPF ~all: SoftfailOther servers are considered probably unauthorised486'459 domains28.61%
SPF without an all mechanismA redirect is possible. This does not establish a lack of protection328'576 domains19.33%
DKIM selector detectedPublic verification key found through a known selector342'508 domains20.15%

Categories overlap. SPF references were not fully followed. DKIM detection is a lower bound.

Download chart (PNG) · Vector graphic (SVG)

Technical details of the DKIM search

The next two figures describe detected DKIM records. Their base is the domains with a detected selector. For 31.65%, a short encoded key value was stored. This does not establish a vulnerability. The length check does not distinguish RSA from Ed25519, for which short values can be valid. A testing flag was detected for 7.44%. The flag does not establish that a test was actually running.

MX: which email providers can be identified?

Providers are assigned using recognisable patterns in mail server names. This does not establish exact market shares or provider security. Nor does it reliably identify who actually operates a mail server.

MX: classification by mail server names

Base: 1'700'148 examined domains with a non-empty MX record. Each full bar represents 100%.

HostpointHostname pattern detected348'340 domains20.49%
InfomaniakHostname pattern detected178'072 domains10.47%
Microsoft 365Hostname pattern detected160'129 domains9.42%
Google WorkspaceHostname pattern detected59'683 domains3.51%
Unassigned / possibly self-hostedNo provider pattern assigned432'455 domains25.44%
Other categoriesOther patterns assigned by the scanner405'385 domains23.84%
Unknown / not recognisedNo recognised assignment0 domains0.00%

Not market shares or security ratings. Hostname patterns do not establish the actual operator.

Download chart (PNG) · Vector graphic (SVG)

Show detailed table
Assignment by recognisable patterns in mail server names. Each row uses domains with MX records as its base.
Identified email providerCountShareComparison baseGroup examinedWhat the figure means
Unassigned / potentially self-hosted432'45525.44%1'700'148configured to receive emailAssignment by mail server name. This does not establish market share, security or the actual operator.
Unknown / not recognised405'38523.84%1'700'148configured to receive emailAssignment by mail server name. This does not establish market share, security or the actual operator.
Hostpoint348'34020.49%1'700'148configured to receive emailAssignment by mail server name. This does not establish market share, security or the actual operator.
Infomaniak178'07210.47%1'700'148configured to receive emailAssignment by mail server name. This does not establish market share, security or the actual operator.
Microsoft 365160'1299.42%1'700'148configured to receive emailAssignment by mail server name. This does not establish market share, security or the actual operator.
Google Workspace59'6833.51%1'700'148configured to receive emailAssignment by mail server name. This does not establish market share, security or the actual operator.
Other hostname categories116'0846.83%1'700'148configured to receive emailAssignment by mail server name. This does not establish market share, security or the actual operator.

DNSSEC and transport: which records are present?

Other records concern the protection of domain information, certificates and encryption during email transport. Some announce error reporting or point to a sender logo. The table shows whether these records were present. We did not test whether the protections work, certificates are valid, logos are displayed or reports are sent.

DNSSEC and transport: detected records

DS uses 2'316'512 analysed domains. The other figures use 1'700'148 domains with MX records. Each full bar represents 100% of its group.

DNSSEC: DSLink used to authenticate DNS information1'247'313 of 2'316'512 domains53.84%
DANE: TLSAInformation for checking the mail server certificate652'997 of 1'700'148 domains38.41%
MTA-STS: TXTPointer to rules for encrypted email transport2'534 of 1'700'148 domains0.15%
TLS-RPT: TXTDetails for reporting transport problems2'728 of 1'700'148 domains0.16%

Records only. DNSSEC, DANE, HTTPS policies and report delivery were not functionally tested.

Download chart (PNG) · Vector graphic (SVG)

Show detailed table
Each figure shows the domain count, comparison base and measurement limits.
DNS recordResultCountComparison baseGroup examinedWhat the figure means
DNSSEC: DS record for authenticating domain information53.84%1'247'3132'316'512analysedOnly record presence was measured. DNSSEC and DANE operation was not tested.
DANE: TLSA record for checking the mail server certificate38.41%652'9971'700'148configured to receive emailOnly record presence was measured. DNSSEC and DANE operation was not tested.
MTA-STS: DNS pointer to encrypted transport rules0.15%2'5341'700'148configured to receive emailRecord detected. Its operation was not tested.
TLS-RPT: DNS record for reports on transport problems0.16%2'7281'700'148configured to receive emailRecord detected. Its operation was not tested.
BIMI: DNS pointer to a sender logo0.08%1'3121'700'148configured to receive emailRecord detected. Its operation was not tested.
CAA: permitted certificate issuers specified1.50%25'4911'700'148configured to receive emailRecord detected. Its operation was not tested.

What this report does not measure

  • Actual delivery or spam filtering
  • Phishing incidents, data breaches or compromised mailboxes
  • Security or quality of individual organisations or providers
  • Exploitability of unresolvable mail-server names

How we measured

The report examines public settings for .ch domains. The measurement program looked up domain settings in the public DNS directory. It sent no emails, opened no mailboxes and did not assess individual companies.

Measurements ran from 21 to 23 August 2026, using a fixed list of .ch domains from 12 April 2026. Domains registered after that date are not all included.

For 142'615 domains, no usable response was obtained. They were not counted as unprotected and are excluded from the findings. These domains may differ from those we could analyse. The findings therefore cannot simply be applied to them.

The program recognises certain information in published DMARC rules. It does not fully check whether those rules are valid. If several rules are present, it may select the first. It also does not discard every incorrect or repeated setting. The percentages reflect what this method could detect.

A rule that applies to only some emails does not prove complete protection. The p=none setting also does not show whether reports are set up or read.

Technical terms explained

  • DNS: the public directory of technical information about a domain.
  • MX: names the servers intended to receive email for a domain. Without this record, a domain can still send email and, in some cases, receive it.
  • SPF: lists the servers allowed to send email using a domain.
  • DKIM: adds a digital signature to outgoing emails.
  • DMARC: tells recipients what they are asked to do when an email’s sender cannot be confirmed.
SourceSWITCH .ch zone snapshot (2026-04-12)
Measurement interval (UTC) –
MethodOnly public DNS services were queried. There were no connections to websites or mail servers, no searches for open ports, no login attempts and no emails sent to the domains examined.
DNS services used1.1.1.1, 8.8.8.8, 9.9.9.9, 1.0.0.1, 8.8.4.4
Code and methodologyswiss-email-security-report
PublicSummary figures, charts, code and verification documents.
PrivateDomain lists and results for individual domains.

Interpretation limits

  • The DKIM search uses known names from email providers. It may miss other names. The actual number of domains using DKIM may therefore be higher.
  • Keys were assessed only by the length of their encoded form, not by testing their security. Valid keys using the Ed25519 method can be short and may be flagged by this length check.
  • References to other lists in SPF rules were not all followed.
  • For MTA-STS, we checked only whether a DNS record was present. We did not retrieve the rule published on the corresponding website.
  • The results combine findings from many domains. They do not assess individual organisations.

Corrections and methodology questions:

Cite this report

Hadorn, P. (2026). Swiss Email Security Report 2026. WebEvolve.ch.
https://webevolve.ch/en/studies/swiss-email-security-report/
Archived dataset (v2026.08.2), DOI: 10.5281/zenodo.22116736

Download data and charts

Download the summary results and charts for reuse. Only totals and percentages are public, not domain lists or results for individual domains.

Download data (CSV)
Download data (JSON)

Source code and methodology on GitHub
Dataset on Zenodo

You may reuse the data and charts under CC BY 4.0. Credit Peter Hadorn / WebEvolve, link to this study and indicate any changes.

Charts for the findings

The charts appear in their respective chapters. You can download each one there as PNG or SVG.

Corrections and questions

Found an error? Write to hallo@webevolve.ch.

Identify the affected number or file and explain the discrepancy with evidence we can check. We review reports and document confirmed corrections. Changes to measurements are published as a new version. Previous versions remain accessible and citable. Files archived on Zenodo are not silently replaced.

Do not publish raw data about individual domains. We answer questions about individual domains only where privacy obligations and source agreements allow.

The clarifications of 6 September 2026 concern the limits of the DMARC, DKIM and DNSSEC measurements. The measurements and published archive remain unchanged.

Methodology clarifications and scanner corrections

Questions and answers

How many .ch domains lack protection against sender spoofing?

70.01% of the examined .ch domains configured to receive email do not effectively protect against sender spoofing. For 57.07%, no DMARC record was detected. About 0.03% lack a recognised p value. Another 12.91% publish p=none, requesting neither quarantine nor rejection. That is 1'190'194 out of 1'700'148 domains.

Does this mean these domains were attacked?

No. The report measures public settings. It does not show that an attack happened or that a mailbox was hacked.

What protection rules are available?

With p=none, the domain asks for no filtering or rejection. This setting can be used to collect reports. We did not check whether reports were set up or read. With p=quarantine, suspicious messages should be moved to spam. With p=reject, they should be rejected. We did not test whether recipients follow these instructions for each message.

Is SPF enough on its own?

No. SPF alone does not protect against every form of sender spoofing.

How were the domains examined?

We queried public DNS services only. We sent no emails and did not contact mail servers directly.

Why could some domains not be analysed?

They did not return a usable DNS response during measurement. They were not counted as unprotected and are excluded from the findings. This affected 142'615 out of 2'459'127 domains.

Does the search find every domain using DKIM?

No. The search uses known names from email providers. Custom or unknown names may be missed. The actual number of domains using DKIM may therefore be higher.

Was email delivery tested?

No. We sent no emails and examined no mailboxes.

Which data are public?

Summary figures, charts, program code and verification documents are public. Results for individual domains remain private.

How should I cite this report?

Hadorn, P. (2026). Swiss Email Security Report 2026. WebEvolve.ch.

↑

Protect your email domain.

We discuss your current situation and identify sensible next steps for your company.

Book a consultation