Incident
A title company’s funding department opened a ticket: “In Front we are having an issue with it marking all of the wire confirmations that come from [a regional bank] as Spam. It does not matter if it is an incoming or outgoing wire or the amount. On each wire we are setting them to ‘Unblock Sender’ and ‘Not Spam’ but it will not help the issue.” Every confirmation landed back in Spam.
Wire confirmations landing in Spam is not a small annoyance for a funding department. These are the emails that tell them a several-hundred-thousand-dollar wire actually went through. If one gets missed, a closing gets delayed. If one gets missed the wrong way, it becomes a fraud-risk conversation.
The funding manager flagged a useful breadcrumb: “I know there was an adjustment made when we had an issue with the wires with [a different bank] so not sure if that is somehow related.” Same pattern, different bank.
Diagnostics
Front is a shared-inbox client on top of a real mailbox (here, Gmail). Spam decisions for that stack happen at the gateway and at Gmail — Front mostly displays the result. So the path was layer-by-layer, not “poke Front until it sticks.”
First check: third-party mail hygiene in front of the mailbox. Clean. Messages were passing spam filtering at the MX layer. Not a gateway problem.
The funding team had already been hitting “Unblock Sender” and “Not Spam” in Front on every confirmation; those only reclassify that one message. We confirmed Front contacts, account records, and Front-side allowlisting for the bank’s sender as well — those own Front metadata and routing, not Gmail’s spam score. A test confirmation looked fine for about 48 hours, then the next one dropped back into Spam the same way.
That pattern is the tell: Front was reflecting a classification made underneath it. The durable rule had to live on the mailbox Gmail was scoring against.
How Front actually works with gmail
Here’s the piece that catches people. Front is not a mail server. It’s a shared-inbox client that syncs against an underlying mailbox: Gmail, Microsoft 365, whatever. Mail hits Gmail first, Gmail applies its filters and folders, and Front displays whatever Gmail did. Front’s “Spam” folder in the UI is literally Gmail’s Spam label.
So when you click “Not Spam” in Front, Front tells Gmail to remove the Spam label from that one message. Good. But Front has no mechanism to tell Gmail “never send mail from this sender to Spam in the first place.” That rule lives in Gmail itself, in user filters or Google Workspace policies. Front’s “Unblock Sender” is a Front-level concept that doesn’t translate down to the Gmail filter layer. Single-message “Not Spam” (in Front or Gmail) only clears that copy; Gmail still scores the next arrival on its own and can put it right back in Spam.
We opened a support ticket with Front to confirm there wasn’t a platform-side allowlist outside that model. Front confirmed the diagnosis: Gmail classification, not something their product overrides.
Resolution
We added a Gmail filter on the specific mailbox Front was syncing to. The filter matched the bank’s sender address and applied the “Never send to Spam” action:
- Log into the Gmail account that Front is syncing (the actual underlying mailbox, not Front)
- Settings → Filters and Blocked Addresses → Create a new filter
- From: the exact sender address from the wire confirmations
- Next → Check “Never send it to Spam”
- Save
That’s it. One filter, one mailbox, five minutes of work. The rule runs at Gmail’s classification layer, which means by the time Front syncs the message, Gmail has already decided it’s not spam, and Front displays it in the normal inbox.
Why in-front whitelisting doesn't stick
Worth spelling out because this is the exact trap. Front syncs against an external mailbox. It doesn’t own the filtering rules. Clicking “Not Spam” reclassifies one message, not the sender. Clicking “Unblock Sender” is a Front-level policy invisible to Gmail. Front contacts and “accounts” affect Front’s own metadata, not Gmail classification. Gmail keeps scoring each new inbound independently and keeps flagging the sender. The fix has to happen where the classification happens: for Gmail-backed Front, a Gmail filter; for M365-backed Front, a mail flow rule or tenant allow-list. Knowing which layer owns the decision is most of what Google Workspace and Microsoft 365 administration actually is.
Outcome
After the Gmail filter went in, the funding manager sent two more wires that week. Both confirmations landed in the normal Front inbox. A few days later: “We have been getting the confirmations in Front again for that bank again and not in the Spam folder. I think the issue has been resolved.”
While we were in that mailbox, we also ran real unsubscribe links on legitimate marketing that had piled up in Spam — not the scammy ones.
time to fix: 5 minutes mailboxes touched: 1 wires recovered from Spam during troubleshooting: several bonus marketing unsubscribes while cleaning up: a bunch