Why are my emails going to spam?

Your emails are going to spam for one of 4 reasons: your domain doesn't list its legitimate senders (SPF), your messages carry no verifiable signature (DKIM), you've never told receiving servers what to do with failures (DMARC), or your sending reputation has a problem the records can't fix. The first 3 are DNS records, checkable in 15 minutes for free, and fixable in an afternoon. This page is the plain-English walkthrough: how spam filtering actually decides, what each record does, the order to fix them in, and how to tell when your problem is the fourth kind.

The Australian numbers say most businesses get exactly one step down this path: 89% of small business domains publish SPF and 79% sign with DKIM, yet fewer than half enforce a DMARC policy^*. The records exist; the follow-through doesn't. That gap is usually the whole story behind "our quotes keep landing in spam".

How spam filtering actually decides

When your email arrives at a customer's provider, it is scored before a human ever sees it - and the scoring runs in a rough order of weight.

Authentication comes first. Can the receiving server verify this message genuinely came from your domain? That is what SPF, DKIM and DMARC answer. Mail that fails - or worse, mail from a domain that publishes no policy at all, leaving the receiver to guess - starts the race with a handicap it rarely recovers from.

Reputation comes second. The sending server's history, your domain's history, whether your provider's shared infrastructure has been misbehaving lately. You control this less directly, but authentication feeds it: a domain that authenticates consistently builds reputation; one that doesn't, can't.

Content comes last - and matters less than the folklore says. Spammy subject lines and tracking-link soup don't help, but well-written email from an unauthenticated domain still goes to spam, and a plain invoice from a properly authenticated one almost never does. If you are rewriting subject lines while your DMARC sits at p=none, you are polishing the wrong surface.

The 15-minute check

Put your domain into MXToolbox - the tool half the internet's mail administrators use for exactly this - and run its SPF, DKIM and DMARC lookups. You are answering 3 questions: does each record exist, does SPF actually list every service that sends as you, and what does your DMARC policy say after p=? Our scan runs the same checks as part of its Email category and reports them in plain English against the Australian baseline, on a schedule - but the one-off manual check is free and takes a quarter of an hour. We've also published short plain-English explainers on the individual records: what is DMARC, what is DKIM, and what an MXToolbox SPF result means.

The three records, in the order they work

SPF: the list of allowed senders

An SPF record is a DNS entry listing the servers permitted to send email for your domain. Receiving servers check the delivering server against the list. Two failure modes matter for a small business. The obvious one: a sending service missing from the list - the website contact form, the invoicing platform, the newsletter tool - whose mail fails checks from day one. The silent one: a record that has accumulated so many include: entries over the years that it exceeds SPF's 10-DNS-lookup limit and returns a permanent error, which receivers treat as no record at all. If your business has changed email or marketing providers a few times, assume the record needs an audit, not just a glance.

DKIM: the signature on the message

DKIM attaches a cryptographic signature to each outgoing message, verifiable against a public key in your DNS. Unlike SPF - which breaks when mail is forwarded - DKIM survives the trip, which is why receivers weight it heavily. It is configured per sending service: your email provider signs its mail, your newsletter platform signs its own, each with its own key under your domain. The practical task is enumerating everything that sends as your business and confirming each one signs. 79% of Australian small business domains have DKIM in place^* - usually because Microsoft 365 and Google Workspace set it up during onboarding - but the secondary senders, the form handlers and booking tools, are routinely unsigned.

DMARC: the policy that makes the first two mean something

SPF and DKIM produce check results; DMARC is where you tell receiving servers what to do about them - and get reports back about who is sending as you. Without DMARC, a failing message's fate is the receiver's guess. With p=quarantine or p=reject, you have made the decision for them: suspect mail goes to spam or gets refused, which protects both your deliverability and your customers, because the mail that fails hardest is the fraudulent invoice sent from "you" by someone else.

The Australian picture here is the weakest of the 3: 40% of small business domains publish a DMARC record without an enforcing policy, and about 1 in 6 have no DMARC record at all^*. A record sitting at p=none looks done in an audit checklist while changing precisely nothing about how your mail is treated.

From p=none to enforcement, without bouncing your own invoices

p=none is not a failure state - it is the correct first step, abandoned too early as a last one. The staged path:

1. Publish at p=none with reporting on. Add the rua= tag with an address to receive aggregate reports. Nothing changes about delivery; you start getting data.
2. Read the reports for 2 to 4 weeks. They list every server sending as your domain and whether it passed. Expect surprises - the booking system nobody remembered, the office scanner that emails PDFs. The raw XML is unreadable in volume; free report viewers exist for exactly this.
3. Fix the legitimate failures. Add missing services to SPF, get DKIM signing turned on for each one.
4. Move to p=quarantine, then p=reject. Once the reports show your real senders passing, tighten. Each step is one DNS edit, and each is reversible.

The whole sequence is a few hours of attention spread over a month. What it buys: your mail authenticates consistently (deliverability), and a fraudster sending invoices from your exact domain gets refused (protection). The OAIC's Australian Privacy Principles expect reasonable steps to secure the personal information businesses handle - and email that can be trivially impersonated is increasingly hard to defend as reasonable.

When it's the fourth reason: reputation

If all 3 records check out and mail still lands in spam, you are in reputation territory, and the fixes change shape. The usual suspects, roughly in order: a shared hosting provider whose other customers send spam from the same servers (the fix is sending your email through a proper email provider rather than the web server - which for most Australian small businesses means the Microsoft 365 or Google Workspace account they already pay for); a domain or server that has landed on a blocklist (checkable in the same MXToolbox pass; fix the cause before requesting delisting); or sending patterns that look like spam - bulk mail to bought lists, no unsubscribe link, sudden volume spikes. The Australian Cyber Security Centre's small business hub is also worth a visit here for the adjacent problem: if your account itself is compromised and silently sending spam, no DNS record will save your reputation until the account is secured.

What we don't do

We don't send your email, host your mailboxes or manage your provider - and this page isn't a pitch pretending we do. What our scan does is check the public half of everything above - SPF, DKIM, DMARC, the supporting records, the blocklists - continuously, in plain English, so "are the records still right" stops being a thing anyone has to remember. The fixes themselves live with whoever manages your domain and your email service, and after reading this page you can brief them in 2 sentences. Check the 3 records this week; enforce DMARC this quarter. Everything else in email deliverability is easier once those are true.