Why Client Reminder Emails End Up in Spam
Reminder emails about a client project usually land in spam for one of three reasons: the sending domain's authentication doesn't fully check out (SPF, DKIM, or DMARC), the domain is shared with senders whose mail has a worse reputation than yours, or the message pattern itself reads like an automated blast rather than mail from a specific person about a specific project. None of those depend on what the reminder actually says — they're checked before a mail server ever reads the subject line.
Authentication: the part a spam filter checks first
Every receiving mail server runs three checks against the domain in the "From" address before it decides anything else:
- SPF (Sender Policy Framework) — a DNS record listing which mail servers are allowed to send as that domain.
- DKIM (DomainKeys Identified Mail) — a cryptographic signature on the message, verified against a public key published in DNS, proving the message wasn't altered in transit and really came from a server that holds the matching private key.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) — a policy record telling the receiver what to do when SPF or DKIM fails, and whether the domain in SPF/DKIM has to match the visible "From" domain ("alignment").
As of October 2026, Gmail and Yahoo's current bulk-sender guidance (in force since February 2024) requires full SPF+DKIM+DMARC with alignment, a sub-0.3% spam-complaint rate, and one-click unsubscribe — but only for senders pushing past roughly 5,000 messages a day to their users. A reminder about one client's project is nowhere near that volume, and the unsubscribe requirement specifically exempts genuinely transactional mail. What doesn't go away below that threshold is the underlying signal: Gmail and Yahoo (and every other major provider) still use SPF/DKIM/DMARC pass-or-fail as one input into whether a message is trustworthy, bulk sender or not. A domain missing DKIM, or one where SPF passes but doesn't align with the visible sender, looks more like something worth a second check — and spam folders are where second checks happen by default.
The practical upshot: a domain with SPF and DKIM both configured and aligned starts every message with one fewer reason to be filtered. A domain missing either doesn't guarantee spam, but it removes a signal the filter would otherwise have given it credit for.
Whose reputation is actually on your reminder
Authentication proves who sent the mail. Reputation is a separate question — has this sending identity behaved well before — and it's tracked per domain (and per sending server), not per message.
A shared sending domain means every account using that domain inherits the same reputation history. If BriefGate's shared domain carries a good reputation, your reminder benefits from it without you doing anything. The address itself stays intake@briefgate.dev regardless of plan — what changes with a verified custom sending domain (Studio and Agency; see Custom Domains) is that the display name drops the "via BriefGate" qualifier and mail goes out as you@yourcompany.com instead, carrying your own domain's reputation rather than the shared one. Until a custom domain is verified, nothing breaks and nothing is held back — mail keeps going out from the shared domain exactly as before.
A dedicated domain cuts the other way: your reputation is entirely your own, for better or worse. A brand-new domain, or one that's never sent transactional mail before, doesn't start with a bad reputation — it starts with no reputation, which filters treat cautiously until they've seen enough consistent, low-complaint sending to build trust. That's the trade custom domains make: full control over the identity the client sees, at the cost of a reputation you now have to earn rather than borrow. For most projects, the shared default is the right call precisely because it comes pre-earned; a custom domain is worth the ramp-up mainly when you're sending enough client reminders, from enough projects, that your own domain's reputation adds up faster than relying on a shared one, or when the client-facing identity matters enough on its own (an agency putting its own name in front of every client, not BriefGate's).
Patterns that make a message look automated
Authentication and reputation decide whether a server is willing to trust the domain at all. A third layer looks at the message itself, and at the sending pattern around it:
- Frequency. The same recipient getting several nearly-identical messages close together reads like an automated loop, even when each one is legitimate. A fixed short interval — emailing every two or three days regardless of how long the request has been outstanding — is the clearest version of this pattern, because it's exactly how a crude mail-merge script behaves. BriefGate's chase schedules are built to avoid that shape by spacing reminders out as a request goes unanswered longer, rather than hammering at a constant interval; see Reminders that arrive at a sensible hour for how the cadence itself is designed, and the reminder cap that stops it from escalating into exactly the pattern a spam filter is watching for.
- Time of day. A message sent at 3am local time to the recipient is a pattern no human sender produces, and filters know it. BriefGate holds reminders to 8:00–19:00 in the client's own time zone by default — also covered in that same article — rather than firing on whatever schedule the server happens to run.
- Generic templates with no context. A message with no reference to the specific project, sent from a name the client doesn't recognize, is harder for a filter to distinguish from a phishing attempt that also claims urgency and asks for action. Reminders that name the actual project and the actual sender don't just read better to the client — they give the filter less reason to flag the pattern as mass mail.
What you can actually check
- Run a one-off deliverability test. A tool like mail-tester.com sends you a throwaway address; mail to it and the result shows SPF, DKIM, and DMARC pass/fail individually, so a misconfigured record shows up by name rather than as a vague "went to spam."
- Check Google Postmaster Tools (free, for any domain sending to Gmail addresses) for your domain's reputation and spam-rate trend if you're on a custom sending domain — there's nothing to check on the shared domain, since that reputation isn't yours to monitor.
- Ask the client to do the one thing that actually works immediately. Replying to any BriefGate email, or adding the sender address to their contacts, is a stronger positive signal to most providers than any authentication fix, because it comes from the recipient's own behavior rather than from the message. It's worth a one-line ask the first time you send: "add this address to your contacts so our reminders don't get buried."
- If you're on Studio or Agency and considering a custom sending domain, add it and verify the SPF, DKIM, and MX records in Custom Domains before relying on it for a time-sensitive project — a domain mid-verification still sends from the shared address, so there's no gap in delivery, but you want the reputation question settled before a deadline, not during one.
Related
- Reminders that arrive at a sensible hour — how BriefGate's chase schedules and quiet hours are designed
- Custom Domains — setting up your own sending and portal domain, step by step
- Client Portal — what the client actually sees once a reminder lands
- Security — how BriefGate handles the data behind those reminders