Why the mail is being filtered
Mail lands in spam for one of three reasons: the receiving system cannot prove the message came from you, the domain or IP that sent it carries a poor reputation, or enough recipients have marked similar mail as junk. Authentication is the only one of the three you can fix in an afternoon, so it is where to start, and it is also where most of the damage turns out to be.
This is for someone whose own business mail has started going to junk: replies to customers, form notifications, invoices, password resets. It assumes you own the domain and can change its DNS. The first half works through the causes in roughly the order a receiver evaluates them. The second half is the order to check them in, which is not the same order.
Authentication is the first thing a receiver looks at
Before anything decides whether your message is interesting, something decides whether it is yours. That question has three answers: SPF, which lists the servers allowed to send for your domain; DKIM, which puts a cryptographic signature in the message; and DMARC, which tells receivers what to do when neither of the first two matches the domain your recipient sees.
Google’s own sender requirements put SPF or DKIM at the top of the list for every sender, along with valid forward and reverse DNS records for your sending IPs, a TLS connection, and messages formatted per RFC 5322 (September 2026). Missing one of those does not guarantee the junk folder. It removes the cheapest evidence in your favor and leaves the decision to everything else.
Gmail and Outlook.com publish requirements with numbers in them
Above a certain volume the requirements stop being advice. Google’s list for senders of 5,000 or more messages a day to personal Gmail accounts asks for both SPF and DKIM rather than either one, a published DMARC record where a policy of none is enough, alignment between the From domain and the domain that passed SPF or DKIM, and one-click unsubscribe on marketing and subscribed mail.
Microsoft enforces the same shape of rule with a specific bounce. A sender of 5,000 or more messages using the same domain that has not met the requirements gets 550 5.7.515, which reads “Access denied, sending domain does not meet the required authentication level”, and the fix Microsoft names is SPF and DKIM passing plus a DMARC record such as v=DMARC1; p=none with alignment. If you are seeing that code in your bounces, the diagnosis is finished and the rest of this article is the instructions.
A spam rate above 0.3 percent is already a filtering decision
Google’s requirement is to keep spam rates reported in Postmaster Tools below 0.3 percent. That is three complaints in a thousand messages, which is a lower bar than most people guess, and the number is not something you can reason your way to from the outside.
Postmaster Tools is where that figure lives, along with domain and IP reputation, authentication results and delivery errors. It has one catch worth knowing before you go looking: data can be missing when the daily message count is too low, which Google does to protect user privacy. A business sending a few hundred messages a day may see nothing at all there, which is exactly why small senders end up diagnosing this blind.
Your website is usually the unauthorized sender
Nearly every site sends mail. Contact form notifications, order receipts, password resets, admin alerts. Left alone, a WordPress site hands those to the web server’s default mailer, which sends them from the hosting IP with a From address at your domain and no DKIM signature at all.
That mail is genuinely yours and it fails authentication anyway, which makes it the single most common entry in a domain’s failing bucket. It also teaches the receiver that your domain sends unauthenticated mail, which costs you on the messages you sent properly. Routing it through a real sending path, either Email Delivery for Cloudflare or a transactional email service, removes the problem rather than patching it.
One-click unsubscribe is two headers, not a link in the footer
The unsubscribe link at the bottom of your newsletter does not satisfy the requirement. RFC 8058 defines a header pair: List-Unsubscribe-Post: List-Unsubscribe=One-Click, and a List-Unsubscribe header that must contain one HTTPS URI.
When the recipient clicks the unsubscribe button their mail client shows, the receiving system sends an HTTPS POST to that URI carrying the key and value from the first header. The specification is blunt about one detail that catches people out: the sender must not answer with an HTTPS redirect, because redirected POST requests have historically not worked reliably. A tracking redirect in front of your unsubscribe endpoint will break it silently.
Spam traps and the list nobody has cleaned
A spam trap is an address that exists only to catch senders who are mailing without permission. Some are abandoned mailboxes that a provider has turned into traps, which is how a list you collected legitimately in 2019 becomes a liability. Others have never belonged to a person and were seeded somewhere a scraper would find them, so any mail arriving is proof of how the address was obtained.
You cannot detect them by looking, and no vendor will tell you which address it was. What you can do is stop mailing addresses that have not opened anything in a year, and never import a list you did not collect. High bounce rates and trap hits tend to travel together, so a list that bounces badly is usually hitting traps as well.
Reputation attaches to the domain and to the IP separately
These are two different reputations and people conflate them constantly. The domain reputation follows your domain wherever you send from. The IP reputation belongs to the machine, and on a shared sending IP it belongs partly to strangers.
The practical consequence is that moving to a new email provider resets one of them and not the other. If the domain is the problem, a new IP buys you a few good days and then the same filtering resumes. If the IP is the problem, the move genuinely helps. Telling the two apart before you migrate anything saves a migration.
Working through it in the order that finds it fastest
The causes above are not equally likely, and checking them in the order they were listed is slower than it needs to be. This is the order that puts the answer in front of you soonest, and most domains stop at step three.
Start with one message that landed in junk
Get a copy of a specific failing message with its full headers. In Gmail that is Show original on the message; in Outlook it is the message source. You are looking for one line, Authentication-Results, which reads something like dkim=pass header.i=@example.com; spf=pass smtp.mailfrom=example.com; dmarc=pass (p=NONE) header.from=example.com.
Three passes there and your authentication is fine, which means the problem is reputation or content and you can skip four sections. A fail or a none on any of the three tells you precisely which record to go and read. This one header replaces a great deal of guessing, and it is free.
Read the record a receiver resolved, not the one you believe you published
The gap between the DNS you edited and the DNS the world sees is where a surprising number of these problems live. A typo, a record added at the wrong host, a provider that wraps long TXT records badly, a change that has not propagated.
The fastest check is your own DMARC reports, because the policy_published block in each one is a receiver reading your record back to you. Walking through what those files contain is its own subject, and reading a DMARC report covers it field by field. Without reports, dig +short TXT example.com and dig +short TXT selector._domainkey.example.com from a machine outside your network gets you the same answer in two commands.
Count your senders before you edit the SPF record
SPF has a hard limit that is easy to cross and gives no obvious symptom. RFC 7208 requires implementations to limit the total number of DNS-querying terms to ten during evaluation, and counts include, a, mx, ptr and exists, plus the redirect modifier, toward that total. Exceeding it means the evaluator must return permerror, and permerror is not a pass.
Each vendor you add contributes at least one include, and a single include can expand into several more lookups inside itself, so a record with six vendor includes may already be over. There is a second limit worth knowing: void lookups, meaning queries that return no answer or a name error, should be capped at two, and passing that also produces permerror. The syntax and the counting are covered in detail in how an SPF record is built.
Sign every sender with DKIM, including the ones you forgot about
If you do one thing after fixing SPF, sign everything. A DKIM signature travels inside the message, so it usually survives a plain forward, while SPF stops being useful the moment someone forwards your mail from their own server.
Every service that sends as you needs its own key published at its own selector: the mailbox provider, the marketing platform, the helpdesk, the invoicing system, the website. Alignment defaults to relaxed for both SPF and DKIM, so a signature from mail.example.com still matches a From address at example.com, which is what makes subdomains workable. What does not align is a vendor signing with its own domain, and that shows as a DKIM pass in the raw results and a DKIM fail in the DMARC verdict.
Only now check whether you are listed somewhere
Blocklists get checked first by most people and they are rarely the answer, which is why they sit here rather than at the top. When a listing is the cause, though, it is usually the whole cause, and mail is being refused outright rather than filed in junk.
Look up your sending domain and each sending IP address against the major lists. A listing that appeared the same week the filtering started is your answer. A listing that has been there for months while mail was arriving normally probably is not. Either way, note the date it started, because the delisting request almost always asks what changed.
Content and volume signals come last, and they matter least
The advice you will find most of online sits here: subject lines, image ratios, the word free. It is not wrong, it is just low value next to everything above, and rewriting your copy while your DKIM is broken is wasted effort.
Two content problems are worth attention because they are structural rather than stylistic. A link shortener in the body of your mail puts a domain with somebody else’s reputation into your message. And a sudden jump in volume, the classic being a quiet domain that sends its first large campaign, reads as a compromised account to a receiver who has no history to compare it against. If you are about to increase volume sharply, do it over a couple of weeks rather than in one morning.
When everything passes and mail still goes to junk
This happens, and it is the point where the problem stops being a record and starts being a pattern. Authentication proves the mail is yours. It says nothing about whether recipients want it, and a filtering decision built on complaint history will not be argued away with a DNS change.
What works from here is unglamorous: mail people who asked for it, remove anyone who has not engaged in a year, keep the sending volume steady, and make the unsubscribe easy enough that nobody reaches for the junk button instead. Then watch the numbers rather than your inbox, because by the time you notice personally it has been happening for weeks.
Watching it for you is what Deliverability Monitoring exists to do. We check the major blocklists every day for your domain and your sending addresses, track your sending reputation against your own baseline rather than a generic benchmark, and tell you the day something changes instead of at the end of the month. When a listing appears we name the cause rather than the symptom, handle the delisting ourselves, and check again until it clears. Nothing is installed and we never see your mailboxes. Every check is kept for 90 days, so you can show exactly when a listing started and when it cleared. It is not inbox placement testing, which needs a seed-list vendor, and we do not pretend to offer that.
The other half is the records themselves. Email Authentication proves the mail is yours, and Deliverability Monitoring watches whether it is arriving; they solve different halves of the same problem, and a domain with filtering trouble usually needs both. If you are weighing this against a tool you would run yourself, the deliverability comparisons take the main options in turn. And if the hard part is that nobody is sure who controls the zone you need to edit, that is a DNS problem before it is an email one, and the walk through DNS record types is a reasonable place to start.