You sent the deck two weeks ago. The client, asked why they haven't approved it, says with total sincerity that they never got it. Now you're in an unusually specific kind of bind: you likely believe you sent it, they likely believe they didn't get it, and neither of you is necessarily lying.
Why this happens more than freelancers assume
Spam and promotions folders eat a real percentage of legitimate email, especially from senders a client's mail system hasn't seen much traffic from before. This isn't a client being careless — it's a filtering algorithm making an imperfect call.
Attachments and external links get stripped or flagged by some corporate mail systems, particularly in security-conscious industries (finance, healthcare, legal), sometimes without any visible notice to the recipient that anything was blocked.
People genuinely do lose track of emails in high-volume inboxes — not maliciously, just as an ordinary consequence of managing hundreds of messages a week across dozens of active threads.
Occasionally, “I never got it” is a face-saving way to say “I saw it and haven't dealt with it.” This is the least common cause, but worth naming honestly — sometimes the real issue is priority, not delivery.
The technical reason this happens inconsistently — even to careful senders
It's worth understanding, at least at a plain-language level, why this problem can strike an otherwise well-run freelance business seemingly at random — because the mechanics explain something that pure bad luck doesn't: why the same kind of email can reach one client perfectly and vanish for another.
“Delivered” and “seen” are not the same thing. A mail server can accept your message — meaning it technically “delivered” successfully by any formal definition — and still route it straight into a spam or junk folder the client never opens. From the client's honest perspective, an email that's sitting unread in a spam folder they never check might as well not exist. This is why “I definitely sent it” doesn't settle anything on its own; sent, delivered, and seen are three separate states, and only the last one actually matters to the person on the other end.
SPF and DKIM are two authentication checks that verify a message is legitimately coming from your domain. DMARC is a separate, third setting that tells a receiving mail server what to actually do if a message fails those checks — quarantine it (send to spam), reject it outright, or do nothing and just monitor. Here's the part that explains a lot of freelancers' confusion: without a DMARC policy configured, every receiving mail provider decides independently how to handle a borderline message. That means the exact same email, sent to two different clients on two different email providers, can be accepted cleanly by one and flagged by the other — not because anything about the message changed, but because the receiving systems made different calls with no shared instruction to follow.
Even correctly configured authentication doesn't guarantee an inbox. This is the part worth being honest about, because it's tempting to assume “I set up SPF and DKIM, so I'm covered” — and that's necessary, but not sufficient. Authentication proves a message is legitimately allowed to come from your domain. It says nothing about whether the receiving provider already trusts your sending reputation, whether the recipient has a history of opening your emails (low engagement rates on past messages can itself lower deliverability for future ones), or whether their company's internal mail filter has a local rule catching your message for reasons that have nothing to do with your setup at all. One deliverability case study found a domain with fully correct SPF, DKIM, and DMARC still landing in spam — the actual cause turned out to be a missing PTR record, a commonly overlooked reverse-DNS setting most people setting up “the big three” authentication records don't even know exists.
None of this is something a freelancer needs to become an expert in. It's worth knowing only so far as it explains something important: doing everything right on your end doesn't fully control whether an email lands — which is a real, structural limitation of email as a delivery mechanism, not a sign you're doing something wrong.
A worked example
A copywriter sends a final draft to a new client on a Tuesday. By Friday, no response. A follow-up gets: “I never got anything from you — can you resend?”
The copywriter's instinct is to check their own sent folder, confirm the email is there, and feel a flash of frustration — clear proof they did their part. But that sent-folder confirmation proves exactly one thing: the message left their outbox. It says nothing about what happened next. In this specific case, the client's company (a mid-sized firm with strict IT policies) runs a corporate filter that quarantines any external email containing a link to an unfamiliar file-sharing domain — precisely the kind of local filtering rule that operates independently of the sender's own SPF, DKIM, and DMARC setup, and that the sender has no way to see or diagnose from the outside.
Nothing about this was the copywriter's fault. Nothing about it was really the client's fault either — they genuinely never saw anything arrive, because nothing did, as far as their inbox was concerned. The resend, sent as a plain link instead of a file-sharing attachment, goes through cleanly. The lesson isn't “always double check your sent folder” — it's that the sent folder was never going to answer the actual question either side needed answered.
What a deliverability-friendlier sending habit looks like
None of this requires becoming an email infrastructure expert, but a few habits meaningfully reduce how often this problem comes up in the first place:
Send from a business domain, not a free consumer address, once you can. A properly configured business domain with SPF, DKIM, and DMARC set up starts building its own sending reputation over time — something a shared, high-volume address like a free Gmail account can't accumulate the same way, since its reputation is shared across millions of unrelated senders.
Avoid large attachments and unfamiliar file-sharing links in a first message to a new client. These are exactly the pattern many corporate filters are tuned to flag, particularly the first time a domain is seen sending them. A plain-text link a client has to click through, rather than an embedded attachment, tends to fare better.
Don't assume silence means disinterest before checking for a delivery issue. It's tempting to read a week of silence as the client deprioritizing the work. Sometimes that's true. Often, especially with a new client relationship where no sending reputation has built up yet, it's simply that nothing arrived.
What to do in the moment
Resist the urge to prove you sent it by forwarding the original email with a pointed “as sent on [date].” It's technically accurate and socially unhelpful — it reads as a gotcha even when that's not the intent, and it doesn't solve the actual problem, which is that the client still needs to review the work.
Instead: “No worries — resending now, and I'll follow up here once you've had a chance to take a look.” Then genuinely resend, ideally through a second channel (a portal link, a text, whatever exists outside email) so a repeat of the same delivery failure doesn't happen twice.
The structural fix
Given everything above, the reason this keeps happening isn't usually about being more careful with any single email — it's that email as a delivery mechanism has failure modes entirely outside your control, some of which (like a client's own local filtering rules, or a receiving provider's independent handling decisions) you'll never be able to see or fix from your end. A single persistent link the client already has bookmarked or saved removes the “did it arrive” question altogether, because there's nothing to deliver in the first place — the client returns to a place that already exists rather than waiting for something to land in an inbox, pass a spam filter, and get opened.
This is part of why SwiftSignoff portals work off a single magic link rather than repeated email attachments. Once a client has the link — bookmarked, saved in a text thread, wherever — every new milestone appears there automatically, with no new email that can get filtered, blocked, or lost to any of the deliverability mechanics above. And because the portal logs every time the link is opened, “I never saw an update” becomes something you can actually check rather than take on faith either way.
Related guideZero-login client portals: how a magic link makes every update instantly accessible
What to do if it keeps happening with the same client
A single instance is normal internet friction. A repeated pattern with one specific client is worth a direct, non-accusatory conversation: “I've noticed a couple of my emails haven't been landing — is there a chance they're going to spam, or is there a better way to reach you for project updates?” This reframes it as a solvable logistics problem rather than a character judgment about either party.
FAQ
Should I ask a client to check their spam folder?
Yes, and phrase it as a genuine possibility rather than a suggestion that they made a mistake: “Totally possible it landed in spam or promotions — worth a quick check?”
Is it worth using email read receipts to settle this kind of dispute?
Generally not — read receipts are unreliable (many mail clients don't support them, and recipients can decline them), and asking for one can come across as distrustful before there's even been a dispute.
Does sending from a personal domain instead of Gmail help with deliverability?
It can — properly configured business email (with SPF, DKIM, and DMARC records set up correctly) tends to land in spam folders less often than free consumer email addresses, though it's not a guarantee, since sender reputation and the recipient's own local filtering rules matter too.
What if the client insists they checked everywhere and it's genuinely not there?
Believe them and move forward rather than relitigating — resend immediately through whatever channel is available, and treat solving the problem as more valuable than establishing who was right.
If my email authentication (SPF/DKIM/DMARC) is set up correctly, does that guarantee inbox delivery?
No — authentication proves the message is legitimately allowed to use your domain, but it doesn't guarantee a mailbox provider trusts the sender, that the recipient wants the mail, or that a corporate filter won't still catch it for unrelated reasons. It's a necessary foundation, not a complete guarantee.
Stop relying on email to prove a client saw your work.
PricingSee how portal links remove the guesswork on the pricing page