Proton Mail Email Verification

What Proton's MX records look like

Proton hosted domains publish MX records pointing at Proton's own infrastructure under protonmail.ch, typically mail.protonmail.ch as the primary host with mailsec.protonmail.ch as a secondary. The same MX set serves protonmail.com, proton.me and pm.me, and custom domains hosted with Proton point at it as well. Mailthentic recognises Proton from the MX chain rather than the visible domain, so a company running its own domain on Proton is correctly classified as Proton infrastructure rather than being mistaken for a self hosted server.

How Proton answers an SMTP probe

Proton validates recipients during the SMTP conversation. An address that does not exist draws a permanent rejection in the 550 family, commonly with wording to the effect that there is no such user. A real mailbox draws a 250. That means a Proton mailbox can genuinely be confirmed over SMTP, unlike on Google or Microsoft, where a 250 tells you nothing about the recipient. Mailthentic opens the conversation, issues RCPT TO, and stops before DATA. No message is ever sent, and nothing is ever delivered to the person behind the address.

Mailthentic also runs its catch all detection pass against Proton domains, probing with a randomly generated local part that could not belong to anyone. Proton rejects it, which confirms the domain is not accept all and that a 250 on a real address is a meaningful signal rather than a reflex.

Privacy posture and what it means for probing

Proton is engineered around minimising what the outside world can learn about its users, and that principle extends to its inbound servers. It is conservative about talking to unfamiliar sources, and it is quick to defer or throttle an IP that behaves like it is enumerating addresses. Probing Proton at speed is the fastest way to learn nothing at all.

It is worth being precise about what a verification probe does and does not reveal, because Proton's users care about this. The probe asks Proton's server whether it would accept mail for an address you already hold. It does not read mail, it cannot see the contents of any mailbox, it cannot decrypt anything, and Proton's end to end encryption is not touched by it in any way. Verification operates entirely at the transport layer and stops before any message data exists. The one thing it does establish is whether an address is routable, which is exactly the same thing that any sender learns the moment they send a message.

Rate limiting, deferrals and greylisting

Expect temporary responses. Proton returns codes in the 421, 450 and 451 families when it wants a source to slow down, and these are requests to back off rather than statements about the recipient. Mailthentic treats all three as deferrals, retries with an increasing backoff, and only decides once the server gives a stable permanent answer. It also paces probes against the Proton MX cluster rather than against individual domains, which matters because custom Proton domains all share the same endpoints. A deferral is never converted into an invalid verdict.

So what does a Proton result actually mean?

A 550 for an unknown user is a definitive answer and the address should be removed. A 250 is a real confirmation that the mailbox exists, and it carries far more weight than the same code from an ambiguous provider. An unknown verdict on Proton usually means the platform deferred the probe rather than that the address is bad, and it should be re queued rather than deleted. As always, existence is not permission: a Proton address can be perfectly valid and still belong to somebody who will report your message the moment it lands.

Verify slowly and read the deferrals correctly

Proton will throttle a source that probes hard, and the resulting temporary codes look like failures if you squint at them. They are not. Let the backoff and retry logic run, accept that a Proton heavy segment takes longer to process than a Gmail heavy one, and treat anything that still will not resolve as unknown rather than invalid.

What to do with each verdict

• Invalid. Proton told you plainly that the user does not exist. Suppress permanently.
• Valid. A genuine confirmation that the mailbox is real and routable. This is a trustworthy result on Proton, unlike on accept-all providers.
• Unknown or deferred. Almost always throttling, not a bad address. Re queue in a smaller batch. If it still will not resolve, fall back on acquisition source and engagement history rather than guessing.
• Risky. Role addresses, disposables and prior bouncers come out regardless of what the probe said.

Consent matters more here than almost anywhere

This is the practical point that senders underestimate. People choose Proton deliberately, usually because they want to be left alone. A Proton address on a purchased, scraped or otherwise unconsented list is not just a legal problem, it is a complaint waiting to happen, and a valid verification result gives you no cover whatsoever. Verification confirms that an address exists. It never confirms that the person agreed to hear from you. Mail Proton contacts only where you have a clear, documented opt in, and be able to show where it came from.

Protecting deliverability into Proton

• Authenticate. SPF, DKIM and DMARC on your sending domain are expected, and Proton's users are the sort of audience for whom authentication failures are noticed.
• Warm new IPs and domains gradually. Proton is conservative with unfamiliar sources and will defer a cold sender that arrives with a burst.
• Make unsubscribing trivial. A one click unsubscribe that works instantly is far cheaper than a spam complaint from a privacy minded recipient.
• Do not rely on open tracking. Proton blocks remote image loading by default for many users, so open rates from Proton contacts are systematically understated. Use clicks, replies and conversions to judge engagement, and do not prune a Proton segment for looking dead when the tracking pixel was simply never allowed to fire.

Verify at capture, then again before a large send

Catching a typo on the signup form is the cheapest verification you will ever do, and on Proton it produces an immediate, definitive answer you can surface to the user in the moment. Re verify before big campaigns so closed accounts leave the list before Proton sees them.