Proton Mail Sender Requirements

Proton Mail is an end-to-end-encrypted mailbox provider based in Switzerland, built around zero-access encryption and a refusal to scan message content. That privacy model shapes everything about sending to it: Proton’s published sender-facing surface is small, there is no bulk threshold, no spam-rate number, and no feedback loop, and the encryption guarantees mean a sender gets no open or click visibility into Proton recipients. What Proton does document well is its machine-learning anti-spam and anti-abuse posture and clear abuse-reporting channels, plus standard SPF/DKIM/DMARC guidance for its custom-domain customers.

Scope: this page covers sending to Proton-hosted recipients - proton.me, protonmail.com, pm.me, protonmail.ch, and the custom domains Proton hosts (their MX points at mail.protonmail.ch / mailsec.protonmail.ch). It is not about sending bulk mail from Proton, which Proton’s anti-abuse system actively restricts.

The 60-second version

• Proton runs an in-house, machine-learning anti-spam system for inbound mail, including PhishGuard phishing warnings, that learns from user feedback (move-to-spam, mark-as-phishing, move-from-spam). Proton claims it is “at least 60% more effective than widely used spam filters such as SpamAssassin.”
• No published sender requirements page, no threshold, no spam-rate ceiling, no FBL, no sender dashboard. Reputation signals are not exposed to senders.
• Privacy means no engagement telemetry. Zero-access encryption and Proton’s tracker-blocking mean opens and clicks are not observable - do not build segmentation on them for Proton recipients.
• For custom domains, Proton requires/recommends SPF, DKIM, DMARC and runs automatic DKIM key rotation (2048-bit keys, rotated every six months, via three CNAMEs). This is sender guidance for Proton’s own customers, and a clear statement of what Proton values.
• Abuse reporting is well-defined: report abusive Proton accounts at proton.me/support/report-abuse or abuse@proton.me; mail-delivery and spam issues go to postmaster@proton.me; wrongful anti-abuse suspensions are appealed at proton.me/support/appeal-abuse.
• Proton aggressively suppresses outbound abuse (bulk signups, account takeovers, spam) to keep its IP/domain reputation high.

The anti-abuse and anti-spam posture

Proton’s most substantive sender-relevant document is its anti-abuse blog. Because Proton cannot read message bodies (zero-access encryption) and does not require a phone number at signup, it leans heavily on machine learning and behavioral clustering rather than content inspection. The verified specifics:

• In-house ML anti-spam + PhishGuard. “Proton Mail also has a sophisticated in-house system that applies similar machine-learning techniques to email, mainly to fight spam and phishing attacks. This system also includes PhishGuard, which automatically adds phishing warnings to emails that are likely spoofed or are part of a phishing attack.”
• It learns from user feedback. Moving a message to spam, marking it as phishing, or moving it from spam to inbox all train the system.
• The headline claim: “Our anti-spam system… is at least 60% more effective than widely used spam filters such as SpamAssassin.” (Proton’s own assertion; the methodology behind the figure is not published - flag as a vendor claim, not an independently verifiable benchmark.)
• Outbound abuse is suppressed to protect reputation. Proton blocks bulk email registrations and outgoing spam from abusive accounts, and states this is why “Proton Mail has high-reputation IPs and domains that provide great email deliverability for the Proton community.”

The operational read for a sender: Proton scores inbound mail with a learning system tuned by recipient behavior. There is no score, threshold, or dashboard exposed to you, so the levers are the universal ones - authenticate, send wanted mail, and avoid the spoofing/phishing signatures PhishGuard targets.

What Proton requires for custom domains (SPF, DKIM, DMARC)

Proton’s clearest “what good looks like” statement is its custom-domain anti-spoofing guide, written for its own paying customers who bring a domain. It is sender guidance, and it tells you exactly what Proton considers correct authentication:

• SPF: “strongly recommend” (Proton’s word; not framed as mandatory). Proton customers add include:_spf.protonmail.ch and typically mx, with ~all (SoftFail). Proton explicitly warns against -all (HardFail) because it breaks forwarding.
• DKIM: managed via three CNAME records so Proton can run automatic key rotation - “we will generate a new 2048-bit key every six months and use it to sign your emails.” This is a notably strong default (2048-bit, rotated).
• DMARC: default is p=none; Proton recommends p=quarantine, and p=reject “if you think you are likely targeted for email spoofing,” citing Yahoo, PayPal, and eBay as p=reject examples. Proton documents the rua= aggregate-reporting tag and warns that quarantine/reject can break mailing-list mail (SPF breaks on forward; list edits break DKIM).

Two things to take from this. First, Proton’s own authentication hygiene is strong (2048-bit rotating DKIM, recommended DMARC enforcement). Second, this is guidance for Proton’s customers; Proton does not publish a separate inbound rulebook saying “senders to Proton must do X.” The honest synthesis: authenticate to the standard Proton itself recommends, because that is plainly what Proton values, but note it is not codified as a Gmail/Yahoo-style sender mandate.

The privacy implications for senders

This is where Proton differs most from every other provider on this site, and it is structural, not incidental:

• No open tracking that you can trust. Proton blocks tracking pixels and remote-content tracking by default as part of its privacy stance, and its zero-access architecture means Proton cannot (and will not) surface engagement to senders. Open rates for Proton recipients are effectively meaningless.
• No click telemetry exposed. There is no sender-side reporting of recipient behavior at all.
• No content-based feedback to senders. Proton cannot read message content, so any feedback to senders is necessarily limited to abuse reports and bounces, not content signals.
• Limited sender tooling by design. There is no Postmaster-Tools/Sender-Hub equivalent. This is a deliberate consequence of the privacy model, not a missing feature.

For an audience that includes journalists, activists, and privacy-conscious users, lean entirely on delivery and complaint/abuse signals plus downstream conversions you can measure on your own properties - never on opens or clicks for Proton recipients.

Abuse reporting and appeals

Proton publishes distinct, well-defined channels - more clearly than most providers on this site:

Situation	Channel
Report an abusive Proton account (spam, bulk signups, impersonation, fraud)	proton.me/support/report-abuse form, or email abuse@proton.me
Mail-delivery or spam issues (sender-facing)	postmaster@proton.me
Still receiving spam after self-help steps	Email postmaster@proton.me with the spam message headers
Your own account wrongly hit by anti-abuse	Appeal at proton.me/support/appeal-abuse (reviewed 24/7)
Account-security / recovery issues	abuse@proton.me (per Proton’s blog)

The report-abuse form is handled via Zendesk; Proton notes you can instead email abuse@proton.me with the username/address to report, your contact address, and a description if you prefer to use Proton Mail privately. The postmaster@proton.me address is the one that matters for deliverability problems - it is Proton’s stated contact “if you have any issues with mail delivery or spam.”

Recipient-side, Proton gives users an Allow List and Block List plus custom filters (and Sieve scripts) to control spam classification per account - so an individual Proton recipient can allow-list your domain, but that is a per-user action you cannot trigger.

What Proton does NOT publish (be honest about the surface)

• No sender requirements / bulk-sender page. There is no Proton equivalent of Gmail’s or Yahoo’s sender guidelines.
• No volume threshold and no spam-complaint-rate number.
• No feedback loop (FBL) and no sender reputation dashboard.
• No published rate limits, connection limits, TLS mandate, or one-click-unsubscribe (RFC 8058) requirement for inbound senders.
• No exposure of the ML scoring - the “60% better than SpamAssassin” figure is Proton’s own claim with no published methodology.

Everything Proton publishes that resembles sender guidance is aimed at its own custom-domain customers; the inbound-sender rulebook is essentially “authenticate and send wanted mail,” enforced by an opaque learning system.

Common mistakes

• Tracking opens/clicks for Proton recipients. Proton’s privacy model makes these untrustworthy or invisible - do not segment on them.
• Expecting a feedback loop or dashboard. Neither exists; use postmaster@proton.me for delivery problems instead.
• Publishing SPF -all and then forwarding. Proton itself warns this breaks forwarded mail; it recommends ~all.
• Assuming weak DKIM is fine. Proton’s own standard is 2048-bit rotating keys - meet that bar.
• Treating the “60% better than SpamAssassin” claim as a measurable threshold. It is a vendor statement, not a number you can target.

What Egressif does

We send to Proton the way Proton itself authenticates: SPF that authorizes our real hosts (with a soft fail so forwarding survives), DKIM signing every message with strong keys, and a real DMARC policy - precisely the configuration Proton documents and uses on its own domains. Because Proton’s filtering is an opaque, learning system with no exposed score, threshold, or feedback loop, we do not chase signals that do not exist; we keep lists clean, send wanted mail, and avoid the spoofing/phishing patterns PhishGuard targets. We treat Proton recipients as an audience where opens and clicks are deliberately invisible, so suppression and engagement decisions ride on delivery, complaints/abuse signals, and conversions we can measure on our own properties - never on Proton open rates. When a real delivery problem arises, the channel is postmaster@proton.me, and we keep abuse hygiene tight so we never become the subject of an abuse@proton.me report. We make no inbox guarantee: Proton’s machine-learning system and recipient behavior decide placement, and by design we cannot see most of what it sees.

See the cross-provider provider rule tracker for how Proton compares, DMARC in 2026 for the authentication Proton recommends, and the reputation overview for the signals that matter when a provider exposes none.