1. Purpose

This document walks through how phishing simulation emails actually make their way - or don't - to users on a Zimbra mail system, where they can get stuck or flagged along the way, what needs to be whitelisted, and how to track down the problem when a campaign isn't landing the way it should.

The goal is simple to state and occasionally fiddly to achieve: get authorized phishing simulation emails into the intended inboxes reliably, without much delay, and without opening the door any wider than the approved sender, domain, IP, and recipient list.

2. What Needs to Be Whitelisted

Before the campaign starts, get the following from the simulation platform - all four, not just the sender address, since each one gets checked at a different point.

A. Sending Domain

Example: securebankupdate.com

If the vendor rotates between multiple sending domains for realism, get all of them up front rather than discovering them one bounced campaign at a time.

B. Sending IP Address

The public IP (or IP range) the simulation platform actually sends from - not the IP the user's browser connects from after they click the link, which is a completely different thing and a surprisingly common mix-up.

Example: 82.25.108.185

Ask the vendor for their full published sending range, since most simulation platforms send from more than one server.

C. Simulation URLs / Tracking Domains

If the campaign includes any of the following, get the domains for each - they don't all live on the sending domain and often need separate handling:

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

3. Zimbra - Where Whitelisting Actually Happens

Unlike a hosted platform with one “Allowed senders” screen, Zimbra spreads this across a handful of places, and which one you need depends on what's actually blocking the message. Here's the map before we get into the how-to.

3.1 The Amavis Whitelist (amavisWhitelistSender)

The core mechanism: a per-account, per-domain, or per-Class-of-Service attribute that tells Amavis - the traffic cop that sits between Postfix and SpamAssassin/ClamAV - to treat mail from a given address or domain as trusted. This is the closest thing Zimbra has to a “trusted sender” bypass, and it's covered in full in Section 4.

3.2 SpamAssassin Local Rules

A more surgical option: a custom rule file that gives a large negative score to mail matching a specific pattern - commonly a custom header the simulation vendor adds to their test emails. This is, in fact, Zimbra's own documented recommendation for whitelisting phishing simulation traffic specifically, and it pairs well with the Amavis whitelist rather than replacing it. Also in Section 4.

3.3 MTA Trusted Networks

A connection-level setting (Global Settings, or per-server) that tells Postfix which networks get relaxed handling. It's tempting to reach for this first because it sounds like exactly what you want, but it's a blunter instrument than it looks - see the caution in Section 5, Step 4.

3.4 Spam Scoring Thresholds (Tag / Kill Percent)

Not a whitelist at all, but worth understanding early: every message gets a spam score, and two global thresholds - Tag Percent and Kill Percent - decide whether it's delivered normally, tagged and dropped in Junk, or discarded outright. A message can clear the Amavis whitelist and still get caught here if something else about it scores high enough. More in Sections 6 and 7.

In practice: most delivery problems trace back to one of two things - the sending address or domain was never added to the Amavis whitelist at the right level (account vs. domain vs. Class of Service), or it was added correctly but something else in the stack (an RBL hit, a virus-scanner false positive, a stray Sieve filter) is catching the message anyway. Section 5 walks through both in order.

4. The Amavis Whitelist and the Local SpamAssassin Override

This is the section to read closely - it's the mechanism that does the actual bypassing, and Zimbra's own wiki documents almost this exact scenario (whitelisting a phishing test service), so what follows leans on that rather than guesswork.

The amavisWhitelistSender Attribute

Set via the zmprov command-line tool rather than a form field in the admin console. It can be applied to a single account, an entire domain, or a Class of Service, and it accepts either a full address or a bare domain:

Account level: zmprov ma [email protected] +amavisWhitelistSender [email protected]

Domain level: zmprov md company.com +amavisWhitelistSender securebankupdate.com

The + in front of the attribute name matters - it appends the entry instead of overwriting whatever's already there. Leave it off and you'll quietly wipe out any existing whitelist entries, which is a mistake you generally only make once.

The Local Rule / Custom Header Override

If the simulation vendor's emails carry a distinguishing custom header - many platforms add one specifically so receiving mail systems can whitelist them - you can write a small SpamAssassin rule that scores any match so far into negative territory that nothing else could realistically outweigh it:

Add to /opt/zimbra/data/spamassassin/localrules/sauser.cf (create the file if it isn't there yet):

Rule: header PH_CHK X-PHISHTEST =~ /^PRILOCK$/

Score: score PH_CHK -99.0

Swap in whatever header and value the vendor actually publishes — the example above is illustrative, not a real header to copy. Restart Amavis after saving (zmamavisdctl restart) or the new rule won't be picked up.

Fair warning: both of these are strong bypasses, so scope them tightly. Whitelist the vendor's actual address or domain - never the organization's own domain - and if you go the local-rule route, make the header match as specific as possible. A loose regular expression here is the kind of thing that looks fine in testing and causes a headache eighteen months later when nobody remembers why it's there.

Also worth flagging: the Amavis whitelist skips content filtering - spam scoring - but it does not disable ClamAV's virus scan. A simulation attachment that trips a heuristic match (encrypted archives are a classic culprit) can still get blocked, and Zimbra doesn't have a clean, built-in way to whitelist a sender specifically for antivirus. See Section 15 for what your options actually are there, which, to be honest, aren't great.

Note: if mail arrives through a gateway in front of Zimbra, that gateway needs its own exception too - the Amavis whitelist only affects what happens once the message reaches Zimbra's own filtering. See Section 12.

5. Detailed Zimbra Whitelisting Steps

Menu labels below match a recent Zimbra Collaboration release; older installs may look slightly different, but the underlying zmprov attributes haven't changed in years and are the more reliable reference point if a screen looks different than expected.

Step 1 - Sign In and Get Your Bearings

1. Log in to the admin console, typically at https://:7071 - the port matters, and it's easy to forget.
2. You'll need a Global Admin account, or a delegated admin with rights over the relevant domain/COS. A regular mailbox user has no access here.
3. Most of what follows lives under Configure in the left-hand navigation - Class of Service, Domains, Global Settings, and Servers all show up there.
4. If you'll be running zmprov commands (and for the whitelist itself, you will), you'll need shell access to a mailbox or MTA server, running commands as the zimbra user.

Step 2 - Add the Sender to the Amavis Whitelist

1. Decide the right scope: a single pilot account, an entire domain, or a Class of Service shared by the pilot group. Domain-level is the most common choice for a full campaign.
2. SSH to a mailbox server and switch to the zimbra user, or prefix each command with su - zimbra -c "...".
3. Run zmprov md +amavisWhitelistSender for a domain-wide entry, or zmprov ma +amavisWhitelistSender for a single account.
4. Add the sending domain and, separately, the exact sending address - both, not one or the other.
5. Confirm it took: zmprov gd | grep amavisWhitelistSender (or zmprov ga for an account).
6. Changes to this attribute are picked up on the next message - there's no propagation delay to wait out, unlike some hosted platforms.

Step 3 – Add the SpamAssassin Header Override (If the Vendor Supports It)

1. Ask the vendor whether their platform adds a custom header to identify itself - most established phishing simulation platforms do, precisely for this purpose.
2. If so, edit (or create) /opt/zimbra/data/spamassassin/localrules/sauser.cf as the zimbra user and add the header match and score, as shown in Section 4.
3. Restart Amavis: zmamavisdctl restart.
4. Send a test message and check its headers (Section 21) to confirm the rule actually fired - don't just assume it worked because nothing broke.

Step 4 – Consider MTA Trusted Networks (Usually Not Needed - Read This First)

1. Global Settings → MTA → MTA Trusted Networks lists the network ranges Postfix treats as trusted for relaying and relaxed checks.
2. Resist the urge to add the simulation vendor's IP here just because it sounds like the right place - this setting is about relay permissions, not spam scoring, and a network added here can end up able to relay mail through your server to anywhere, not just receive it. That's a much bigger door than you meant to open.
3. In the overwhelming majority of cases, Steps 2–3 are what you actually need. Only touch Trusted Networks if you've confirmed - via message headers, not a guess - that a connection-level restriction, not spam scoring, is what's blocking the message.
4. If you do add an entry, scope it to the narrowest possible range and put a reminder somewhere to remove it after the campaign.

Step 5 - Check Spam Scoring Thresholds

1. Global Settings → AS/AV shows the current Tag Percent and Kill Percent (defaults are typically 33% and 75%).
2. A whitelisted sender that somehow still triggers a very high score - through SpamAssassin rules the whitelist doesn't touch - can still get caught by Kill Percent. This is uncommon once Steps 2–3 are done correctly, but it's the next thing to check if mail is still disappearing.
3. Don't lower Kill Percent organization-wide to solve a single campaign - that weakens spam protection for every user, every sender, indefinitely. Fix the whitelist entry instead.

Step 6 – Check for Conflicting Blocklist Entries

1. Run zmprov gd | grep amavisBlacklistSender (and the account-level equivalent) to see whether the simulation sender - or, more likely, the domain it's spoofing - is already blacklisted from an earlier incident.
2. A blacklist entry always wins over a whitelist entry for the same address. If one exists, it needs the customer's sign-off before you remove it, not just your own judgment call.
3. Check any IP-level blocks too - firewall rules or fail2ban-style tools are common on self-hosted Zimbra installs and won't show up in zmprov at all.

Step 7 - Check User-Level “Not Junk” Marks and Personal Filters

1. Individual users can mark a message as Not Junk from the Zimbra Web Client, which whitelists that sender for their own mailbox only - in Zimbra 9's Modern UI this is a native right-click action, no add-on required.
2. Users can also set up personal mail filters (Preferences → Filters) that could catch or redirect the simulation before it's ever seen.
3. These are invisible to you as an admin unless you ask the affected user directly or check their account's Sieve script via zmprov ga mailSieveScript.

Step 8 – Check Attachment Type Blocking

1. Global Settings → MTA includes a list of blocked file extensions - messages with a matching attachment are rejected outright, with both sender and recipient notified by default.
2. If the simulation includes an attachment, confirm its file type isn't on this list before assuming a delivery failure is a whitelisting problem.
3. This setting is global, so don't disable it entirely for one campaign - if the simulation's attachment type is genuinely blocked, ask the vendor for an alternative format instead.

Step 9 – Check the Mail Queues

1. A message that's neither delivered nor bounced is usually sitting in a Postfix queue somewhere - incoming, active, deferred, or hold.
2. From the CLI: postqueue -p (or the older mailq) lists everything currently queued, with a reason logged next to anything stuck.
3. The deferred queue is the one to watch during a large campaign - it means Zimbra accepted the message but hasn't been able to hand it off yet, which is different from a rejection and usually resolves on its own. Section 7 has more on why this happens.
4. Full detail on reading logs and queue output is in Section 21.

6. Zimbra Blocking / Filtering Methods

A rundown of everywhere a message can get stopped, slowed, or flagged - useful as a checklist when you're not sure yet which layer is the culprit.

1. Connection-Level / Protocol Checks

Postfix rejects some connections before a message is even accepted - missing reverse DNS, a HELO that isn't a proper hostname, that kind of thing.

Symptom: connection refused, SMTP error before the message is even queued.

Action: check Global Settings → MTA protocol check options, and the sending server's own reverse DNS setup.

2. DNS Blocklists (RBLs)

Zimbra can check the sending IP against one or more DNS-based blocklists as part of connection handling.

Symptom: rejection with an RBL reference in the bounce message.

Action: check whether the vendor's sending IP shows up on Spamhaus, SpamCop, or whichever lists are enabled — this is on the vendor to get delisted, not something to fix inside Zimbra.

3. Amavis / SpamAssassin Content Scoring

The main event: every message gets scored, and the score decides its fate.

Symptom: delivered but tagged and moved to Junk, or discarded above the Kill threshold.

Action: confirm the Amavis whitelist entry from Section 4, and check the actual score in the message headers (Section 21).

4. ClamAV Antivirus Scanning

Every message and attachment gets scanned; a match blocks the message regardless of any spam whitelist.

Symptom: rejection or quarantine specifically tied to a virus signature or heuristic, not a spam score.

Action: see Section 15 - realistically, this usually means changing the attachment rather than fixing a setting.

5. Attachment Type Blocking

A message with a disallowed file extension is rejected outright, independent of spam or virus scanning.

Symptom: immediate rejection, notification sent to sender and recipient.

Action: check Global Settings → MTA's blocked-extensions list (Section 5, Step 8).

6. MTA Trusted Networks / Relay Restrictions

Governs what's allowed to relay through the server, and interacts with some connection-level checks.

Symptom: relay access denied, or (if misconfigured the other way) an unintended open relay.

Action: see the caution in Section 5, Step 4 before touching this one.

7. Personal Filters and Not-Junk/Blacklist Marks

Anything an individual user has set up in their own mailbox, invisible at the admin level.

Symptom: inconsistent results - some users get the email cleanly, others don't.

Action: ask the affected user, or check their Sieve script directly (Section 5, Step 7).

8. Mail Queue Deferrals

Temporary delivery problems - often on the vendor's sending side, sometimes local resource limits - land a message in the deferred queue instead of delivering or bouncing it.

Symptom: delayed delivery, message eventually arrives (or eventually bounces after the bounce queue lifetime, five days by default).

Action: postqueue -p, and see Section 7.

9. Domain Impersonation Getting Flagged as Spam

Because a phishing simulation deliberately imitates a real sender, generic spam-scoring rules around suspicious headers or lookalike domains can catch it - this isn't a dedicated “impersonation protection” feature the way some platforms have, just SpamAssassin doing what it's designed to do.

Symptom: high spam score despite a clean sending reputation.

Action: see Section 11.

10. Anything Sitting in Front of Zimbra

A gateway, firewall, or DNS filter upstream of Zimbra can block a message before it ever reaches any of the above.

Symptom: the message never shows up anywhere in Zimbra's own logs or queues at all - which is itself a useful clue.

Action: see Section 12.

7. Rate Limiting and Temporary Deferrals

How Zimbra Handles a Sudden Burst of Mail

Zimbra doesn't publish a clean “messages per hour” ceiling the way some hosted platforms do - what actually happens is a function of your server's own resources and Postfix's queue behavior. Send a large campaign all at once and a few things can happen: the active queue fills up and new messages wait their turn, Amavis (which spawns a limited number of scanning processes) becomes the bottleneck, or the deferred queue starts filling with temporary failures if your server or the vendor's sending infrastructure is under load.

None of this is a rejection in the spam-filtering sense - it's just traffic. A message sitting in the deferred queue will keep retrying until it either gets through or hits the bounce queue lifetime (five days by default, adjustable via zmlocalconfig's bounce_queue_lifetime setting).

What to Actually Do About It

• stagger a large campaign instead of sending it all in one burst, if the vendor's platform supports scheduling
• keep an eye on the deferred queue during the send (postqueue -p) rather than assuming silence means success
• check /var/log/zimbra.log for repeated deferral messages tied to the same sender or IP - that pattern usually points to a specific, fixable cause rather than general overload
• if the server itself is under-resourced for the burst, that's a capacity conversation with whoever manages the infrastructure, not a whitelisting fix.

8. SPF

SPF is the mechanism that lets a receiving mail server check whether the machine that sent a message was actually authorized to send on behalf of the domain in question.

What It Looks Like When SPF Is the Problem

• higher spam score than expected

• delivered to Junk despite a whitelist entry

• outright rejection, in stricter configurations

If the simulation runs on its own dedicated domain, that domain's SPF record needs to authorize the vendor's actual sending servers - and that's the vendor's DNS record to fix, not anything inside Zimbra. Your own domain's SPF record (whatever it currently authorizes for your own outbound mail) has no bearing on a third-party simulation domain and doesn't need to change for a campaign.

9. DKIM

DKIM attaches a cryptographic signature to outgoing mail, letting the receiving side confirm the message wasn't altered in transit and really did come from where it claims.

What It Looks Like When DKIM Is the Problem

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

On the Zimbra side, DKIM signing for your own domains is generated with zmdkimkeyutil -a -d yourdomain.com, run as the zimbra user on an MTA server - it drops a public key into LDAP and gives you the DNS TXT record to publish. Zimbra 8.7 and later default to a 2048-bit key. As with SPF, none of this is what matters for the simulation itself - the DKIM signature that needs to be valid is the vendor's, on their domain, which is on them to get right.

10. DMARC

DMARC ties SPF and DKIM together and tells receiving systems what to do when a message fails both - monitor it, quarantine it, or reject it outright.

A quick honest note here: out of the box, Zimbra's SpamAssassin/Amavis stack doesn't enforce inbound DMARC the way Google or Microsoft's filtering does natively. Some admins add DMARC checking through SpamAssassin plugins, and some have moved to Rspamd as a SpamAssassin replacement specifically because it handles this more cleanly - if your installation has gone that route, the specifics will differ from what's described elsewhere in this guide, and it's worth checking with whoever manages the server.

What this means practically: if the vendor's DMARC policy on the simulation domain is set to quarantine or reject and their SPF/DKIM alignment isn't clean, the failure will most likely show up as a generic authentication problem contributing to the spam score, rather than a dedicated DMARC rejection. The fix is the same either way - ask the vendor to get their authentication properly aligned rather than relying on the whitelist to paper over it indefinitely.

11. Display Name Spoofing / Impersonation Protection

Here's the honest version of this section: Zimbra doesn't have a dedicated, purpose-built impersonation-detection feature the way some hosted platforms do - no toggle labeled “warn on display name spoofing.” What it has instead is SpamAssassin's general-purpose rule set, which includes rules that react to exactly the kind of thing a phishing simulation does on purpose: a display name that doesn't match the sending domain, headers that look inconsistent, that sort of thing.

Example: From: CEO Name  [email protected]

The sender is external, but the display name is deliberately made to look like someone internal - which is, of course, the entire point of the exercise.

What Actually Happens

This shows up as extra points added to the spam score rather than a distinct warning label or banner. If it's enough to push the message over the Tag or Kill threshold, that's what you're seeing - not a separate “impersonation” feature working against you.

What to Do About It

• confirm the Amavis whitelist and, if applicable, the SpamAssassin header override from Section 4 are both in place - a clean whitelist entry generally outweighs the extra scoring
• if a message is still scoring high after that, pull up the headers (Section 21) and look at exactly which SpamAssassin rules fired - that tells you precisely what's contributing, rather than guessing
• as a last resort, a targeted local rule (the same mechanism from Section 4) can down-weight a specific rule for the simulation's traffic pattern - but that's a scalpel, not something to apply broadly.

Don't, whatever you do, disable or gut SpamAssassin's spoofing-related rules organization-wide to make one campaign land cleanly. That protection is doing real work the other 364 days of the year.

12. Mail Server / Secure Email Gateway

Plenty of Zimbra deployments aren't the first thing mail hits - there's often a gateway, a spam appliance, or a firewall sitting in front of it, especially in larger or more security-conscious environments.

A typical path looks like: internet → secure email gateway or firewall → Zimbra (Postfix/Amavis/SpamAssassin/ClamAV) → end user. Anything in that first hop - Proofpoint, Barracuda, Mimecast, a hardware appliance, whatever the customer runs - does its own filtering before Zimbra ever sees the message.

What to Check

First, confirm where MX actually points - it's a two-minute DNS lookup and it's surprising how often “why isn't whitelisting working” turns out to be “mail isn't even reaching Zimbra yet.” If there's a gateway in the path, it needs its own allow-list entry for the sender, domain, and IP, completely separate from everything in Sections 4–5 - fixing Zimbra's side does nothing if the gateway drops the message first. And if this is a Zimbra environment set up in a hybrid arrangement with another mail system, check that side's rules too.

13. Proxy Settings

This one has nothing to do with Zimbra itself - it's entirely about what happens after the email is already sitting in the inbox.

The message can arrive perfectly cleanly and the user still can't reach the simulation's landing page, because a proxy or secure web gateway is blocking the click, not the email.

Symptoms

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

Solution

Get the landing-page domain, tracking domain, redirect domain, and any other HTTPS endpoints the simulation touches, and have the network team add scoped exceptions for those specifically. Don't turn off proxy filtering broadly just to get one campaign through - that defeats the purpose of having it.

14. Browser Plugins / Endpoint Security

Even after the email lands and the proxy lets the connection through, antivirus, EDR, and browser-level protections can still step in - and because a phishing simulation is designed to look exactly like the real thing, this is often working as intended, just not in a way you want during a sanctioned test.

Common culprits: endpoint antivirus, EDR agents, browser phishing/malware warnings (built-in ones like Chrome's or Edge's Safe Browsing-style protections, or a third-party security extension), DNS-level filtering.

Symptoms

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

Solution

Scoped exceptions, added by whoever manages the endpoint tooling, limited to the simulation's domains. Leave the rest of the protection alone - it's not the enemy here, it's just doing its job a little too well.

15. Malware / Attachment Filtering

ClamAV scans every message and attachment that passes through Amavis, and - as covered in Section 4 - the Amavis whitelist doesn't touch this. It only affects spam scoring.

This matters most when a simulation includes: an executable, a script, a macro-enabled document, an encrypted or password-protected archive, or really any file type ClamAV's heuristics have opinions about.

Symptoms

• attachment stripped from the message
• entire message rejected or dropped
• a warning noted in the logs referencing a specific virus signature or heuristic name

The Honest Answer Here

There's no clean, built-in “whitelist this sender for antivirus” switch in Zimbra the way there is for spam. Admins who've hit this have generally ended up either avoiding the attachment type that trips the scanner (the simplest fix, and usually the right one for a simulation), or hand-editing Amavis/Postfix configuration to bypass scanning on a specific port or condition - which works, but is fiddly, easy to get wrong, and worth doing only with someone who's comfortable in that configuration. For a phishing simulation specifically, the simplest real-world answer is almost always: use a safe attachment type, or no attachment at all, and don't go fighting ClamAV over it.

If an attachment is genuinely required, confirm the exact file type and how it should be handled with the customer before the campaign goes out - not after it bounces.

16. Warning Banners & External-Sender Indicators

Another honest one: out of the box, Zimbra doesn't tag external mail with a banner or label the way some platforms do. There's no native “this message is from outside your organization” indicator built into the base Zimbra Web Client.

What you will see, if anything, comes from one of two places: a Zimlet (Zimbra's plugin system) that a given deployment has installed specifically to add this kind of labeling, or a Sieve-based mail rule an admin has set up to prepend something like [EXTERNAL] to the subject line of messages from outside the organization - essentially a homemade version of the feature.

How to Handle It

If the customer's environment has either of those in place and it's affecting how the simulation looks or gets sorted, that's a conversation with whoever manages the Zimlet or the Sieve rule - not a setting covered elsewhere in this guide. If neither is in place, there's nothing to configure here at all, and this section is mostly to save you from hunting for a setting that doesn't exist.

17. External Images

Like most webmail clients, Zimbra can hold back automatic image loading in HTML email - this is a per-user Zimbra Web Client preference, not anything set at the admin console.

Symptoms

The email arrives fine, but the logo doesn't show up, a tracking pixel never fires, or the user sees a prompt asking whether to display images before anything loads.

Solution

In the Zimbra Web Client: Preferences → Mail → Displaying Messages, and check the box for "Download pictures automatically in HTML Email".

18. Symptoms When Whitelisting Is Not Done Properly

Issue	Possible Symptom
Sender not in Amavis whitelist	Spam score applied / delivered to Junk
Whitelist added at wrong level (account vs. domain)	Works for one user, not the pilot group
Local SpamAssassin rule missing or wrong	Header-based override doesn't fire
Kill Percent threshold exceeded	Message discarded outright
SPF failure	Higher spam score / Junk placement
DKIM failure	Higher spam score / authentication flag
DMARC misalignment	Contributes to spam score (no dedicated DMARC action by default)
Spoofing-pattern rules firing	Elevated spam score, no separate warning banner
Blacklist entry present	Hard block regardless of whitelist
RBL hit on sending IP	Connection-level rejection
Attachment type blocked	Immediate rejection with sender/recipient notice
ClamAV heuristic match	Attachment stripped or message dropped
MTA queue congestion / deferral	Delayed delivery
Secure Email Gateway block (upstream)	Message never appears in Zimbra logs at all
Proxy block	Email fine, link doesn't open
Endpoint / browser security block	Link or landing page blocked after the click
External images setting (per user)	Images not shown automatically

19. Recommended Customer-Side Checklist

Sender Configuration

☐     Simulation sender email identified

☐     Sending domain identified

☐     Sending IP identified

☐     Tracking domain identified

☐     Landing page domain identified

Zimbra Configuration

☐     Amavis whitelist entry added (correct level: account / domain / COS)

☐     Both sending address and sending domain whitelisted

☐     SpamAssassin local rule / header override configured, if the vendor supports it

☐     Confirmed MTA Trusted Networks was NOT needed (or added narrowly, with a removal reminder)

☐     Spam Tag/Kill thresholds reviewed

☐     Blacklist entries checked for conflicts

☐     Attachment type checked against the blocked-extensions list

☐     Mail queues checked for deferrals

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

☐     Junk folder checked

☐     ClamAV / attachment handling confirmed clean

☐     External images checked

☐     Links tested

☐     Landing page tested

☐     Tracking tested

☐     Large-campaign send tested against real queue behavior, not just a single test message

20. Troubleshooting

Case 1 - Email Never Arrives. Check, in this order: whether it shows up in the mail queue or logs at all (Section 21) - if it doesn't, look upstream at any gateway or firewall first (Section 12); if it does, check for a blacklist entry (Section 5, Step 6), an RBL hit, or a hard rejection logged against it.

Case 2 - Email Lands in Junk. Almost always a whitelist problem: check the Amavis whitelist is set at the right level for the affected users (Section 4), then check the actual spam score in the headers (Section 21) to see what's still contributing points even with the whitelist in place.

Case 3 - Email Is Discarded Entirely. The message scored above Kill Percent. Check the score breakdown in the headers - if it happened even after whitelisting, something outside the whitelist's reach (Section 11's impersonation-pattern rules are a common one) is likely responsible.

Case 4 - Attachment Is Missing or the Whole Message Is Gone. This is very often ClamAV, not spam filtering - check the logs for a virus signature or heuristic reference (Section 15) before assuming the whitelist didn't work.

Case 5 - Some Users Get It, Others Don't. Check whether the whitelist was added at the account level for only some of the pilot group instead of at the domain or Class of Service level. Also check for personal “Not Junk” marks or filters working in the opposite direction (Section 5, Step 7).

Case 6 - First Few Land Fine, Then Delivery Slows Down. Check the deferred queue (postqueue -p) - this is usually a capacity or pacing issue rather than a filtering one. See Section 7.

Case 7 - Email Arrives but the Link Doesn't Work. Not a Zimbra issue - check the proxy (Section 13) and endpoint/browser security (Section 14) instead.

Case 8 - Email Arrives but Images Don't Load. Check the affected user's own external-images preference (Section 17) - remember it's set per mailbox.

21. Mail Queues, Logs & Header Analysis

This section supports Section D (Delivery Logs & Evidence) of the Diagnostic Questionnaire, which the whitelisting steps in Section 5 don't cover on their own. It's also, realistically, where most Zimbra troubleshooting actually happens - the admin console tells you configuration; the logs tell you what really occurred.

Checking the Mail Queue

1. SSH to the mailbox or MTA server.
2. Run postqueue -p (or mailq) to see everything currently queued, with a reason noted for anything stuck in deferred.
3. To search for a specific message, grep the Postfix logs directly - for example, grep 'securebankupdate.com' /var/log/zimbra.log - which will show the full path a message took through Postfix, Amavis, and delivery.
4. A message that's been sitting in deferred for a while and shows repeated retry attempts against the same error is worth escalating; a message that clears within a few retries is normal queue behavior, not a problem to chase.

Reading the Message Headers

Open the message in the Zimbra Web Client, and from the message's options choose Show Original (in some versions, right-click the message) to see the full raw headers.

The header to look for is X-Spam-Status, which SpamAssassin adds to every scanned message. It shows the overall score, the pass/fail verdict against the Tag threshold, and - critically - a breakdown of every individual rule that fired and how many points each one contributed. This is the single fastest way to answer “why did this get flagged” without guessing: if a specific rule is doing the damage, you'll see its name right there and can decide whether it needs a targeted local-rule adjustment (Section 4) rather than a broader change.

A useful sanity check when you're not sure the pipeline itself is even working: send a GTUBE test string (a standard, industry-wide test pattern that's designed to always score as spam) to a test mailbox. If it gets caught the way it should, you know spam scoring is active and functioning - which at least rules out “the filter is broken” as an explanation for whatever else you're chasing.

Comparing the full headers of one message that made it through cleanly against one that didn't is, more often than any single tool, the fastest way to spot exactly where the two diverged.

22. Zimbra Editions - 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 which Zimbra edition a customer runs changes what support options and add-on tooling are actually available to them, even though it doesn't change the core filtering mechanics described throughout this guide.

• Open Source Edition (OSE) - free, self-hosted, and the edition most of this guide describes directly (Postfix, Amavis, SpamAssassin, ClamAV, zmprov). Officially community-supported only — Synacor stopped providing direct support for OSE at the end of 2023, so troubleshooting typically leans on the admin community, forums, and documentation rather than a vendor support ticket.
• Network Edition (NE) - the paid, officially supported edition, built on the same underlying filtering stack but adding vendor support, mobile ActiveSync, and backup/HSM tooling (some of it licensed through Zextras as part of the NE agreement).
• Zimbra Suite Plus - additional modules available to Network Edition and Suite Plus customers through Zimbra's partner channel, layered on top of NE rather than replacing anything covered here.

Practical implication for whitelisting: none, really - amavisWhitelistSender, SpamAssassin scoring, ClamAV, and the mail queues work the same way across OSE and NE, since they're the same underlying components. What changes between editions is who you can call when something goes sideways, and whether a handful of convenience features (mobile sync, polished backup tooling) are available. If a customer mentions Zextras Carbonio rather than Zimbra by name, that's a related but separate product built by the same ecosystem - worth a quick confirmation of which one they're actually running before assuming this guide applies as-is.

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