It usually surfaces on a phone call. A customer rings to chase the quote you sent on Tuesday. You did send it on Tuesday; it’s in your sent items, timestamped, PDF attached. They check their junk folder while you’re on the phone, and there it is, sitting between a fake parcel notification and something about crypto. You both laugh. Then you put the phone down and wonder how many people never bothered to look.
The short answer: your domain probably isn’t vouching for your email. When your message arrives, the receiving mail server asks your domain a question. Is this sender allowed to use your name? The answer is meant to come from your domain’s DNS records, the public settings that live alongside the ones pointing your website at the right place. If nothing’s published, the server gets silence, and silence isn’t a pass.
We run this lookup during most first conversations with a prospect, and often enough there’s nothing there. No record of who may send as them, and years of quotes quietly landing in junk, absorbed as one of those things.
Why does silence count against us?
A spam filter has a fraction of a second to judge a message from a stranger. Anyone can type any name into the From field of an email. That’s always been true, and it’s still true today. So the receiving server needs a way to tell a real message from your business apart from a message that merely claims to be from your business.
Published records are that evidence. Without them the filter is working blind, and blind means cautious. Your message gets scored on whatever’s left: attachments, links, phrasing, the reputation of the service you sent from. Quite often it loses.
Silence isn’t neutral. An unanswered question counts against you. That’s the rule at the bottom of this whole subject, and it explains the maddening inconsistency too: different providers weigh the leftover signals differently, so the same email sails into one inbox and gets buried in another. Nobody complains, because people who don’t receive an email have no idea they were meant to.
What are SPF, DKIM and DMARC in plain English?
Three records, and they build on each other, which is why this order makes sense.
SPF is the list of which servers may send email using your domain name. One short line of text in your DNS. If your business sends from a cloud mailbox, plus an accounting package that emails invoices, plus a website contact form, plus a marketing platform, all four need to be on the list. This is the usual point of failure: the record was set up years ago for the mailboxes, then three other systems were added, and nobody went back to update the list.
DKIM is a signature added to each message proving it left your systems unaltered. The sending service stamps every outgoing message, and publishes the matching key in your DNS so receiving servers can check it. A matching stamp establishes two things: the message really came from where it claims, and nothing was tampered with on the way.
DMARC tells receiving servers what to do when the first two don’t line up, and can send you reports on who is sending as you. Without it, a server that finds a failed check has to guess your intentions. With it, you’ve said in advance: treat a failing message this way. The reports are the underrated half. They show you every system in the world sending email with your name on it, including the ones you forgot, and any you never authorised.
Who may send, proof that they did, and what to do when the proof is missing. Three steps in one story.
What’s the security half of this?
The gap that sends your quote to junk is the same gap that lets somebody else put your business name in the From line of an email you never sent.
They don’t need access to your mailbox and they don’t need your password. They need your domain name, which is printed on your van and at the bottom of every email you’ve ever sent. If your domain publishes nothing about who may send on its behalf, a forged message carries exactly as much supporting evidence as a genuine one. None.
The version that costs money is the invoice. A convincing email lands with one of your customers, apparently from you, with amended bank details. They pay it, because why wouldn’t they. What follows is unpleasant for everyone, and the business whose name was borrowed takes most of the reputational damage even though its systems were never touched.
The same three records close both problems at once. One piece of housekeeping, two results.
What’s our domain publishing right now?
Before anyone changes anything, find out what’s actually there. It takes minutes, and it becomes the record you work from.
We built a free checker for exactly this: the Email Security Check. Put your domain in and it reads those public records and turns them into plain English. It only reads what’s already public, so it can’t see inside your email; it just tells you whether the door’s locked. You want three answers: does an SPF record exist and what does it list, is DKIM set up, and is there a DMARC record at all.
Screenshot the result with the date visible and save it somewhere findable. Whoever eventually works on this will need the starting position, and in six months nobody will remember it.
Who controls our DNS?
Here’s the question that stalls this job more often than any technical difficulty.
DNS records get changed in one place, and that place belongs to whoever manages your domain. Sometimes that’s the registrar you bought the name from. Sometimes it’s your web host, because the developer moved the settings there when the site was built. Sometimes it’s an account belonging to someone who did the website in 2018 and hasn’t been heard from since.
In our experience the fix is usually already in the business’s own hands: you have the access, you just didn’t know that’s what it was for. Sometimes it sits with whoever built the website, and in fairness to them, email deliverability isn’t their trade. Nobody hires a web designer to think about mail authentication.
So: find the domain, find who controls it, and confirm someone at your business can actually log in. If the answer turns out to be a former supplier or a dormant account, start the recovery process with the registrar now, not the week you need it.
What order do we fix it in?
Carefully, because these records can be got wrong in a way that stops legitimate email rather than starting it.
Publish an SPF record that omits your accounting system and your invoices start failing checks they previously passed by default. Set DMARC to reject on day one and any system you missed simply stops being delivered, silently, to everyone.
That’s why DMARC has a monitoring mode, and why starting there is normal. Monitoring mode asks receiving servers to report what they’re seeing without changing how anything is handled. You collect reports for a few weeks, discover four systems sending on your behalf instead of the two you remembered, fix the SPF list, get DKIM signing properly, and only then tighten the policy. Nothing breaks, because you looked first. This is work we do as part of managed IT support, and the sequencing is most of the skill.
It’s unglamorous. Nobody notices when it’s done. The quotes just arrive, in the inbox, where the customer expects them, and the phone doesn’t ring on Thursday asking where Tuesday’s email went. The same habit that fixes this fixes a lot else: check what’s actually there, rather than assuming. It’s the reason we also tell people to test whether OneDrive is really backing them up.
Quick answers
Will fixing the records get us out of junk folders immediately? Not instantly. The records answer the authentication question straight away, but sender reputation rebuilds over time, and each receiving provider moves at its own pace. Expect steady improvement over weeks rather than an overnight flip, and keep the before screenshot so you can see the difference.
We’re on Microsoft 365, so isn’t this already done? Partly, quite often. The base setup frequently covers mail from your own mailboxes, but the systems added later (invoicing, the website, marketing tools) are the usual gaps, and DMARC is often missing entirely. That’s why the check comes first: the answer is specific to your domain, not your platform.
Can our web designer sort this out? Maybe, and it’s worth asking. But be fair about the ask: deliverability is its own specialism, and the riskiest step is tightening the policy without finding every legitimate sender first. Whoever does it, insist on the monitoring-first order above.
What do the records themselves cost? Nothing. They’re text entries in DNS you already pay for. The real cost is care and a few weeks of watching reports, which is why the job gets stalled by access questions far more often than by money.
If you would like any help or advice, get in touch today!
