Blog · October 22, 2026
You sent an invoice to a client you have emailed a hundred times, and it never arrived. Or it arrived, but they found it in the spam folder three days later and were annoyed. Nothing about your message changed. So what did?
Almost always, the answer is that something outside your message changed. Spam filtering is not really about the words you write. It is about whether the receiving server can prove the message came from you, whether your domain has a history of behaving well, and whether your sending pattern looks like a person or like a machine that got loose. When legitimate mail lands in spam, one of those three has usually broken, and it is usually the first one.
Before a receiving server reads a single word of your email, it asks a simpler question. Is this message really from the domain it claims to be from? Three DNS records exist to answer that, and they are the foundation everything else sits on.
SPF is a list, published in your DNS, of the servers allowed to send mail for your domain. If a message arrives from a server that is not on the list, SPF fails. DKIM is a cryptographic signature attached to each message, which the receiver verifies against a public key in your DNS. If the message was altered in transit, or signed with a key that does not match, DKIM fails. DMARC is the policy that ties the two together and tells the receiver what to do when they fail, and it is also what generates the reports that tell you who is sending as you.
Here is the part most people miss. Having SPF and DKIM records is not the same as having them correct. A very common failure looks like this: your SPF record allows your web host's mail server, but your actual mail now goes out through Google Workspace or Microsoft 365, which is not listed. The record exists. It is published. It is also wrong, and every message fails SPF. The same thing happens with DKIM when a business switches email providers and the old signature stays in place, or when a booking system sends on your behalf using its own infrastructure that you never authorized.
If authentication is the lock on the door, reputation is whether anyone trusts you to have the key. Receiving servers keep score. They watch whether mail from your domain gets opened, replied to, marked as spam, or bounced. A domain that has sent almost nothing has no score at all, which is its own problem, because unknown is treated more cautiously than known-good.
This is why a brand new domain can have perfect authentication and still land in spam. There is nothing wrong with it. There is simply nothing right with it yet either. Reputation is built by sending consistent, wanted mail over time and by not sending unwanted mail, and there is no shortcut. What you can do is avoid the things that damage it: purchased lists, sudden volume spikes, and mail that generates complaints.
One specific trap deserves naming. If your domain has ever been used for bulk mail without proper authentication, or if a spammer has forged your domain in the From line, your reputation may be damaged by mail you never sent. This is the spoofing problem, and it is the reason DMARC enforcement matters even for a small business with no marketing department. Without an enforced policy, anyone can send as you, and their behavior becomes your reputation.
Filters model behavior. A mailbox that sends forty messages in an hour after sending two a week looks like a compromised account. A domain that suddenly sends to two thousand recipients it has never contacted looks like a list purchase. A message with a link to a domain registered eleven days ago looks like phishing, regardless of who sent it.
For normal business correspondence this rarely matters. It matters enormously if you are doing outreach, running a newsletter, or sending notifications from an application. If you are, volume needs to ramp gradually, and the domain sending that volume should be separate from the domain your invoices come from, so that a deliverability problem in one does not take down the other.
Start with authentication, because it is the only one you can check definitively and fix in an afternoon. Look up your SPF record and read it against the servers you actually send from. Check that your DKIM selector returns a public key. Check that your DMARC record exists, and read its policy. If your DMARC policy is p=none, you are asking for reports but telling receivers to deliver failing mail anyway, which is a monitoring posture rather than a protection.
If all three are correct and mail still lands in spam, the problem is reputation or behavior, and the diagnostic tool is your DMARC report stream. Those reports tell you which servers are sending as your domain, how many messages each sent, and whether they passed. A report showing a large volume from an IP you do not recognize is either a third-party tool you forgot about or someone spoofing you, and both need action.
If authentication is correct, reputation is clean, and volume is modest, then the remaining suspects are content and list quality. A message that looks like a template, sent to a list that has gone cold, will underperform no matter how correct the plumbing is. That is a marketing problem, not a technical one, and it is worth being honest about which you have.
Get authentication correct first, and get it correct for every system that sends as your domain, not just your main mailbox. That means your booking tool, your CRM, your invoicing platform, and your newsletter service each need their own authorization, because they send from their own infrastructure. This is the step people skip, and it is the single most common cause of "my email worked fine until we started using this new tool."
Then publish a DMARC policy that actually enforces. Move from p=none to p=quarantine once your reports show that everything legitimate is passing, then consider p=reject. Enforcement is what stops others from spoofing you, and it is what turns your reputation back into something you control.
Then leave it alone and watch it. Authentication breaks quietly. A provider changes an IP range, a vendor rotates a DKIM key, a record gets deleted during a DNS migration, and nobody notices until invoices start disappearing. The businesses that stay out of spam are not the ones that fixed it once. They are the ones that check.
If you want to know where you stand right now, run your domain through the checker on our homepage. It reads your public DNS records and tells you what is published, what is missing, and what is misconfigured. It takes about ten seconds and it does not require an account.