A client sends an invoice. A week later they ring, annoyed, because it has not been paid. The customer checks, finds it in spam, and now you look disorganised over something you did correctly.
Most people assume it is the wording. They remove the word "invoice" from the subject line, strip the attachment, rewrite the whole thing in plainer language. None of that is usually the problem.
The problem is that the receiving mail server cannot confirm the message actually came from you.
What the receiving server is checking
When mail arrives, the server on the other side asks three questions before it decides where to put the message. All three are answered by records published in your domain's DNS, not by anything inside the email.
SPF answers "is this server allowed to send mail for this domain?" You publish a list of the systems permitted to send as you. Your mail host, your invoicing tool, your newsletter platform. Anything not on that list looks suspicious.
DKIM answers "has this message been tampered with?" Your sending server signs each message with a private key. The receiver looks up the matching public key in your DNS and checks the signature.
DMARC answers "what should I do when the first two fail?" This is the one almost nobody has set correctly, and it is the one that decides your fate.
The trap in the middle
Here is where most small businesses sit. They have SPF, because their host set it up years ago. They may have DKIM. And they either have no DMARC record at all, or they have one that says p=none.
p=none means monitor and report, take no action. It looks like protection. It is not. A message forged to look exactly like yours still lands in the inbox, and your own mail gets no benefit either.
No DMARC record and a DMARC record set to p=none produce the same outcome for the person receiving your invoice. The difference is only that one of them generates reports you are probably not reading.
Why it got worse recently
This used to be an optional nicety. It is not any more.
Google, Yahoo and Microsoft now require SPF, DKIM and a published DMARC record for domains sending more than 5,000 messages a day, and they have been steadily tightening what they accept from smaller senders too. If your authentication is incomplete, you are competing for inbox placement against senders whose is not.
The second problem: you can be impersonated
There is a worse version of this. Without an enforcing DMARC policy, anyone can send email that appears to come from your domain.
Not a lookalike domain with a swapped letter. Your actual domain, in the From field, arriving in your customer's inbox looking exactly like you. That is how invoice redirection fraud works: a convincing message from a real supplier address, with new bank details.
If that happens using your domain, the reputational damage is yours to explain, even though the failure was a missing DNS record.
The other thing that quietly breaks SPF
There is a limit almost nobody knows about. SPF is only allowed to trigger ten DNS lookups while it is being evaluated. Every include: in your record counts, and every include: inside those counts too.
Add a mail host, an invoicing tool, a CRM and a newsletter platform, and it is easy to go over. Once you exceed ten, the record is treated as invalid and effectively ignored, which puts you back where you started without any warning that it happened.
This is why "we already set up SPF" is not the same as "SPF is working".
How to find out where you stand
You can check this yourself in about thirty seconds, and you should, because the answer is public information about your own domain.
There is a free checker on the front page of this site. It reads your DNS, scores what it finds out of 100, and explains each result in plain English. It shows the whole result immediately, no email address required, and gives you a link you can forward to whoever handles your IT.
If everything passes, close the tab. You have confirmation and you owe me nothing.
If it does not, you now have a specific list of what is wrong, and you can hand that to your existing provider or ask me to fix it.
What fixing it actually involves
Two things worth knowing before anyone quotes you for this.
It should not require handing over your DNS login. The records can be written out for you or your host to publish. Anyone insisting on full access is making their life easier, not yours.
It should not be switched on in one afternoon. Moving DMARC straight to enforcement without watching the reports first is how legitimate mail gets blocked. The right sequence is to publish, watch what comes back, find the senders nobody remembered, then tighten. That is a few weeks of monitoring, not a single evening of work.
Anyone promising instant enforcement is either not reading the reports or has not thought about what happens to the mail you actually want delivered.