Why do bid invitation emails go to spam?

"We never got it" is the most common thing a sub says on bid day, and it's true more often than estimators want to believe. Here's what goes wrong between Send and the sub's inbox, with the fixes ordered from the ones you can do this afternoon to the ones that need someone in IT.

What receiving servers check

Before any human sees your email, the receiving server asks roughly three questions about it.

Is the sender who they claim to be? That's authentication: SPF, DKIM, DMARC. Does this sender have a decent reputation? Has the domain sent spam before, does its mail get ignored or deleted? And does this particular message look like spam? Content, links, attachments, how many people got the same thing at once.

Fail badly on one of those and the message goes to Junk or is dropped outright. Fail mildly on a couple and it lands in Other or Promotions, where nobody looks, which for your purposes is the same thing.

Six fixes on the estimating side, for today

Stop sending to Bcc lists. Forty recipients looks like a marketing blast because it is one. Individual emails look like correspondence, to the filter and to the recipient. Mail merge gets you there without the typing.

Stop attaching big files. A 40 MB attachment bounces on many servers, and "many attachments to many people" is a spam signal on its own. Link to the documents.

Send from a person, to a person. "estimating@" to "estimating@" is two robots talking. A named sender to a named recipient is correspondence.

Watch the formatting. No capitals in the subject line, no strings of exclamation marks, no image-only signature, one link rather than eight.

Fix bounces immediately. Every address you keep sending to that bounces counts against your domain. A list with 10 percent dead addresses slowly poisons delivery to the other 90 percent, which is a bad trade.

Don't blast from a new address. A "bids@" mailbox created yesterday that sends 300 invitations today looks like a spammer with a fresh domain, because that's what spammers with fresh domains look like. Warm it up over a couple of weeks, or send from an established personal address.

The platform question

Invitations sent through a bidding platform come from the platform's domain. Their deliverability is their problem, and the large vendors handle it competently. But corporate mail systems learn, over time, that mail from that domain is automated notifications, and they sort it into Other or Promotions accordingly. Not spam. Just not the inbox. That's why "I never got it" comes up more often with platform invitations than with personal ones.

The alternatives are sending from your own domain, either with an Outlook merge or with a tool that connects to your Microsoft 365 or Google Workspace mailbox and sends as you (which is how Invite All works), or phoning the important trades after each send to confirm arrival. Either way, "sent" and "in the inbox" are different things and it's worth knowing which one you've achieved.

Three fixes on the IT side, for this month

Send this section to whoever manages your domain and email.

SPF is a DNS record listing which servers are allowed to send mail for your domain. If it's missing, or doesn't include a service you send from (a bidding platform, accounting software, a merge add-in), that mail looks forged. Check it with any SPF checker; it should exist and it should pass.

DKIM is a cryptographic signature on each message proving it came from your domain unaltered. Microsoft 365 and Google Workspace both support it, but it isn't always on by default. Check by sending yourself a test at a Gmail account, opening "Show original," and looking for "DKIM: PASS."

DMARC is a policy record telling receivers what to do when SPF or DKIM fails, and where to send reports. Even a monitoring-only policy improves how your mail is treated. Google and Yahoo began requiring these records from bulk senders in 2024, and Microsoft followed in 2025. A domain without them is on borrowed time.

One trap worth naming: the shared mailbox. Sending from "estimating@" with "send as" permissions is fine when it's configured inside your own tenant. It goes wrong when a third-party tool or an old on-premises server sends as that address without SPF and DKIM covering it, at which point your invitations are technically forgeries. Any tool that sends on your behalf should do it through your actual mailbox, with OAuth into Microsoft 365 or Google, not by spoofing the From address.

The fifteen-minute test

Before the next bid round, send a real invitation with your normal template to three addresses: a Gmail account, an Outlook.com account, and a colleague at another company on Microsoft 365. Note where each one landed: Inbox, Other, Promotions, Junk. In Gmail, open "Show original" and look for SPF, DKIM and DMARC. You want three passes. Anything off, work through the lists above.

If the message lands in Other on your colleague's corporate Outlook, assume it does for about a third of your subs, and phone the important ones after each send until it's fixed.

In short

Individual emails, from a person, to a person, with a link instead of attachments. Fix bounces the day they happen. Get IT to set up SPF, DKIM and DMARC. And if you send through a platform, remember that delivered and seen are not the same thing.