1. Purpose

This document covers how phishing simulation emails move through Proton Mail, where they can get caught or flagged along the way, what needs whitelisting, and how to figure out what went wrong when a campaign doesn't land the way it's supposed to.

The goal, as with any platform in this series, is to get authorized phishing simulation emails into the right inboxes reliably, without much delay, and without loosening anything beyond the approved sender, domain, IP, and recipient list.

Worth saying up front: Proton Mail is built around a genuinely different set of priorities than most business email platforms - privacy and encryption come first, and that shapes how filtering, images, and link-handling all work. A few things that are simple toggles elsewhere (like “auto-load images from anyone”) are deliberately less simple here, because Proton designed them that way on purpose. That's not a flaw to work around so much as something to understand before you start changing settings.

One more thing: whitelisting improves the odds of clean delivery, it doesn't guarantee it. Spam classification, phishing detection, and anything sitting in front of Proton Mail are separate systems. Fixing one doesn't automatically fix the others.

2. What Needs to Be Whitelisted

Get the following from the simulation platform before the campaign starts - all four, since each one gets checked somewhere different.

A. Sending Domain

Example: securebankupdate.com

If the vendor rotates between several sending domains, get all of them up front rather than one bounced test at a time.

B. Sending IP Address

The public IP the simulation platform actually sends from. Worth noting: Proton Mail's whitelisting tools work primarily off addresses and domains rather than IPs, so this matters more for Section 12 (if there's a gateway involved) than it does inside Proton Mail itself.

Example: 82.25.108.185

C. Simulation URLs / Tracking Domains

If the campaign includes any of the following, get the domain for each one separately:

• tracking links
• phishing landing pages
• redirect URLs
• image-hosting domains
• click-tracking domains

These matter more than usual for a Proton Mail campaign - see Section 17 for why tracking links specifically can behave unexpectedly here.

3. Proton Mail - Where Whitelisting Actually Happens

Proton Mail's admin tooling is lighter than some of the platforms in this series, but it's not as thin as you might expect - Proton for Business does have a genuine organization-wide allow-listing feature, plus a few other things worth knowing about before you dive into Section 5.

3.1 Organization Spam, Block, and Allow Lists

The main mechanism, and the closest thing Proton Mail has to a “trusted sender” bypass. An organization admin can maintain lists that apply to every member of the organization, split into three categories - Spam, Block, and Allow - each with its own effect. Covered in full in Section 4.

3.2 Per-User Spam, Block, and Allow Lists

The same three categories, but scoped to a single mailbox and manageable by that user directly. These can override the organization's Spam and Allow lists for that one person - useful to know when a whitelisted sender still isn't behaving consistently across the pilot group.

3.3 PhishGuard

Proton's own anti-spoofing feature, which flags email addresses that look like they're impersonating someone the recipient would trust and marks them visibly in the inbox. Because that's exactly what a phishing simulation is designed to do, this is worth understanding on its own - see Section 11.

3.4 Tracking Protection

Not a whitelist at all, but it changes how a simulation email actually behaves once delivered - Proton routes remote images through its own proxy and strips known tracking parameters from links by default. If the simulation vendor's analytics depend on raw click tracking, this is worth knowing about ahead of time rather than discovering it partway through a campaign. Section 17 has the details.

In practice: most delivery issues come down to one of two things - the sender was never added to the organization Allow list (or was added at the wrong scope), or it was added correctly but PhishGuard or a per-user setting is still flagging the message for a reason the Allow list doesn't reach. Section 5 walks through both.

4. The Organization Allow List

This is the section that matters most for getting a simulation delivered cleanly, so it's worth understanding exactly how it behaves rather than just where to click.

How It Works

An organization admin signs in to the admin account at mail.proton.me and creates entries under Organization filters. Each entry is an email address or a domain, and it goes into exactly one of three lists:

• Spam - matching mail is sent to org members' spam folders (a member's own filter can still override this for their mailbox).
• Block - matching mail is dropped and never delivered, full stop.
• Allow - matching mail is delivered to org members' inboxes (again, a member's own filter can override this for their own mailbox).

That parenthetical matters: a user's personal Spam or Allow list can override the organization's for their own mail, but the organization's Block list cannot be overridden by an individual user. So if you're troubleshooting a case where the org Allow list is configured correctly and one user still isn't getting the message, check that user's own lists next (Section 5, Step 6) - they may have inadvertently blocked or spam-filtered the sender themselves.

Worth flagging: this is a real bypass, so scope it to exactly what the vendor publishes - the sending address and domain, never your own organization's domain. And remember it's an address/domain mechanism, not an IP mechanism - if the vendor's simulation domain changes or rotates, the Allow list entry needs updating to match, since there's no IP-based fallback the way some other platforms offer.

Also worth knowing: being on the organization Allow list gets a message delivered to the inbox, but it doesn't appear to suppress PhishGuard's spoofing indicator on its own - the two are different systems. If a whitelisted simulation email is still showing a spoofing flag, that's expected rather than a sign the Allow list didn't work; see Section 11 for what your actual options are there.

Note: if mail arrives through a gateway in front of Proton Mail, that gateway needs its own separate exception - the organization Allow list only affects what happens once Proton Mail itself receives the message. See Section 12.

5. Detailed Proton Mail Whitelisting Steps

Menu paths below reflect the current Proton Mail web interface. Proton updates its settings layout more often than some platforms, so if a label has moved, Settings → All settings is the reliable starting point for anything referenced here.

Step 1 - Sign In as an Organization Admin

1. Go to mail.proton.me and sign in with an account that has organization admin privileges. A regular member account can manage only their own personal lists (Section 5, Step 6), not the org-wide ones.
2. Some broader organization settings - access control, two-factor enforcement, branding - live at account.proton.me instead of mail.proton.me. For whitelisting specifically, mail.proton.me is where you'll spend most of your time.
3. Confirm you're working with the right organization if the admin account has access to more than one.

Step 2 - Add the Sender to the Organization Allow List

1. Go to Settings → All settings → Organization → Organization filters → Spam, block, and allow lists.
2. Select the Allow tab.
3. Click Add address or domain, choose whether you're adding an Email or a Domain, and enter the value.
4. Add both the sending domain and the specific sending address separately - don't rely on one covering the other.
5. Repeat for any additional sending domains or addresses the vendor has published.
6. There's no propagation delay to wait out here - the list applies to the next message that comes in.

Step 3 - Check the Organization Block List for Conflicts

1. Still under Organization filters → Spam, block, and allow lists, select the Block tab.
2. Search for the simulation sender's address and domain - and for the domain it's spoofing, in case an earlier incident led someone to block it.
3. A Block entry always wins over an Allow entry for the same address, and unlike the Spam and Allow lists, individual users can't override it. If it's there, it needs to come out before anything else in this section will help.
4. Remove a conflicting Block entry only with the customer's sign-off, then re-test.

Step 4 - Consider PhishGuard's Likely Reaction

1. There's no dedicated “exempt this sender from PhishGuard” setting to toggle - it isn't part of the Organization filters page.
2. Send a test message and check whether PhishGuard flags it once it's whitelisted. If it does, that's expected behavior given what PhishGuard looks for, not a misconfiguration.
3. Decide with the customer whether a visible spoofing flag on an otherwise-delivered test email is acceptable for the campaign, or whether it undermines the exercise - there isn't a clean technical way to have it both ways. More on this in Section 11.

Step 5 - Check Custom Filters

1. Go to Settings → All settings → Proton Mail → Filters → Custom filters, and check for anything an admin or a previous IT contact may have set up organization-wide, as well as anything an individual user has built for their own mailbox.
2. These are Sieve-based rules and can move, label, or forward mail based on almost any condition - including, potentially, something that inadvertently catches phishing-simulation-style content.
3. Custom filters run independently of the Spam/Block/Allow lists, so a message can clear Section 4 cleanly and still get redirected here.

Step 6 - Check the Affected User's Personal Lists

1. If one user in the pilot group isn't getting the message while others are, check that user's own Spam, Block, and Allow lists: Settings → All settings → Proton Mail → Filters → Spam, block, and allow lists, from their account.
2. Remember that a user's own Block entry isn't visible from the organization's filter page, and - for organizations using private user accounts - an admin may not be able to see it at all without the user's direct involvement, since private users' account data is only accessible through their own login.
3. This is usually a five-minute conversation with the affected user rather than something to dig for as an admin.

Step 7 - Confirm the Domain's Own SPF/DKIM/DMARC Isn't the Real Issue

1. This one's about the simulation vendor's domain, not your own organization's - but it's worth ruling out before assuming Proton Mail's filtering is misbehaving.
2. Check the vendor's SPF, DKIM, and DMARC setup (Sections 8-10) for their sending domain. A domain that fails its own authentication checks can still get flagged even with a clean Allow list entry.
3. This step is genuinely worth doing early - authentication problems are a more common cause of unexpected flagging than the Allow list being wrong.

Step 8 - If Users Access Proton Mail Through Bridge and a Desktop Client, Check That Too

1. Proton Mail Bridge lets users connect Proton Mail to a traditional desktop client - Outlook, Thunderbird, Apple Mail - over IMAP/SMTP, while keeping encryption intact locally.
2. If the pilot group uses Bridge with Outlook or another client rather than Proton's own web or mobile app, that client's own junk-mail rules and safe-senders list are a second, independent layer on top of everything in this section - a message can clear every Proton Mail setting and still get caught by the desktop client itself.
3. Ask affected users which interface they actually use before assuming the problem is on Proton's side.

Step 9 - Send a Real Test and Check Where It Lands

1. Send an actual test campaign to a small pilot group rather than relying on a single message to one inbox - individual mailbox history and personal filters can make one test misleading.
2. Check Inbox, Spam, and (if applicable) each pilot user's own filters and folders.
3. If something's still off, Section 21 covers reading the message headers, which is usually the fastest way to see what actually happened rather than guessing from symptoms alone.

6. Proton Mail Blocking / Filtering Methods

A rundown of everywhere a message can get stopped, flagged, or altered on its way to a Proton Mail inbox.

1. Machine Learning Spam Classification

Proton Mail's core spam filter, which doesn't expose the kind of tunable scoring thresholds some platforms do - it's more of a black box, though the Allow/Block/Spam lists in Section 4 sit on top of it and take precedence.

Symptom: delivered to spam despite looking like a clean message.

Action: confirm the organization Allow list entry from Section 4.

2. Organization or Personal Block List

An explicit block always wins, at either the organization or the individual level.

Symptom: message never arrives, no spam-folder landing either.

Action: check both block lists (Section 5, Steps 3 and 6).

3. PhishGuard

Flags addresses that look like they're impersonating a trusted contact or organization - which describes most phishing simulations by design.

Symptom: a visible spoofing warning on an otherwise-delivered message.

Action: see Section 11 - there isn't a clean bypass, only an expectation to set with the customer.

4. Custom (Sieve) Filters

Organization-level or personal rules that can move, label, or forward mail based on almost any condition.

Symptom: mail arrives somewhere other than the inbox, with no spam or block explanation.

Action: review custom filters at both levels (Section 5, Step 5).

5. Domain Authentication (SPF/DKIM/DMARC)

Standard email authentication, checked against the sending domain - in this case, the simulation vendor's.

Symptom: flagged or spam-folder delivery despite a clean Allow list entry.

Action: see Sections 8-10.

6. Link Protection

Proton's click-time confirmation feature, which shows the actual destination URL and asks for confirmation before opening a link, particularly on mobile.

Symptom: users see an extra confirmation step or a displayed URL before the simulation's landing page opens.

Action: usually nothing to fix - this is expected behavior and worth mentioning to pilot users so it doesn't read as a broken link.

7. Tracking Protection (Images and Links)

Proxies remote images and strips known tracking parameters from links by default.

Symptom: the simulation vendor's dashboard shows lower open/click rates than expected, even though messages are reaching users.

Action: see Section 17 - this one is more about setting expectations than fixing anything.

8. Custom Domain Authentication Issues (Your Own Domain)

If the organization's own Proton Mail domain has an SPF, DKIM, or DMARC misconfiguration, some receiving systems elsewhere may treat the org's own outgoing mail with suspicion - not directly related to receiving the simulation, but worth a quick sanity check if other odd authentication issues are showing up.

Action: Settings → Domain names → Review, to confirm all records show as verified.

9. Desktop Client Rules (If Using Bridge)

An Outlook, Thunderbird, or Apple Mail client connected via Proton Mail Bridge applies its own junk-mail handling on top of everything Proton Mail already did.

Symptom: message shows as delivered on Proton's side but the user's desktop client has it somewhere else.

Action: see Section 5, Step 8.

10. Anything Sitting in Front of Proton Mail

A gateway or filtering appliance upstream of Proton Mail's own MX records can block a message before Proton Mail ever processes it.

Symptom: the message doesn't show up in Proton Mail's headers or logs at all.

Action: see Section 12.

7. Rate Limiting and Temporary Deferrals

The Honest Answer

Proton Mail doesn't publish a specific messages-per-hour receiving limit the way some larger platforms do. That's not an oversight on our part in writing this guide — Proton positions itself as a smaller-scale, privacy-focused alternative to the big providers rather than trying to match their infrastructure documentation, and detailed throughput numbers aren't something they've made public.

What that means practically: for a typical pilot-sized campaign (dozens to low hundreds of recipients), rate limiting is unlikely to be the thing you're troubleshooting. For a genuinely large campaign against a big organization, it's worth staggering the send anyway as a matter of good practice, and watching for delivery delays or bounces rather than assuming a specific threshold exists to plan around.

What to Actually Do

• stagger a large send rather than firing everything at once, if the vendor's platform supports scheduling;
• watch for bounce messages or unusual delays during the send rather than assuming silence means success;
• if delays do show up, check the message headers (Section 21) for anything referencing a temporary deferral before assuming it's a filtering problem;
• if a genuinely large campaign is planned, it's worth a quick conversation with Proton's support team ahead of time, particularly on a Business or Enterprise plan - not something covered in this guide, but a reasonable step for anything unusually large.

8. SPF

SPF lets a receiving mail system check whether the server that sent a message was actually authorized to send on behalf of the domain it claims to be from.

What It Looks Like When SPF Is the Problem

• higher likelihood of spam-folder placement
• a visible authentication concern in the message headers
• in stricter configurations, outright rejection

If the simulation runs on a dedicated domain, that domain's SPF record needs to authorize the vendor's actual sending infrastructure - which is the vendor's DNS record to get right, not anything inside Proton Mail. Your own organization's Proton Mail domain (typically authorizing Proton with something like include:_spf.protonmail.ch) is a completely separate record and has no bearing on a third-party simulation domain.

9. DKIM

DKIM attaches a cryptographic signature to outgoing mail so the receiving side can confirm it wasn't altered in transit and really came from where it claims.

What It Looks Like When DKIM Is the Problem

• authentication failure noted in the headers
• higher spam likelihood
• a DMARC failure as a knock-on effect (Section 10)

For your own organization's domain, Proton Mail generates DKIM keys automatically when you set up a custom domain - you'll add three CNAME records under Settings → Domain names → [your domain] → DKIM. As with SPF, though, what actually matters for the simulation is the vendor's DKIM signature on their own domain, which is on them to configure correctly.

10. DMARC

DMARC ties SPF and DKIM together and tells receiving systems what to do when a message fails both: let it through and just report on it, quarantine it, or reject it outright.

Proton's own guidance for a domain's DMARC record generally recommends a quarantine policy over monitor-only or reject, as a reasonable middle ground. That's advice for your organization's own domain, though - for the simulation itself, what matters is the vendor's DMARC policy on their sending domain. If it's set to quarantine or reject and their SPF/DKIM alignment isn't clean, the message can get flagged even with a correct Allow list entry (Section 4). The fix is on the vendor's side: proper alignment, not a stronger bypass on yours.

11. Display Name Spoofing / Impersonation Protection

Unlike a couple of the other platforms in this series, Proton Mail actually has a named, purpose-built feature here: PhishGuard. It looks for email addresses that appear to be impersonating someone the recipient would recognize or trust, and marks them visibly in the inbox when it finds a likely match.

Example: From: CEO Name  [email protected]

The sender is external, the display name is made to look internal - which is precisely the pattern PhishGuard is designed to catch, and precisely the point of running the simulation in the first place.

What Actually Happens

A flagged message still gets delivered - PhishGuard marks it rather than blocking it outright - but the visible warning is likely to tip off a security-aware user before they'd otherwise engage with the test, which can skew results for that portion of the campaign.

What Your Options Actually Are

• confirm the organization Allow list (Section 4) is configured correctly - it's still worth doing, since it handles the spam and inbox-placement side even though it doesn't reach PhishGuard's own flag;
• set the expectation with the customer ahead of time that a PhishGuard flag is a plausible outcome on Proton Mail specifically, rather than something to debug as a failure;
• if the simulation vendor supports it, consider whether a display name closer to a generic external sender (rather than directly impersonating a named executive) reduces how often this fires, without changing what the campaign is actually testing.

Worth being upfront about: there's no admin setting to exempt a specific sender from PhishGuard the way there is for spam filtering. That's a deliberate design choice on Proton's part - the whole point of the feature is that it doesn't get quietly switched off for anyone, including in cases exactly like this one. Plan around it rather than searching for a toggle that isn't there.

12. Mail Server / Secure Email Gateway

Most organizations running Proton Mail on a custom domain point their MX records directly at Proton, but that's not universal - some run a gateway or filtering appliance in front of it for compliance or additional filtering reasons.

A typical path with a gateway in place looks like: internet → secure email gateway or firewall → Proton Mail → end user (via web, mobile, or Bridge and a desktop client).

What to Check

Start by confirming where MX actually points - Settings → Domain names → [domain] → Review will show whether Proton considers its own MX records properly set up, which is a reasonable proxy for whether Proton is really the first stop for incoming mail. If there's a gateway ahead of it, that product needs its own allow-list entry for the sender, domain, and IP - completely separate from the organization Allow list in Section 4, since fixing Proton's side does nothing if the gateway drops the message first.

13. Proxy Settings

This one is entirely about what happens after the email has already landed - a network proxy or secure web gateway blocking the click, not the message itself.

The email can arrive perfectly cleanly, PhishGuard-flagged or not, and the user still can't reach the simulation's landing page because something on the network side is stopping the connection.

Symptoms

• email received normally
• link doesn't open
• browser or network security warning
• redirect fails partway
• landing page never loads

Solution

Get the landing-page domain, tracking domain, redirect domain, and any other endpoints the simulation touches, and have the network team add scoped exceptions. Don't turn off proxy filtering broadly for one campaign.

14. Browser Plugins / Endpoint Security

Antivirus, EDR, and browser-level protections can still step in after the message and the network both let a click through - and because a phishing simulation is deliberately designed to look like the real thing, that's often exactly what these tools are supposed to do.

Worth remembering here: Proton's own Link Protection feature (Section 6) already adds a click-time confirmation step on some platforms, which is separate from and in addition to whatever endpoint security the user's device is running.

Symptoms

• link blocked before the page loads
• landing page itself gets blocked
• browser throws a phishing or malware warning
• redirect gets blocked partway
• click tracking doesn't register

Solution

Scoped exceptions from whoever manages the endpoint tooling, limited to the simulation's domains. Leave everything else running as normal.

15. Malware / Attachment Filtering

Here's a fair bit of nuance worth understanding: Proton Mail's zero-access encryption means that once a message is stored, Proton itself has no technical ability to read it. That naturally raises the question of how attachment scanning even works - and the answer is that non-encrypted incoming mail (which covers essentially all external senders, including a phishing simulation platform) is checked as part of the receiving process, before it's encrypted for storage. Proton doesn't publish the specifics of that scanning the way some enterprise platforms document their antivirus engine, so treat this section as directional rather than a precise technical spec.

What This Matters For

If a simulation includes an executable, a script, a macro-enabled document, or an encrypted/password-protected archive, there's a real chance it gets caught by whatever checks run during receipt - independent of anything configured in the Allow list.

Symptoms

• attachment missing from an otherwise-delivered message
• the message doesn't arrive at all
• a warning shown in the message itself referencing the attachment

The Practical Answer

There's no admin-facing setting to exempt a sender from malware scanning specifically - nothing comparable to the organization Allow list for this particular layer. For a phishing simulation, the reliable path is the same one that applies almost everywhere in this guide series: use a safe attachment type, or skip the attachment entirely, rather than trying to engineer around scanning that isn't really meant to be worked around. If an attachment is genuinely required for the exercise, confirm the exact file type and how it should be handled with the customer before the campaign goes out.

16. Warning Banners & External-Sender Indicators

Proton Mail doesn't have a separate “external sender” tag distinct from what's already covered elsewhere in this guide - the indicators a user might see all trace back to PhishGuard (Section 11) or, less commonly, a spam/tracking-related banner rather than a dedicated “this is from outside your organization” label.

What Users Might Actually See

• a PhishGuard spoofing warning, for messages that look like they're impersonating a known contact;
• a “this message contains remote content” or “load embedded images” prompt, tied to tracking protection rather than sender trust (Section 17);
• standard spam-folder placement, with no additional banner beyond being in that folder.

How to Handle It

Since none of these are separate toggles from what's already covered in Sections 4, 11, and 17, there's nothing additional to configure here - this section exists mainly to save you from hunting for an “external sender” setting that Proton Mail simply doesn't have under that name.

17. External Images

This is one of the more distinctive parts of running a phishing simulation through Proton Mail, and it's worth reading closely - the default behavior is different enough from other platforms that it can genuinely confuse a campaign's results if nobody's expecting it.

How It Actually Works

Proton Mail's tracking protection is on by default on web, iPhone, and iPad. For non-encrypted incoming mail — which describes a phishing simulation email - remote images are automatically fetched through Proton's own proxy as the message is received, using a generic IP address and location, then displayed to the user without requiring a click. That means images generally do show up automatically for the recipient. What's different is what the simulation vendor sees on their end: because the image request comes from Proton's proxy rather than the recipient's real device, tracking pixels won't reveal the recipient's actual IP, device, or open time the way they would on a platform without this kind of protection.

This is genuinely worth flagging to the customer and the vendor before the campaign runs: if the simulation's “open rate” metric depends on a tracking pixel firing from the recipient's real connection, that number may look artificially different - not because users aren't opening the email, but because Proton's proxy is what's actually fetching the pixel. Click-through and landing-page metrics are more reliable indicators of real engagement on Proton Mail than open-tracking is.

On top of that, Proton strips known tracking parameters (UTM tags and similar) from links in the message by default, as part of the same tracking-protection system. If the vendor's click-tracking relies on parameters appended to the URL, those may not survive the trip - worth testing a real link in a test message before assuming the vendor's dashboard numbers will match what actually happened.

The Setting, If It Needs Adjusting

Settings → All settings → Proton Mail → Email privacy → Block email tracking. Turning this off restores more traditional behavior - images load (or prompt to load) directly from the original sender, and links aren't cleaned - but it does so for all mail, not just the simulation, which is a real privacy trade-off for the organization to weigh, not something to flip casually for one campaign. This is a per-user setting and doesn't sync across a person's own devices, let alone across the organization, so there's no single admin toggle to change it for everyone at once.

There's also a separate, older setting - Settings → All settings → Proton Mail → Messages and composing → Auto show embedded images - which governs images attached directly to a message rather than remote/linked ones. Worth checking independently if the simulation uses embedded rather than remote images.

Symptoms

The email arrives, but a logo doesn't display, a tracking pixel doesn't register on the vendor's side despite the user having genuinely opened the message, or the vendor's open-rate numbers look unexpectedly low compared to click-through numbers.

18. Symptoms When Whitelisting Is Not Done Properly

Issue	Possible Symptom
Sender not on organization Allow list	Delivered to spam
Allow list entry at wrong scope (org vs. personal)	Works for some users, not others
Organization or personal Block entry present	Hard drop, no spam-folder landing either
PhishGuard match	Visible spoofing warning despite Allow list entry
Custom (Sieve) filter catching the message	Delivered somewhere other than Inbox, no spam/block explanation
SPF failure (vendor's domain)	Higher spam likelihood / authentication flag
DKIM failure (vendor's domain)	Higher spam likelihood / authentication flag
DMARC misalignment (vendor's domain)	Quarantine-equivalent behavior / flagged
Malware/attachment check triggered	Attachment missing or message doesn't arrive
Tracking protection proxying images	Vendor's open-rate tracking looks artificially low
Tracking protection stripping link parameters	Vendor's click-tracking data incomplete
Link Protection confirmation step	Extra click-through step before landing page opens
Secure Email Gateway block (upstream)	Message never appears in Proton Mail at all
Proxy block	Email fine, link doesn't open
Endpoint / browser security block	Link or landing page blocked after the click
Desktop client rule (via Bridge)	Delivered per Proton, but misfiled in the desktop client

19. Recommended Customer-Side Checklist

Sender Configuration

☐     Simulation sender email identified

☐     Sending domain identified

☐     Sending IP identified

☐     Tracking domain identified

☐     Landing page domain identified

Proton Mail Configuration

☐     Sender and domain added to organization Allow list

☐     Organization Block list checked for conflicts

☐     PhishGuard behavior discussed and expectations set with the customer

☐     Custom filters (organization and personal) reviewed

☐     Vendor's SPF/DKIM/DMARC confirmed clean

☐     Confirmed whether pilot users access Proton Mail via web/mobile or via Bridge and a desktop client

Network

☐     Firewall checked

☐     Secure Email Gateway (if any) checked

☐     Proxy checked

☐     DNS filtering checked

☐     URL filtering checked

Endpoint

☐     Antivirus checked

☐     EDR checked

☐     Browser security checked

☐     Browser plugins checked

Simulation

☐     Test campaign completed

☐     Inbox delivery confirmed

☐     Spam folder checked

☐     PhishGuard flag status confirmed either way

☐     Open-rate and click-tracking expectations set with the vendor given tracking protection

☐     Links tested

☐     Landing page tested

☐     Attachment handling confirmed clean, if applicable

20. Troubleshooting

Case 1 - Email Never Arrives. Check whether it shows up anywhere in the recipient's account at all (Section 21) - if it doesn't, look upstream for a gateway (Section 12) before assuming Proton Mail is the cause. If it does show up somewhere, check the organization and personal Block lists (Section 5, Steps 3 and 6) next.

Case 2 - Email Lands in Spam. Almost always an Allow list problem: confirm the entry exists at the organization level and matches the sender exactly (Section 4), then check the vendor's SPF/DKIM/DMARC (Sections 8-10) if it's still landing in spam after that.

Case 3 - Email Arrives but Shows a Spoofing Warning. This is PhishGuard, not a delivery failure - see Section 11. There's no bypass to configure; this is a conversation to have with the customer about expectations, not a setting to fix.

Case 4 - Some Users Get It Cleanly, Others Don't. Check each affected user's personal Spam, Block, and Allow lists (Section 5, Step 6), and whether some users access Proton Mail through Bridge and a desktop client with its own rules (Section 5, Step 8).

Case 5 - Vendor's Dashboard Shows Low Open Rates Despite Users Reporting They Saw the Email. This is very likely tracking protection (Section 17), not a delivery problem - check click-through numbers instead of open-rate numbers as the more reliable signal.

Case 6 - Email Arrives but the Link Doesn't Work. Check the proxy (Section 13) and endpoint/browser security (Section 14) first - and rule out Proton's own Link Protection confirmation step (Section 6) before assuming something's actually broken.

Case 7 - Attachment Is Missing or the Whole Message Never Arrived. Check Section 15 before assuming this is a whitelisting issue - it's more likely the attachment itself than the sender.

Case 8 - Delivered Cleanly per Proton, but the User's Desktop Client Shows Something Different. Confirm whether that user is on Bridge with Outlook, Thunderbird, or Apple Mail (Section 5, Step 8) - the desktop client's own junk-mail handling is a separate layer from anything covered elsewhere in this guide.

21. Headers & Message Source Analysis

This section supports Section D (Delivery Logs & Evidence) of the Diagnostic Questionnaire. Worth setting expectations here: Proton Mail doesn't offer an admin-facing, organization-wide log search the way some platforms in this series do - there's no central console showing every message's delivery path across the organization. Troubleshooting on Proton Mail leans more on the individual message's own headers, and on talking to the affected user directly.

Viewing a Message's Headers

1.     Open the message in question, whether in the affected user's account or a test mailbox.

2.     Click the three-dot More menu and select View headers.

3.     The headers open in a new window (on mobile, a Message headers sheet) showing the standard fields - Received (the path the message took, hop by hop), and Authentication- Results (the outcome of SPF, DKIM, and DMARC checks).

4.     On mobile, headers can be downloaded as a .txt file directly from that screen, which is useful for sending to the customer or the simulation vendor for their own review.

What to Actually Look For

The Authentication-Results field is the most useful single thing to check - it tells you plainly whether SPF, DKIM, and DMARC passed for the message, which rules authentication in or out as the cause before you go looking anywhere else. Beyond that, comparing the full headers of a message that landed cleanly against one that didn't - different recipients, same campaign - is usually the fastest way to spot what's actually different between the two, rather than guessing from symptoms alone.

22. Proton for Business Plans - What's Actually Included

This section supports Section C (Proxy, URL Rewriting & Sandboxing) and the related items in Section E (Whitelisting Checklist) of the Diagnostic Questionnaire - mainly because it affects how many custom domains an organization can run and what other tooling is available, even though the core whitelisting mechanics in this guide don't change much between tiers.

• Mail Essentials - the entry-level business plan: email and calendar, support for a handful of custom domains, and the organization admin panel described throughout this guide.
• Proton Workspace (Standard and Premium) – the fuller business suite, adding the rest of Proton's apps (Drive, Pass, VPN, Meet), more custom domains, and - on Premium - data retention policies, which are worth knowing about separately since they can affect how long test campaign emails are retained in members' mailboxes.
• Proton Enterprise - a customizable plan for larger organizations, with everything in Workspace plus dedicated account support and negotiated terms.

Practical implication for whitelisting: the organization Spam/Block/Allow lists, PhishGuard, and tracking protection all work the same way regardless of plan tier - they're core Proton Mail behavior, not features gated to the top of the pricing table. What actually changes between tiers is more about domain limits, storage, and which other Proton apps are bundled in, plus (at the Enterprise tier) more direct support if something needs escalating. Note that Proton has renamed and restructured its business tiers before and may again - if a customer references a plan name that doesn't match what's described here, it's worth a quick check of Proton's current business page rather than assuming this guide is out of date on the mechanics themselves.

As with every platform in this series: if a third-party secure email gateway sits in front of Proton Mail with its own filtering or sandboxing, it needs its own exclusion inside that product, in addition to - not instead of - everything covered in Section 5.