Your quotes may be going to spam, and nothing will ever tell you.
Three DNS records decide whether your email arrives or lands in junk, and whether anyone else can send mail pretending to be you. Most small businesses have never heard of them, and nothing in the inbox looks broken when they are wrong.
Mail servers (MX)Whether your domain is set up to receive mail at allSPF recordWhich servers are allowed to send email as your domainDKIM keysWhether your mail is cryptographically signed so it cannot be forgedDMARC policyWhat receiving servers should do with mail that fails the first two
The failure nobody notices
Every other website problem announces itself. The site goes down and the phone rings. A page looks wrong and somebody tells you. Email authentication is different: when it fails, everything looks completely normal from your side. You write the quote, you press send, your sent folder shows it went. It simply never arrives in the inbox the customer reads.
The customer does not tell you it went to spam, because they never saw it. They assume you did not bother replying and they call someone else. From where you sit, that is not a technical fault, it is a quiet, unexplained drop in how many enquiries turn into work.
Google and Yahoo tightened this considerably for bulk senders, and the direction of travel across the whole industry is the same: mail from a domain that cannot prove who it is gets treated with suspicion.
What the three records actually do, in plain English
SPF is a list. It names the servers allowed to send email using your domain. If your mail comes from Microsoft 365 and your quoting software, both need to be on the list. If the list is missing, receiving servers have no way to tell your genuine mail from somebody forging your address.
DKIM is a signature. Your mail server signs each message with a private key, and the matching public key sits in your DNS so the receiver can check the signature. It proves the message really came from you and was not altered on the way.
DMARC is the instruction. It tells receiving servers what to do when a message fails SPF and DKIM: let it through anyway, put it in junk, or reject it outright. Without DMARC the first two records are advisory, and a spammer forging your domain gets the benefit of the doubt.
Don't know what these are? Don't worry, we've got you!
The second problem: somebody else spending your reputation
Missing records do not only cost you delivery. They let anyone put your domain in the from line of their own email. Their spam earns your domain the bad reputation. You get flagged for messages you never sent, and nothing anywhere tells you it is happening.
A domain marked as a spam source is hard to rehabilitate. It is much cheaper to publish three DNS records than to rebuild a sender reputation, and the whole job is usually under an hour of work for whoever manages your DNS.
Why checking once is not the job
Almost everybody who fixes this fixes it once and assumes it is done. It is not. Every time you add a new tool that sends email on your behalf, a newsletter platform, a booking system, a CRM, your SPF record needs to know about it, and typically nobody updates it. A DNS change during a website move can drop the records entirely.
That is the actual product here. The fix takes an hour. Knowing it is still correct every week, forever, without you remembering to look, is the part worth paying for.
Common questions
How do I know if my emails are going to spam?
Usually you do not, which is the problem. The signals are indirect: quotes that never get replied to, customers saying they never heard from you, or replies arriving days late. Checking whether you publish SPF, DKIM and DMARC records tells you whether you are exposed to the most common cause.
Do I need all three of SPF, DKIM and DMARC?
Yes. They do different jobs. SPF says which servers may send, DKIM proves a message was not forged or altered, and DMARC tells receivers what to do when the first two fail. Publishing one or two of them leaves obvious gaps.
Who sets these up?
Whoever manages your DNS, which is usually your web company, your IT provider or your domain registrar. They are three text records. The work is small; knowing they are needed is the hard part.
Fixed once is not fixed
Everything on this page is a one-off job for whoever manages your website or your DNS. The reason it is a product rather than an afternoon is that all of it drifts: records get dropped in a migration, renewals break, a new tool starts sending email on your behalf and nobody updates the list. We check every week and show you what changed, in plain English, with the fix attached.