Proton Mail Settings: Security, Bridge, and DMARC

Proton Mail’s settings are spread across two places that look similar and are not: the quick panel behind the gear icon, and Settings → All settings, where everything that actually matters lives. Most of the questions people arrive with, from “what are the Proton Mail server settings” to “does Proton need a DMARC record”, are answered in three sections of that second screen.

This page is the reference for those. It assumes the account already exists; if it does not, the ProtonMail setup guide covers creation and migration first, and this page picks up afterwards.

Account and security settings that change your risk

These are ordered by how much they change if something goes wrong, not by where they appear in the menu.

Two-factor authentication (Account and password → Two-factor authentication). Proton supports both TOTP authenticator apps and FIDO2 security keys. A security key is meaningfully stronger than TOTP because it validates the origin of the login page and therefore cannot be replayed by a phishing proxy. Enable one, then save the recovery codes somewhere that is not the mailbox they unlock.

Recovery phrase versus recovery email (Recovery). These do different jobs and the distinction is the single most misunderstood thing in the product:

• A recovery email or phone restores account access. It does not restore the encryption keys, so historic encrypted mail can still be unreadable afterwards.
• A recovery phrase is a backup of key material. It restores the mailbox.

Set both. If you set only one, set the phrase, and store it outside any password manager whose master credential is protected by this same email address.

Proton Sentinel (account dashboard → Security and privacy). An elevated account-protection program that applies stricter challenges to suspicious sign-ins and escalates them to human security analysts for review. It adds friction to legitimate logins from new devices, which is the point. Worth turning on for an address that is the recovery route for other accounts.

Check the plan before you go looking for the toggle: Sentinel ships with Proton Unlimited, Duo, Family, Visionary, Pass Plus and the Workspace plans. Mail Plus does not include it, which catches out people who upgraded specifically for custom domains and assumed the security features came with it.

Sessions (Account and password → Sessions). Lists every authenticated client. Sign out anything you do not recognise, and do a pass after any lost device. Note that a signed-out Bridge session breaks desktop clients until Bridge signs in again.

Address verification (Encryption and keys → Address verification). Pins a contact’s public key so that a silent key change is flagged instead of being trusted automatically. This closes the one gap that makes provider-side end-to-end encryption a trust decision rather than a guarantee, and it is off by default.

Message privacy settings

Under Email settings → Privacy and security:

• Block email tracking strips the invisible pixels that report when and where a message was opened. On by default on newer accounts; verify rather than assume.
• Block remote content stops externally hosted images loading until you ask. This also suppresses the IP address leak that loading them causes.
• Request link confirmation interposes a confirmation dialog before external links open. It is the cheapest anti-phishing control in the product.
• Auto-load embedded images is the setting people flip off and then wonder why newsletters look broken. That is the tradeoff working as designed.

None of these change what Proton can see. They change what senders can see about you, which is a separate and often more immediate exposure. The email security threat model separates the two.

Proton Mail server settings: why there are none, and what to use instead

The most common search on this topic is for Proton Mail’s IMAP and SMTP server settings, and the honest answer is that a personal Proton account does not expose any. Mail is decrypted client-side, so there is no server that can hand a standard mail client plaintext over IMAP. Proton solves this with Proton Mail Bridge, a local application on paid plans that decrypts locally and presents a standard IMAP/SMTP interface on your own machine.

The settings your mail client wants are therefore all pointed at localhost:

Setting	Value
IMAP server	127.0.0.1
IMAP port	1143
IMAP security	STARTTLS
SMTP server	127.0.0.1
SMTP port	1025
SMTP security	STARTTLS
Username	your full Proton address
Password	the Bridge-generated password, not your Proton password

Four things routinely trip people up here:

1. The password is not your account password. Bridge generates a per-client password and shows it in its own interface. Your real password never reaches the mail client.
2. Bridge has to be running. Close it and the mail client reports a connection failure. It starts on login by default; leave that on.
3. The certificate is self-signed. Bridge issues its own certificate for the local connection, so clients prompt on first connect. That prompt is expected, and Bridge shows the fingerprint you should compare it against.
4. Bridge is a paid feature. Free accounts use the web app and the official mobile and desktop apps only.

If you are configuring Thunderbird, note that Thunderbird also has a native PGP implementation, which is a different path to a different goal. How to set up PGP for email covers that route.

SMTP submission for applications

Bridge is for humans reading mail. If what you need is an application, a server, or a website sending as your custom domain, Proton offers SMTP submission instead: a token-authenticated connection to Proton’s own submission server, no local Bridge involved. It is available on any paid Proton Mail plan, but only for a custom domain address — you cannot use it with a @proton.me address.

Setting	Value
Server	smtp.protonmail.ch
Port	587
Security	STARTTLS
Authentication	PLAIN or LOGIN
Username	the custom domain address the token was issued for
Password	the generated SMTP token

The token is generated per address in Proton’s settings, and it is the only credential that works here. Your account password and mailbox password will both be rejected, and Proton’s guidance is never to put them into a third-party client at all.

Mail sent this way is not end-to-end encrypted, because the sending application holds no keys. That is the correct tradeoff for transactional mail and the wrong one for correspondence. If a small team is deciding between the two, choosing an encrypted email provider for a small team covers where the boundary should sit.

Custom domain settings: MX, SPF, DKIM, and DMARC

Under Settings → All settings → Domain names, adding a domain produces a checklist of DNS records. Proton verifies each one and refuses to finish until they resolve.

• Verification TXT record. Proves you control the domain. It can be deleted afterwards, and there is no benefit to doing so.
• MX records. Two, at priorities 10 and 20, pointing at Proton’s inbound servers. These are what actually route mail to you.
• SPF. A single TXT record, v=spf1 include:_spf.protonmail.ch ~all, listing Proton as an authorised sender for the domain. If another service also sends as this domain, add its include: to the same record. Two separate SPF records is a configuration error that causes a permanent failure, not a merge.
• DKIM. Three CNAME records pointing at Proton-hosted keys. Three, because Proton rotates through them; publish all three or rotation breaks your signatures.
• DMARC. One TXT record at _dmarc.yourdomain.com that tells receivers what to do with mail failing the two checks above.

The DMARC record, specifically

“Proton Mail DMARC” is a frequent search, and it is worth knowing that Proton’s own recommendation is p=quarantine, with p=reject once you are confident legitimate mail passes. That is the destination. If the domain has ever sent mail through anything other than Proton, it is not the right first move.

Start in monitoring mode:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

p=none means “check, report, deliver anyway”. It changes no delivery behaviour. Its purpose is the rua= aggregate reports, which tell you every source currently sending as your domain, including the ones you forgot about. Run it for two to four weeks, read the reports, then move to Proton’s recommended policy:

v=DMARC1; p=quarantine; pct=100; rua=mailto:you@yourdomain.com; adkim=s; aspf=s

and eventually p=reject, which is the only policy that actually stops someone forging your address. Moving straight to p=reject before reading aggregate reports is how legitimate mail from a forgotten newsletter platform starts bouncing. A brand-new domain that has only ever sent through Proton can skip the monitoring stage and start at p=quarantine, because there is no legacy sender to discover. RFC 7489 documents the full tag set; the mechanics and the verification steps are in SPF, DKIM, and DMARC setup for a custom domain.

Catch-all (Domain names → catch-all address) routes everything sent to any local part at your domain into one mailbox. It is convenient and it is a spam magnet, because a dictionary attack against your domain now always succeeds. Per-service aliases are the better pattern, for the reasons in email aliases for privacy.

Settings that sound like security and are not

• Subject line encryption. There is no setting, because Proton does not encrypt subject lines. Neither do headers or recipient lists. If that is a requirement, it is a provider decision rather than a settings decision, and it is the specific line where Tuta differs. The ProtonMail vs Tuta comparison covers what each side gives up.
• “End-to-end encrypted” on outbound mail to non-Proton addresses. Not a toggle. Mail to a Gmail address is TLS in transit and plaintext at rest on Google’s side unless you use a password-protected message or PGP. Proton Mail vs Gmail on privacy sets out what each provider can actually see.
• Zero-access encryption on imported mail. Import via Easy Switch encrypts at rest once it lands, but the import itself moves plaintext. It does not retroactively make old Gmail correspondence end-to-end encrypted. The staging approach is in the Gmail to ProtonMail migration plan.

Quick reference

You want	Setting location
Security key or TOTP	Account and password → Two-factor authentication
Mailbox recovery, not just login recovery	Recovery → recovery phrase
Stricter login protection	Security and privacy → Sentinel (Unlimited and above, not Mail Plus)
Detect a swapped contact key	Encryption and keys → Address verification
Stop read tracking	Email settings → Privacy and security
IMAP/SMTP for Thunderbird or Apple Mail	Proton Mail Bridge, 127.0.0.1:1143 / :1025
Send from an app or server	SMTP submission token, smtp.protonmail.ch:587, custom domain only
Stop address forgery	Domain names → DMARC, p=reject once reports are clean

If you are still choosing a provider rather than configuring one, the encrypted email provider matcher applies hard requirements as knockout filters, and how to create a secure email account covers the decisions that come before any of these settings exist.