Server and transport security
The protections around your encrypted mail — signed DNS, our mail key pinned in DNS, TLS 1.2 or better, HSTS, SPF, DKIM, DMARC, MTA-STS — and their limits.
End-to-end encryption protects what is inside a message. This page is about everything around it: whether the connection that carries your mail can be intercepted, whether somebody can impersonate our mail server, and whether a message can be pushed off the encrypted path onto a plain one.
None of this replaces end-to-end encryption, and we would rather you kept that order of importance. A message encrypted to a recipient's key is safe even over a bad connection. These measures are there so that the parts PGP cannot protect — the envelope, the delivery, the first visit to the web app — are not the easy way in.
Every claim below is a public record you can check yourself; the commands are in the last section.
Mail to and from the rest of the internet
Mail between Private.Ki accounts never touches SMTP at all — it is handed from mailbox to mailbox as an encrypted object. What follows applies to mail crossing the border.
Encrypted connections, with a floor. Our mail server offers TLS 1.2 and TLS 1.3 and nothing older. TLS 1.0 and 1.1 are refused outright, as are export-grade, RC4, 3DES and other legacy ciphers; strong ciphers are preferred in our order, not the sender's.
Our certificate is pinned in DNS (DANE). A sending server that supports DANE looks up a record that names the exact public key our mail server must present. If it is shown anything else, it refuses to deliver rather than handing your mail to whoever answered. This is what makes the common attacks on mail delivery — swapping in another certificate, or stripping the encryption offer so the connection falls back to plaintext — fail instead of succeeding quietly.
A published policy that senders must have TLS (MTA-STS). We publish a policy saying that mail for this domain goes to our mail host over TLS with a valid certificate. The policy is currently in testing mode: supporting senders check it and report failures to us, but still deliver if something does not match. That is the deliberate first stage — it lets a misconfiguration show up in reports rather than in bounced mail. It will move to enforcing after a period of clean reports.
Reports about failed connections (TLS-RPT). We publish an address for supporting senders to send daily summaries of TLS problems they had reaching us, which is how a quiet failure becomes visible.
Sender authentication, in both directions. We publish SPF with a hard fail (only our mail server may send for the domain), sign outgoing mail with DKIM, and publish a DMARC policy of quarantine, so mail forged in our name is treated as suspicious by receivers. On the way in, connections are screened before they are accepted and the sender's own SPF record is checked.
smtpd_tls_security_level is deliberately permissive: a sending server that cannot do TLS at all is still accepted, because a public mail host that refuses them simply loses the mail. MTA-STS is the mechanism that makes capable senders require TLS to us — and in testing mode it does not yet enforce. Separately, we do not yet verify other domains' DANE records on mail we send out; that needs a change to how the server resolves names and has not been made. Until then, outgoing mail to another provider uses TLS when that provider offers it.
The one honest summary: for mail leaving Private.Ki unencrypted, transport security reduces who can read it in transit. It does not make it private. Encrypt it to the recipient's key — which, since automatic key discovery, often happens without you doing anything.
Our DNS answers cannot be forged
The zone is signed (DNSSEC), and the signature is anchored. Every answer about privateki.net — where the mail server is, where the app is, what the DANE record says — carries a cryptographic signature, and the chain of trust reaches up to the registry. A validating resolver, which includes the large public ones and most consumer ISPs, rejects a forged answer instead of passing it on.
This is also what makes the DANE record above mean anything: without signed DNS, an attacker who could forge DNS could simply remove the record. Signed DNS and DANE are one measure in two parts, and both halves are live.
Without DNSSEC, anyone able to tamper with DNS answers on the path — a hostile network, a compromised resolver — can point your mail at their server, or hide our certificate pin. With it, the answer either validates or is thrown away. It is the foundation the mail protections stand on, which is why it was worth the care: the record that anchors it is one that, mistyped, takes the whole domain offline.
The web app and this site
HTTPS only, and remembered. Every host sends HSTS with a one-year lifetime, so after a single visit your browser refuses to make a plain HTTP request to it, even if something tries to downgrade a link. On the main domain the promise covers every name beneath it.
Preload submitted. We have submitted the domain to the HSTS preload list, which browsers ship built in — once included, the very first visit from a fresh browser is HTTPS-only, with no window at all. The submission is accepted and pending; inclusion arrives with a later browser release, not on a date we control.
No access logs. Our web server writes no access log, and neither does the host that serves public keys. There is nothing recording which pages or endpoints you requested, from which address. See What our server can and cannot see.
Outgoing mail is checked for abuse, not read for content. Links and addresses in mail leaving for external recipients are checked against blocklists through our own resolver, so the lists are queried by us and not through a third party's. Details, and what each service sees, in Third-party services and How to avoid spam.
The details
Nothing here needs an account. These are public records.
dig +short DS privateki.net # DNSSEC anchored at the registry
dig @1.1.1.1 privateki.net A +dnssec | grep flags # "ad" = the answer validated
dig +short TLSA _25._tcp.mail.privateki.net # "3 1 1 <hash>" - the pinned key
dig +short TXT privateki.net # SPF, ending -all
dig +short TXT _dmarc.privateki.net # p=quarantine
dig +short TXT _smtp._tls.privateki.net # TLS-RPT reporting address
curl -s https://mta-sts.privateki.net/.well-known/mta-sts.txt # the policy and its mode
curl -sI https://privateki.net/ | grep -i strict # HSTS, includeSubDomains, preload
openssl s_client -starttls smtp -connect mail.privateki.net:25 -tls1_2 </dev/null 2>&1 | grep '^New,'
The DANE record is 3 1 1: DANE-EE, the SubjectPublicKeyInfo, SHA-256 — it pins the mail server's public key, independently of who issued the certificate or when it expires. That means the key must survive certificate renewal, so renewal reuses the key pair, and a hook republishes the record and alerts an operator if the key ever does change, keeping the previous record alive while the change propagates. DNSSEC uses algorithm 13 (ECDSA P-256 with SHA-256) with a SHA-256 delegation digest.
Technical write-ups of the decisions behind this page live in the project's operator documentation; the measures were added on 8 October 2026 and are re-applied by every deployment, so the configuration cannot drift away from what is written down.
Common questions
Does any of this mean my mail to Gmail is private?
No. It means the connection is encrypted and hard to redirect or impersonate. Gmail itself can read anything that is not encrypted to a key. Transport security and end-to-end encryption solve different problems.
Is mail between two Private.Ki accounts affected by any of this?
Not really — it never goes over SMTP, so there is no transport to secure. It is encrypted to each recipient's key and handed over internally.
What happens if your DANE record and your certificate ever disagree?
Mail from DANE-validating senders would be refused rather than delivered insecurely. That is the intended behaviour and the reason the record is tied to a key that is reused across renewals, with an alert if it ever changes.
Why is MTA-STS only in testing mode?
Because enforcing it the day it is published turns any small mismatch into lost mail. Testing mode produces reports instead of bounces; enforcing follows once those reports are clean.
Do you verify other providers' DANE records when you send?
Not yet, and we would rather say so. It requires the server to validate DNS answers itself, which is a change to the host's name resolution and has not been made.
Who decides when preload takes effect?
The browser vendors. We submitted the domain and the submission is pending; it becomes effective in the browser releases that ship the updated list.