Security
How We Protect Our Customers
Last updated: August 23, 2026. Every figure in this document comes from measurements on our own systems between August 19 and 23, 2026.
A company that runs email accounts for other people handles someone else's communication. Not data in the abstract, but invoices, draft contracts, sick notes, bank statements, job applications, private correspondence. Anyone who takes on that responsibility owes transparency about what they do to protect it. This document describes our safeguards as precisely as we can without handing an attacker a map. In two places we deliberately stay vague, and we say why each time.
Our Principle: A Legitimate Email Outweighs a Spam Email
Every spam filtering system faces the same trade-off. Filter too aggressively, and real messages get lost. Filter too loosely, and advertising and fraud flood the inbox.
We made a choice, and we'll say it plainly: a legitimate email sitting in the spam folder weighs more, to us, than a spam email sitting in the inbox. For our business customers' invoice mail, that rule holds without exception. An invoice that never arrives costs money, trust, and in the worst case, a business relationship.
That leads to a slower, more deliberate process than most providers use. Before we switch on a new detection rule, it first runs silently and gets measured against real customer mail. We test every new rule against years of business correspondence that was actually delivered. If it fires even once against that history, it doesn't go live. It goes back to the drawing board.
Yes, We Delete Email. And Yes, Some of That Is Wrong.
We don't buy the claim that any spam filter runs error-free. No system on earth does, and anyone who tells you otherwise either hasn't measured or isn't being honest.
We delete messages when the evidence is clear. And we know that some of what we delete are so-called false positives, cases where a harmless message got flagged as harmful.
We didn't stop thinking there. Every sender of a deleted message gets a notice from us, provided they meet a handful of sender authentication rules that are standard practice today. They learn that their message wasn't delivered, why, and what they can do about it. A silent loss becomes a delay with a way back.
That notice deliberately doesn't go to everyone. A sender who can't authenticate themselves gets nothing. The reason is technical, and just as important: replying to a forged sender address bothers an uninvolved third party and turns us into part of the problem. We don't make that mistake.
What Sender Authentication Is, and Why It Decides Delivery
The rules email runs on are called RFCs, short for “Request for Comments,” the collection of internet technical standards maintained since 1969. An RFC isn't one recommendation among many. It's the binding description of how a protocol is supposed to work. Email itself is defined in RFC 5321 and RFC 5322.
Three newer standards decide whether a sender is genuine:
- SPF, RFC 7208. A domain owner publishes, in DNS, which servers are allowed to send email on their behalf. A message from any other server isn't authorized.
- DKIM, RFC 6376. The sending server cryptographically signs every message. The recipient checks that signature against a public key published in DNS. If it doesn't match, the message was altered in transit or didn't come from the stated sender.
- DMARC, RFC 7489. Ties both mechanisms together and tells a recipient what to do when a check fails. It also gives the domain owner reports on who is sending mail in their name.
Three more standards shape how we operate:
- RFC 3834 governs automatically generated replies. It stops two systems from mailing each other into an infinite loop. Every notice we send to a sender carries the markers it requires.
- RFC 8461, MTA-STS, forces encrypted transport between mail servers. Without it, an attacker sitting in the network path can simply strip encryption, and neither side notices.
- RFC 8460, TLS-RPT, delivers daily reports on whether encryption to us actually worked, straight from the sending systems themselves.
The Uncomfortable Truth About the State of Email
We didn't estimate. We counted: every inbound delivery to our servers between August 19 and 23, 2026.
| Check | passed | failed |
|---|---|---|
| SPF | 75.1% | 24.9% |
| DKIM | 69.2% | 30.8% |
| DMARC | 77.3% | 22.7% |
Broken down further:
SPF Pass 75.1% Fail 8.7% SoftFail 8.1% None 4.2%
PermError 3.0% Neutral 0.9%
DKIM Pass 69.2% None 30.5% Fail 0.4%
DMARC passed 77.3% failed 22.6%
Nearly one in four senders that reach us fails both SPF and DKIM. The measured figure is 22.9 percent. Almost one in three senders doesn't sign their mail at all, that's the 30.5 percent showing DKIM none.
The PermError value for SPF deserves its own mention. It means someone set up an SPF record that's technically broken. The sender believes they're protected and isn't. That's 3 percent of all deliveries.
Behind this sits a problem affecting the entire email landscape: a significant share of the world's mail traffic runs through servers that haven't been updated in over a decade. They speak outdated encryption or none at all, they don't know the standards above, and they're a wide-open door for attackers. Mail sent through a server like that is indistinguishable from a genuine message, and that's exactly what scammers count on.
For the public at large, that's a risk that reaches well beyond any one sender. A hijacked, unmaintained mail server sends phishing under its legitimate operator's name, using their reputation and their customer contacts. The damage lands on third parties who had nothing to do with the negligence.
After a lot of thought, we decided not to look away here. We take our responsibility to protect our customers seriously. It's our top priority.
What Our DNS Records Say
DNS, the internet's name service, is the public record of how a sender reaches us and what rules apply. Ours says more than most. Everything below is publicly queryable. We're not giving anything away.
5.1 Reachability and Delivery Paths
MX Priority 10 mail.vipmail.app the primary server MX Priority 20 mx2.vipmail.app the fallback server
Two separate machines at two separate locations. If the first goes down, the second accepts mail and holds it until the first comes back. No sender gets an error, no message is lost.
5.2 Sender Protection
SPF v=spf1 a:mail.vipmail.app -all
DMARC v=DMARC1; p=quarantine; rua=...; ruf=...; fo=1;
adkim=r; aspf=r; pct=100
The -all at the end of the SPF record is the strictest setting available. It means: whoever doesn't send from our server doesn't send in our name, full stop. Many providers use ~all instead, which only expresses a suspicion. We don't.
The DMARC record demands reports on every abuse attempt, both individually and in aggregate. That gives us daily visibility into who's trying to send mail in our name.
5.3 Mandatory Transport Encryption
MTA-STS v=STSv1; mode: enforce; max_age: 604800 TLS-RPT v=TLSRPTv1; rua=...
mode: enforce is the line that matters. A sending server that supports MTA-STS must reach us encrypted. It can't fall back to an unencrypted connection, not even if an attacker sitting in the network is trying to force exactly that. The matching reporting standard tells us daily whether it worked.
These two records are why systems like Proton and Google treat us as a trusted recipient. Neither is mandatory. The large majority of mail servers don't have them.
5.4 Certificate Control
CAA 0 issue "letsencrypt.org" CAA 0 issuewild "letsencrypt.org"
This record specifies that exactly one, named certificate authority may issue certificates for our domain. Every other authority is required to refuse a request. That closes off an entire class of attack where someone talks any certificate authority into issuing a valid certificate for a name that isn't theirs.
5.5 Automatic Setup and Our Own Name Servers
SRV _autodiscover._tcp Port 443 SRV _submission._tcp Port 587 SRV _imaps._tcp Port 993
A mail client finds the right settings on its own. That's convenient, but it also has a security benefit: nobody configuring by hand accidentally leaves an unencrypted port enabled.
Three redundant name servers sit under our own control. DNS is the root of every delivery decision. Whoever takes it over takes over the domain. So it doesn't live just anywhere.
Our Layers of Defense
A message runs through several independent checks with us. That's deliberate. No single mechanism decides alone, and no single mechanism failing takes down the whole defense.
6.1 First Layer: Who's Even Knocking?
Before we accept a message, we check the other end. Does its address have a valid name record, and does that record point back to the same address? Is the address listed on one of the public directories of known spam sources? We query seven independent lists for that: Barracuda, GBUDB Truncate, NordSpam, PSBL, SURBL, SpamCop, and blocklist.de.
We also run addresses that are never, under any circumstances, part of a legitimate business exchange. Anyone writing to one of those didn't get it from a customer. They got it from a harvested list. That's a reliable tell.
6.2 Second Layer: Cyren
We run two separate services from Cyren.
Cyren IP Reputation scores a sending address against its real-time behavior worldwide. The service sees mail traffic at a scale no single server operator ever could, and often flags a new spam source within minutes of its first appearance, a window in which classic block lists still know nothing.
Cyren Spam Server scores the content. It sorts a message into a class, from unremarkable through bulk mail to confirmed spam. What matters: the service works from checksums, not your text. No message content leaves our building.
6.3 Third Layer: SpamFoo
SpamFoo is a learning system that estimates the likelihood a message is unwanted. It doesn't return yes or no, it returns a percentage.
Privacy is the real point here. SpamFoo runs server-side with no transmission of message content to third parties. There's no cloud your mail gets copied into, no external provider reading your correspondence to improve its model, no content handed off to a third country. It learns from what happens on our own server, and what it learns stays there.
We consider this more important than it usually gets credit for. Many modern spam filters buy their detection accuracy by shipping message content to a cloud service. For a mail provider based in Germany, that's a data protection problem no clause in the terms of service can paper over.
6.4 Fourth Layer: Rspamd
Rspamd is the heart of our content analysis. It's open source, runs entirely on our own hardware, and is built from individually switchable modules. We currently run 43 of them. What each one does:
Sender and authenticity checks
| Module | What it does |
|---|---|
spf | checks whether the sending server is authorized for the sender domain |
dkim | verifies the message's cryptographic signature |
dkim_signing | signs our own outbound mail |
dmarc | evaluates the sender's policy and reports abuse |
arc | tracks the authentication chain across forwards |
forged_recipients | detects forged recipient information |
mid | checks the message ID for anomalies |
once_received | flags messages that took a suspiciously short path |
mx_check | checks whether the sender domain can receive mail at all |
Content and structure analysis
| Module | What it does |
|---|---|
bayes_expiry | maintains the learning language model and ages out old data |
neural | a neural network that learns from this server's own traffic |
fuzzy_check | detects messages resembling a known spam template, even after edits |
phishing | compares visible link text against the actual link target |
regexp | pattern matching, the basis for many other rules |
trie | searches a large number of text patterns simultaneously and fast |
chartable | detects mixed character sets used to trick filters |
mime_types | checks attachment types and detects disguised file extensions |
hfilter | checks headers for signs of automated bulk sending |
maillist | recognizes genuine mailing lists and handles them correctly |
url_redirector | resolves short links and checks the real destination |
url_suspect | scores suspicious address patterns in links |
spamassassin | plugs in a maintained external ruleset, focused on fraud and phishing |
Reputation and accumulated trust
| Module | What it does |
|---|---|
reputation | builds a judgment on senders, addresses, and domains over weeks |
known_senders | recognizes senders we've already had contact with |
replies | recognizes replies to ongoing correspondence and protects them |
whitelist | permanently trusted senders |
asn | scores which network operator a message originates from |
rbl | queries the public directories of known spam sources |
multimap | links our own lists with our own rules |
Malware
| Module | What it does |
|---|---|
antivirus | connects the virus scanner, every attachment gets checked |
Control and operations
| Module | What it does |
|---|---|
settings | allows different rules per recipient |
force_actions | forces a fixed decision on unambiguous findings |
ratelimit | limits bulk delivery from a single source |
milter_headers | writes check results into the message, traceably |
history_redis | retains the check history for traceability |
metadata_exporter | exposes metrics for monitoring |
aliases | resolves address redirects correctly |
Built in-house. We wrote seven modules ourselves because nothing suitable existed for the threat in question:
| Module | What it does |
|---|---|
vipmail_kundenimitat | detects when an outside sender uses a display name impersonating one of our customer domains |
vipmail_markenimitat | detects the same for banks, government agencies, and well-known brands |
vipmail_bulk | detects the typical building blocks of industrial-scale bulk mail |
vipmail_auth_deckel | protects fully authenticated business mail from being pushed into a hard action by the sum of small suspicion signals |
vipmail_rechnungsschutz | recognizes genuine invoice mail from documented business history and explicitly protects it |
vipmail_akquise | detects unsolicited cold outreach |
vipmail_wegwerf | detects disposable domains with machine-generated number-and-word patterns in the mailbox name |
vipmail_auth_deckel is the answer to a mistake we made ourselves. In August 2026, a genuine invoice got deleted because two individually harmless suspicion signals added up to a score nobody had planned for as a combination. Each signal was deliberately kept below its own threshold; nobody had watched the sum. Since then, there's a hard cap on suspicion points for fully authenticated senders, and every exception to that cap is individually justified and documented.
We're putting this here because it belongs to being honest. Any operator who claims this never happened to them either wasn't paying attention or isn't telling the truth.
6.5 Fifth Layer: IPServerSec
IPServerSec is our firewall, and it does more than that name suggests. It watches the server around the clock, continuously evaluates every log, and locks out attackers automatically before a human could even look.
It works across nine separate areas at once: login attempts against real accounts, login attempts against made-up accounts, systematic probing for valid addresses, protocol violations, abuse as an open relay, attacks on the web interface, attacks on the admin panel, and the trap addresses.
A single day shows the scale. By the evening of August 23, 2026, we had recorded 11,414 failed login attempts and 22,459 delivery attempts rejected during the SMTP handshake. The active block list for login attempts currently holds over 3,200 addresses and address ranges, covering more than 196 million individual addresses.
That's not an unusual day. That's a Tuesday.
Two things set IPServerSec apart from an ordinary block list. First, it has a memory: an address that trips it again after a block expires gets a noticeably longer block the second time. Second, and this is the harder part, it knows the difference between an attacker and a customer with a misconfigured mail client. A customer whose app keeps knocking every 15 minutes with a stale password produces the exact same pattern as an attacker. Fail to tell them apart, and you lock out your own customers.
In front of the server's own firewall sits a second, independent firewall inside the data center network. It's unreachable from a compromised server, and therefore can't be switched off from one either.
What We Don't Do
We don't read a single message. Every check described here runs automated. No employee opens customer mail, not to troubleshoot, not to improve detection, not out of curiosity. When we build a detection rule, we work from technical signals, checksums, and headers. If clarifying a false positive genuinely requires looking at a specific case, that only happens at the explicit request of the affected customer, and only on their own case.
We don't hand content to third parties. The external services we use work from checksums and reputation data, not your text.
We don't publish thresholds. Nowhere in this document does it say at what score a message receives what treatment. Anyone who knew that could build a message to land just under it. Nobody gets that answer, not even on request.
Backing Up Your Data
We run three independent backup systems, each with different technology, a different storage location, and different timing. They sit physically separate from the production system.
The reason for three instead of one is simple: every single backup method has a case where it fails. A backup on the same machine doesn't survive a hardware failure. A backup the production system can write to doesn't survive a ransomware attack. A backup that only runs daily loses a day. Three methods whose weaknesses don't overlap cover each other's blind spots.
We deliberately don't describe the three methods in detail here. Anyone who knows where and how an operator backs up also knows what to attack to prevent recovery. That's exactly the first step in a modern ransomware attack: the backups first, then the data. We're not drawing that map.
What we can tell you: recovery gets tested, not assumed. A backup that's never been restored isn't a backup. It's a hope.
What It Takes for an Email Not to Reach Us
Customers are right to ask this, so here's the honest answer: it takes a lot.
A message doesn't get held back over a single trait. It has to fail several independent checks at once. A missing SPF record alone isn't enough. A missing signature alone isn't enough. One hit on one block list isn't enough.
The reverse also holds: a sender who authenticates cleanly, who already has a history with us, and whose domain has a documented business relationship with the recipient, doesn't get held back. We built dedicated protection modules for exactly this case, whose only job is to defend genuine business mail against every other check.
And if it does happen anyway, the sender almost always gets a notice about it. They find out and can act. A silent loss is the real damage, not the delay.
Why None of This Is Overkill
We'd like two minutes of your attention here. Please read the next part twice.
Picture your own email account. Not today's inbox. The whole account. Ten years. Maybe twenty.
What's in there?
Invoices, incoming and outgoing, with full addresses and amounts. Bank statements and payment notices. Contracts. Birth dates, addresses, phone numbers of people who trusted you with them. Sick notes. Job applications with résumés. Photos. Your customers' names and addresses, often built up over many years. Passwords someone emailed you because things needed to move fast.
And, less obvious and at least as valuable: your writing. Your style, your sign-offs, the way you talk to which customer. Enough material to write a message in your name that nobody would question.
Then there's the point most people miss: whoever has access to your email account can reset the password almost everywhere else. The mailbox is the master key. Online banking, inventory systems, tax portals, social networks, domain management. Every path leads back through an email address.
Now the consequence. If your account is taken over and personal data belonging to other people is involved, and it practically always is, German law applies here through Articles 33 and 34 of the GDPR, the EU's data protection regulation: notification to the relevant data protection authority within 72 hours, and notification of every single affected person.
Every single one. Built up over ten or twenty years.
And it doesn't stop at reputation damage. We'd call it existential.
A Case That Stuck With Us
A few days ago, we looked into how many German medical practices use free consumer email services for their communication. We're not naming providers here, and we're not naming practices either.
The result didn't surprise us, but it stayed with us.
A free consumer service doesn't come close to meeting the security requirements German data protection authorities impose on a medical practice. Those requirements exist for a reason. Medical correspondence carries reimbursement transfers, X-rays, lab reports, findings, diagnoses.
If that data gets breached, the practice doesn't just owe notice to patients and the data protection authority. In all likelihood, there's something worse waiting: patient records published on the dark web. Under Article 9 of the GDPR, health data belongs to a special category of personal data subject to explicitly stricter rules.
What sits in a hijacked mailbox after ten years, we covered in the previous section. A medical practice adds another dimension on top: access like that is usually enough to reset passwords elsewhere, to learn the private phone numbers of patients and staff, to imitate writing style and tone from years of correspondence, and to use gathered birth dates to prepare further, targeted attacks on those exact people. For that last part, whoever was responsible for securing the account can, under some circumstances, be held liable themselves.
Our research also turned up how few of these practices have two-factor authentication set up for their email access. By today's standard, going without a safeguard that's this well established and this easy to set up is grossly negligent.
And to be clear: this notification duty isn't limited to doctors. Any commercial business handling personal data has to inform the relevant authority in a real incident, and then notify every single affected contact individually. That doesn't just damage a reputation. It gets around.
We're not lawyers, and this isn't legal advice. But we'll put the questions on the table: what does that mean for the damages claims that can follow? And how does a business or professional liability policy respond when the claim traces back to a well-known, long-standard safeguard that simply wasn't in place? We're deliberately not going further into either question here. They're worth answering for yourself, ideally with your own insurer or counsel, and before something happens, not after.
On Gross Negligence
Today, it's grossly negligent for a server or mail server operator not to do everything reasonably possible.
That's not a moral statement. It's one with consequences. Anyone who knows the recognized safeguards and doesn't implement them is in violation of the law. Article 32 of the GDPR requires measures that reflect the state of the art. The state of the art isn't what was common ten years ago.
The effort required today is smaller than most people assume. Two-factor authentication takes minutes to set up. A mailbox can be locked down. And a mail server, or at least its admin access, can be configured to be reachable only over a VPN or your own company network, instead of sitting open to the entire internet. None of this is exotic. It's basic.
Every reader should take a moment to think about what that means for them. Not for the provider they use. For them.
What You Can Expect From Us
- Two separate mail servers at two separate locations
- Five independent layers of checks
- 43 active analysis modules, seven of them built in-house
- Seven independent reputation lists
- Mandatory transport encryption with daily verification
- IPServerSec, our own firewall, watches around the clock and blocks automatically, backed by an additional, independent hardware firewall in the data center network
- Three independent backup systems in separate locations
- No message content handed to third parties
- No human reading your mail
- A notice to the sender when a message doesn't get through
Even If You're Not a Customer Yet
We didn't build all of this to keep it to ourselves. We're proud of what we've learned and built over the past several years, and email deserves to be secured the way this document describes. Anything less, frankly, isn't good enough anymore.
So here's an offer, aimed explicitly at everyone who doesn't host with us today: if something about your own email setup worries you, if you don't know whether your current provider does even a fraction of what's described above, or if you'd simply like a second opinion, talk to us. That goes for medical practices, law firms, trades businesses, associations, larger companies, and individuals alike, wherever in the world you're based.
We review existing configurations, migrate live mail traffic without interruption, and host afterward inside the EU, fully GDPR-compliant. A quote costs nothing and commits you to nothing.
In Closing
A company offering email accounts to other people today is, in effect, a telecommunications provider with special obligations. We meet those obligations, and we go beyond them.
vipmail.app is a service of intelligent piXel GmbH, Enzianstraße 4a, 82319 Starnberg, Germany, HRB 207679.