Your quote went to their junk folder, and it is your domain's fault

"It went to my junk, sorry." You have heard that from a customer this year, probably about a quote, possibly about the follow-up chasing the quote. It reads like bad luck. It is usually a verdict, and the thing being judged is not the email. It is your domain.

Since 2024 the big mailbox providers have stopped giving unverified email the benefit of the doubt. Google and Yahoo moved first, in February 2024, requiring senders to prove their domain authorises what is sent in its name. Microsoft followed for its consumer services in 2025: from 5 May, mail from non-compliant high-volume senders went to junk, and it now bounces outright with an error, 550 5.7.515, that most small businesses have never heard of until it appears between them and a customer.

The strict rules formally apply to senders of around 5,000 messages a day. You do not send 5,000 messages a day, and it does not matter. The same checks those rules are built on now feed the spam scoring applied to everyone, and a domain that fails them starts every delivery a goal down.

What the receiving server actually asks

When your quote arrives at a mailbox, the receiving server asks the sending domain three questions, and it asks your DNS records, not your email.

Who is allowed to send as you? That is SPF: a list, published in your DNS, of the servers entitled to send mail for your domain. No list, and anyone is entitled, which is the answer a spam filter hears loudest.

Is this message signed? That is DKIM: a signature added to each message that proves it was not altered on the way and really came from the domain it claims. Microsoft 365 can sign your mail properly with about ten minutes of setup. On most small business domains that setup never happened.

And what should I do if the checks fail? That is DMARC: your domain's published policy, ranging from "just tell me" to "reject it". No policy at all is itself an answer, and it is the wrong one.

3: DNS records that decide where your email lands
5,000: Messages a day where the formal rules start. The scoring starts at one

Most small business domains were configured once, on the day the website went live, by whoever built the website. If that was more than a few years ago, there is a fair chance your domain answers one of the three questions and shrugs at the other two.

The junk folder is the smaller problem

Here is the part that moves this from an IT nicety to something worth an hour of your time: a domain with no DMARC policy is a domain anyone can send email as.

Not "an address that looks similar". Your actual domain, in the from line, indistinguishable to the person receiving it. This is how fake invoice fraud works: a criminal emails your customer as you, with your email signature harvested from a genuine message, and new bank details. The receiving server would happily flag it, but your domain has published nothing telling it to check.

Deliverability and spoofing are the same problem. A domain that cannot vouch for its real email cannot disown the fake either.

The first step of the fix costs nothing and commits you to nothing. A DMARC policy of p=none changes nothing about how your mail is handled; it simply asks the world's mailbox providers to send you reports on who is sending as your domain. In our experience the first report is the moment this stops being an abstract risk. Sometimes it lists a forgotten but legitimate sender, the newsletter tool or the accounts package nobody remembered. Sometimes it lists servers in countries you have never traded with.

The senders you forgot count too

The list of things sending email as your domain is longer than your staff. The accounting package sends invoices as you. The website's contact form sends notifications as you. The CRM, the booking tool, the newsletter platform, all as you.

Each one either appears in your SPF record and signs with DKIM, or it fails the checks in your name. This is where the problem bites businesses that have done nothing wrong: a perfectly good system, sending perfectly good email, silently failing authentication for two years because nobody added one line to a DNS record when it was set up. We build systems that send email programmatically, so we treat authentication as part of the build. If it is wrong, the software's output does not arrive, and nobody rings to tell you.

What putting it right looks like

01List everything that sends as your domain: people, website, accounts package, CRM, newsletter tool
02Publish an SPF record covering all of them, and only them
03Turn on DKIM signing in Microsoft 365 or Google Workspace, and in each external service
04Add a DMARC record at p=none and let the reports arrive for a few weeks
05Read them, fix the legitimate senders that are failing, then tighten the policy so fakes are refused

The order matters. Jumping straight to a strict DMARC policy without the reporting stage is how businesses block their own invoices; the fortnight of p=none is what makes tightening safe. For a typical business on Microsoft 365 with a handful of external services, the whole exercise is measured in hours, most of them spent on step one.

It is also, honestly, a job you can give to whoever runs your IT, and if they set your domain up in the last couple of years they may already have done it. The useful question to ask them is specific: "do we pass SPF, DKIM and DMARC, and what is our DMARC policy?" A confident answer names the policy. A pause means the junk folder is still deciding.

If nobody runs your email, or the answer was a pause, we do this as a matter of course when we take on a Microsoft 365 estate, and checking a domain takes minutes.

We work with businesses across Knutsford, Alderley Edge, Wilmslow, Altrincham, Stockport and Warrington, and remotely for clients anywhere in the UK.