If your invoices are landing in a client's spam folder, you are losing money to something you cannot see. The client does not know the message arrived, you do not know it was filtered, and the first sign is a polite chase three weeks later. Most of the causes are ordinary, and most of them are yours to fix.
This post is for the person sending from their own domain: the freelancer with a contact address and an invoicing tool, the two-person studio, the consultant who replies to twenty threads a day. It goes through the causes in roughly the order they turn out to be true, so you can stop at the first one that fits. For the setup itself it leans on our SPF, DKIM and DMARC reference rather than repeating it.
One warning before starting. Spam filtering is scored, not ruled, and every provider scores differently. The advice here moves you from likely filtered to likely delivered. Nothing moves you to certain.
Authentication comes first
The commonest fixable cause is that the receiving server cannot tell your mail is really from you. Three DNS records do that job: SPF lists which servers may send for your domain, DKIM signs each message with a key published in your DNS, and DMARC tells receivers what to do when neither check passes, and where to send reports. If any of them is missing, wrong, or written for a server you no longer use, you have found the most likely problem.
This stopped being optional in 2024. Google's sender guidelines, in force since February 2024, require every sender to set up SPF or DKIM, publish valid forward and reverse DNS for sending addresses, and send over TLS. Senders of more than 5,000 messages a day to Gmail accounts must have SPF and DKIM, a DMARC record, and a From domain aligned with either the SPF or DKIM domain. Yahoo's requirements are the same shape: SPF or DKIM for everyone, both plus a DMARC policy of at least p=none for bulk senders, with the From domain aligned. Microsoft followed in May 2025 for domains sending over 5,000 messages a day to Outlook.com, sending non-compliant mail to junk and warning that rejection follows.
The word to notice is aligned. A DKIM signature from your invoicing tool's domain, or an SPF pass for a reseller's domain, is still a pass, but it does not count for DMARC unless the domain matches the one in your From header. The current DMARC specification, RFC 9989, published in May 2026, defines relaxed alignment as sharing the same organisational domain and strict alignment as identical. It also removed the pct tag, so a guide that tells you to roll out gradually with pct= is describing a version of the standard that no longer exists. Most small senders are fine with relaxed alignment and a policy of p=none to begin with.
Being below the bulk thresholds does not exempt you in practice. Filters use the same signals for everyone; the thresholds only mark where providers promise enforcement. A DMARC record with p=none and a rua address costs nothing and starts collecting the reports you will need later.
A domain nobody has heard of
The second cause is reputation, which providers keep for both the domain and the sending IP address, built from what recipients did with earlier mail. A domain registered on Monday has none. A domain that then sends fifty invoices on Tuesday looks, to a filter, much like a domain someone registered to send fifty phishing messages. Google's guidance for new senders is to start with low volume to engaged recipients and increase slowly, and to avoid sudden spikes without a history of sending at that level.
For a freelancer this translates into something dull: send the first messages from the new domain to people who will reply, and let the invoices follow over weeks rather than in one afternoon. If you still have a choice of domain, the extension and the domain's previous owners both matter, which we covered in choosing a domain for email. A domain a spammer burned two years ago carries that history to you.
Google's Postmaster Tools offers dashboards for domain and IP reputation, rated from Bad to High, alongside spam rate and a compliance status view that checks your setup against its sender requirements. It covers only mail to Gmail accounts, and only once you send enough to register, but it is free and nothing else comes close.
What is in the message
Content matters less than folklore says and more than nothing. The verifiable guidance from providers is narrow. Google asks that links in the body be visible and easy to understand, that you do not use HTML and CSS to hide content, and that subject, headers and display names accurately represent the sender. A URL shortener is not banned by any rule you can read, but it hides where a link goes, which is exactly what the guidance asks you not to do, and a shortener's domain carries the reputation of everyone else using it.
The image-only message is the same kind of problem. A single large image with no text gives a filter nothing to read and resembles a technique for evading text analysis, because it is one. Attachments are a third case: Gmail blocks a published list of executable and script file types outright, including inside archives and inside password-protected archives. A PDF invoice is fine. A zipped file sent "for security" is not.
A mismatched Reply-To deserves a mention because invoicing tools set it by default. RFC 5322 defines Reply-To as the address where the author suggests replies go, and there are honest uses for it. But a From on your domain with a Reply-To at a free webmail provider is a pattern phishing uses constantly, and Google's guidelines say headers should represent the sender identity accurately. Send from the address you want replies to.
The list, even a small one
You may not think of thirty clients as a list, but the filters do. Two things on it damage you. The first is addresses that bounce. Google says to automatically unsubscribe recipients with multiple bounced messages; Yahoo says to remove invalid recipients promptly and to watch hard and soft bounces and inactive recipients. A sender who keeps hitting dead addresses looks like a sender who does not know who they are mailing.
The second is sending to people who did not ask. Google and Yahoo both say, in plain words, not to purchase email lists. A bought list contains dead addresses, spam traps and people who will press report, and a small domain's reputation is small enough that one such send can flatten it. If you are tempted by a list of local businesses, the fastest way to guarantee your genuine invoices go to spam next month is to mail it this month. Our post on email aliases for freelancers covers keeping the addresses you give out separate from the addresses you send from, which limits the damage when one of them goes wrong.
Complaints, and the unsubscribe you owe
A recipient pressing the spam button is the strongest negative signal a provider has, because it is a person saying so. Google's guidelines tell senders to keep the spam rate shown in Postmaster Tools below 0.10 percent and never to reach 0.30 percent; Yahoo asks for below 0.3 percent, measured on mail that reached the inbox. Three complaints in a thousand messages is a problem.
If you send anything resembling bulk mail, a newsletter or a monthly note to clients, then Google requires that marketing and subscribed messages support one-click unsubscribe using the headers from RFC 2369 and RFC 8058, with a clearly visible unsubscribe link in the body. Yahoo requires a functioning list-unsubscribe header and says unsubscribes must be honoured within two days. RFC 8058 spells out what one-click means: a List-Unsubscribe header carrying an HTTPS URL, a List-Unsubscribe-Post header with the single value List-Unsubscribe=One-Click, a process that completes from a POST without further interaction, and a DKIM signature that covers both headers. In the United States, CAN-SPAM adds a legal layer to any commercial message: accurate headers, an honest subject, a physical postal address, and opt-outs honoured within ten business days. We are not lawyers, and that is a summary rather than advice.
Invoices and replies are not bulk mail and need none of this. The trap is mixing. Google's guidance is not to combine categories in one message, so a promotion inside a receipt makes the receipt a promotion.
Diagnose rather than guess
Before changing anything, find out what the receiver actually decided. In Gmail, open the message, choose More, then Show original, and the full header appears. Read it from the bottom up: RFC 5321 requires each server that accepts a message to add a Received line at the top and forbids reordering them, so the lowest is the first hop and the highest is the last. Return-Path holds the envelope sender, which is the address SPF actually checks, and it is often not the address in From.
Then look for Authentication-Results, defined in RFC 8601, which the receiving server adds to say what it checked and what it found, in method=result form: spf=pass, fail, softfail or none; dkim=pass, fail or none; and, from the DMARC specification, dmarc=pass, fail or none, plus temporary and permanent error values you will rarely see. An SPF softfail with a passing DKIM is a different diagnosis from a DKIM fail with a passing SPF, and both differ from a DMARC fail caused by alignment.
Run a seed test: send the same message from the same tool to your own accounts at Gmail, Outlook and Yahoo, and read the headers on each copy. If it reaches the inbox everywhere except one provider, the problem is that provider's view of you; if it fails everywhere, it is your setup. Finally, read the DMARC aggregate reports arriving at the rua address you published. They show every source that sent as your domain and how it authenticated, which surfaces the forgotten tool signing with the wrong domain without you sending a single test.
| Symptom | Likely cause | First thing to check |
|---|---|---|
| Spam at Gmail only, fine elsewhere | Gmail's view of your domain | Postmaster Tools spam rate and compliance status |
| New domain, everything filtered in week one | No sending history | How much you sent, how fast; slow down |
| Fine from webmail, spam from your invoicing tool | Tool not in SPF or not signing with your domain | Return-Path domain and the DKIM d= tag |
| Only messages with an attachment | Attachment type or archive | Send the same message without it |
| Only messages with a link | Shortener or link destination | Replace with the full URL |
| Client sees a question mark by your name | DKIM missing or unaligned | Gmail's mailed-by and signed-by fields |
| Suddenly worse after one send | Complaints or a bad list | Spam rate, bounce count, where the list came from |
| Only forwarded copies fail | Second hop failing SPF | Received chain for a hop that is not yours |
When the problem is forwarding, not you
One failure looks like yours and is not. If a client's company forwards mail from an old address to a new one, or you have an alias that forwards to your real inbox, the message passes through a second server before it arrives. SPF checks whether the server handing the message over is authorised by the domain in the envelope sender. A forwarder is not in your SPF record, so at the second hop SPF fails. Google's own forwarding guidance says plainly that forwarded messages often fail SPF.
The fix is not on your side. The forwarder should rewrite the envelope sender to its own domain, which is what Microsoft's Sender Rewriting Scheme does and what Google's forwarding guidance asks for, and should leave the body and signed headers alone so your DKIM signature survives. A DKIM signature that arrives intact still aligns with your From domain, so DMARC passes on DKIM even though SPF failed; Microsoft's own documentation says the same. ARC, defined in RFC 8617, lets an honest forwarder seal the results it saw so the final receiver can take them into account.
So if the headers show spf=fail on a Received chain with an extra hop that is not one of your servers, and dkim=pass, you are looking at forwarding. Ask about the forwarding rather than rewriting SPF for a server that was never yours. If DKIM also fails on the forwarded copy but passes on a direct copy, the forwarder is altering the message, which is again their problem to fix.
The honest limit
No record, tool or checklist guarantees inbox placement. Filters are probabilistic models trained on each provider's own users, weighted differently at Gmail, Outlook and Yahoo, and adjusted without notice. A message that passes every check can still be filtered because it resembles something the recipient's neighbours reported yesterday. What the steps above do is remove the reasons a filter can point to. Anyone who promises delivery is selling the part they control and hoping you do not notice the part they cannot.
What you can do is make your mail boring in the ways that count: authenticated, aligned, sent steadily from a domain with a history, to people who expect it, with an exit for anyone who does not.