Why Are My Emails Going to Spam?
Published
If your emails keep landing in the spam folder, the cause is far more often a missing DNS record than a bad subject line or a “spammy” turn of phrase. The single biggest deliverability failure is authentication — the records that let Gmail, Yahoo, and Microsoft confirm that mail claiming to be from your domain really is from you. In the August 2026 defaults.exposed census, an independent scan that graded 376,928,750 domains for email authentication, 214,276,774 of them — 56.8% — publish neither SPF nor DMARC. That is the majority of the internet sending mail with nothing for a receiving server to verify against, which is precisely the condition that routes a message to junk or blocks it outright. This guide explains why authentication decides deliverability, what Gmail and Yahoo now require, and how to check your own domain for free.
If you have already rewritten subject lines, trimmed links, and warmed up your sending, and mail still lands in spam, the problem is almost certainly upstream of the message itself. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.
The real reason your emails go to spam: authentication
Every large mailbox provider — Gmail, Yahoo, Outlook, Apple — makes a delivery decision on every message before it reaches an inbox. That decision is dominated by three questions, and none of them is about your wording:
- Does this mail authenticate to a domain? Can the receiver cryptographically or verifiably tie the message back to a domain that authorised it to be sent?
- Does that domain match the “From” address the human will see? Alignment is what stops a message that authenticates for one domain from displaying a different one.
- What is that domain’s sending reputation? Reputation is accumulated per authenticated domain over time — and it can only accumulate if step one succeeds.
If your domain publishes no authentication records, there is nothing for the receiver to verify and nothing to attach a reputation to. The message arrives as an unsigned claim from an unknown source, and the safest thing a spam filter can do with an unsigned claim is not trust it. That is the state most of the internet is in.
In the census, 214,276,774 domains — 56.8% of the 376,928,750 graded — publish neither SPF nor DMARC. They have taken no step at all toward being verifiable. This is not a fringe of abandoned domains; it is the majority profile, and it is the leading structural cause of mail landing in spam. We measured the shape of this cohort in The Silent Domain.
The fix is not a copywriting exercise. It is three DNS records, and the first move is simply to see which of them you are missing. Check your domain free at defaults.exposed — it reads your live SPF, DKIM, and DMARC records straight from public DNS and shows you exactly where the gap is. If the terms below are unfamiliar, start with the plain-language explainers for what a DMARC record is and what an SPF record is.
The Gmail and Yahoo sender rules, explained
In February 2024, Gmail and Yahoo jointly changed the rules for anyone sending significant volumes of email. Two years on, in August 2026, those requirements are no longer a grace-period suggestion — they are enforced, and they define the modern deliverability baseline. For bulk senders (broadly, those sending around 5,000 messages a day or more to their users), the providers now require all of the following:
- SPF and DKIM both configured for the sending domain — not one or the other.
- A DMARC record published, at minimum
p=none, on the organisational domain. - Alignment — the domain that passes SPF or DKIM must match the visible
Fromdomain. - One-click unsubscribe in marketing mail, honoured within two days.
- A spam-complaint rate kept below 0.3%, ideally under 0.1%.
The authentication trio sits at the top of that list for a reason: without it, none of the rest can be assessed, and mail is filtered or rejected before reputation even enters the picture. Crucially, these rules pushed publishing a DMARC record from best practice to table stakes — yet adoption is still thin.
The census found that just 20.0% of domains — 75,571,248 — publish any DMARC record at all, and only 9.3% (34,983,618) publish an enforcing policy of p=quarantine or p=reject. The remaining 90.7% (341,945,132) have no enforcing DMARC. Two years after the deadline, the overwhelming majority of the internet still does not meet the bar the two largest mailbox providers set. We tracked exactly where compliance stands in the twin report, The Google and Yahoo Deadline, Two Years On.
If you send from a small domain to a modest list, you may sit below the strict “bulk sender” threshold — but the filters do not switch off for smaller senders. They simply have less reputation to work with, which makes authentication more decisive for you, not less.
SPF, DKIM and DMARC: the deliverability trio
The three records work together. Each answers a different question a receiving server asks, and deliverability depends on all three lining up.
SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send for your domain. When a receiver gets a message, it checks whether the sending server’s IP is on your published list. SPF authorises the envelope sender — the invisible address used during delivery. The grading logic for presence is documented in the SPF exists methodology. In the census, SPF is present on 38.8% of domains (146,413,297) — the most-adopted of the three, but still a minority.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message, verifiable against a public key in your DNS. It proves the message was authorised by the domain and that its key contents were not altered in transit. Unlike SPF, DKIM survives forwarding, which makes it the sturdier of the two authentication mechanisms. See the DKIM exists methodology for how it is graded.
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two to the address a human actually reads. It requires that the domain passing SPF or DKIM is aligned with the visible From domain, tells receivers what to do when a message fails, and requests reports so you can see who is sending as you. The DMARC policy methodology covers how the policy tag is scored.
Together, these three are what a mailbox provider means by “authenticated mail.” Yet only 2.9% of domains (10,902,284) are fully protected across all three. The rest have gaps — and the most damaging gaps are not always the obvious “nothing published” ones. A telling example: 16 million domains publish DMARC without any SPF at all, an inverted setup that leaves the policy leaning on DKIM alone and often misconfigured. Having one record is not the same as being authenticated.
Soft-fail and p=none: the settings quietly hurting you
Publishing the records is only half the job. The values inside them decide whether a receiver treats your mail as trusted or merely tolerated — and two default-flavoured settings quietly undercut deliverability for millions of domains that believe they are set up correctly.
The SPF soft-fail (~all). An SPF record ends with a qualifier that tells receivers how to treat mail from servers not on your list. -all (hard fail) says “reject anything not listed.” ~all (soft fail) says “this probably isn’t authorised, but deliver it anyway and mark it.” Soft fail is the weaker, more permissive setting — and it is the more common one. Of domains that publish SPF, 56.4% (82,539,695) use ~all soft fail, versus 38.4% (56,268,491) using the stricter -all. A soft-fail record gives a receiver a weaker signal to work with, and weaker signals lose the close calls that land mail in spam. The trade-off is quantified in SPF Hard-Fail vs Soft-Fail, and the grading is in the SPF policy strength methodology.
The DMARC monitor-only policy (p=none). A DMARC record can be present, valid, and still do nothing. p=none tells receivers to report on failing mail but take no action against it — it is a listening post, not a protection. Of domains that publish DMARC, 53.6% (40,541,896) sit at p=none. They show up as “DMARC configured” in a basic check while providing no enforcement and building no protective reputation. p=none is the correct first step while you confirm your legitimate senders align — but as a permanent home it is a record that looks like progress and delivers little. Getting value from it depends on actually reading the reports, which is what the DMARC reporting methodology grades.
The pattern across both settings is the same: a domain does the visible work of publishing a record, sees a green tick somewhere, and stops — leaving the setting on its weakest value. Receivers see that weakness even when the sender does not.
How the other 97% get flagged, and where you stand
Turn the fully-protected figure around and the scale of the problem is stark. If 2.9% of domains are authenticated across SPF, DKIM and DMARC, then 97.1% are not — they are missing at least one leg of the trio, or running it on a setting that a receiver discounts. Here is roughly where the graded internet sits, worst to best:
- 56.8% (214,276,774) publish neither SPF nor DMARC. Nothing to verify; the highest-risk state for deliverability. These are the domains a filter has the least reason to trust.
- Around 86.9 million domains (23.1%) publish SPF but no DMARC. They have taken the first step, but without DMARC there is no alignment check and no instruction to receivers — SPF alone protects the envelope, not the
Fromline the recipient reads. - 20.0% (75,571,248) publish some DMARC record, but half of those sit at
p=noneand do not enforce. - 9.3% (34,983,618) enforce DMARC at
p=quarantineorp=reject. - 2.9% (10,902,284) are fully protected across all three records.
For a typical small business, the honest reading is uncomfortable: the odds are you are in the top band of that list — no SPF, no DMARC, or an SPF record on ~all with no DMARC behind it. That is not negligence; it is the default state of the internet, because domains do not arrive with these records and nothing forces you to add them until your mail starts disappearing.
Deliverability and domain reputation are two views of the same thing: authenticated senders accumulate trust, unauthenticated ones cannot. If your mail is inconsistent — fine one week, filtered the next — thin authentication is usually why the reputation never stabilises. We cover how that trust is measured and checked in Domain Reputation: What It Is and How to Check Yours.
Fix your deliverability: a 4-step checklist
The good news is that the fix is finite, well-documented, and mostly free. It is DNS work, not development work, and it can be done in an afternoon plus a short listening period. Do it in this order:
- See exactly what you are missing. Before you change anything, get an accurate picture of your current SPF, DKIM, and DMARC state. Run your domain through a free scanner — Check your domain free at defaults.exposed — which reports each record straight from public DNS and flags weak settings like
~allandp=none. If you want the full remediation done for you rather than tag by tag, see how the fix works. - Publish or repair SPF, ending in
-all. List every service that legitimately sends for you — your mail platform, CRM, invoicing tool, newsletter provider — and set the record to hard fail (-all) once you are confident the list is complete. Watch the ten-lookup limit; consolidate includes if you are near it. - Turn on DKIM signing. Enable DKIM in your mail platform and publish the public key it gives you. Because DKIM survives forwarding, it is the mechanism most likely to keep mail authenticated across mailing lists and relays.
- Publish DMARC and move it toward enforcement. Start at
p=nonewith arua=address you monitor. Read the aggregate reports for two to four weeks to confirm your real senders align, then tighten top=quarantineand finallyp=rejectatpct=100. Each move is one DNS edit; the work is the listening, not the typing.
Done in sequence, none of these steps risks blocking your legitimate mail — the domains that break their own email almost always jumped straight to p=reject without the listening phase in step four.
Beyond authentication: the other reasons mail gets filtered
Authentication is the dominant factor — it is the gate everything else passes through — but it is not the only one, and a complete answer to “why are my emails going to spam” has to name the rest. Once your SPF, DKIM, and DMARC are in order, these are the factors that decide the remaining close calls:
- Sending reputation. Even a fully authenticated domain earns trust slowly. A brand-new domain, or one that suddenly jumps from ten messages a day to ten thousand, has no track record, and receivers treat unknown senders cautiously. Reputation is accrued per authenticated domain and per sending IP — which is the whole reason authentication has to come first. How that reputation is measured is covered in Domain Reputation: What It Is and How to Check Yours.
- Complaint rate. Gmail’s and Yahoo’s rules put a hard ceiling on spam complaints — below 0.3%, and ideally under 0.1%. A handful of “report spam” clicks on a small list can push you over it. Clean, permission-based lists and an easy unsubscribe keep this number down.
- List hygiene. Sending to dead mailboxes, spam traps, or addresses that never opted in signals a low-quality sender. Every hard bounce and every trap hit is a mark against you. Verify addresses before you send, and remove chronic non-openers.
- Content and links. This is the factor most people fixate on, and it matters least in isolation. Broken authentication will filter a perfectly written message, while an authenticated sender with good reputation can send plain, link-light mail all day. Content only becomes decisive once the structural signals are clean.
- Where you send from. Mail sent from a mismatched or shared IP with a poor neighbourhood reputation inherits that reputation. A dedicated, warmed sending setup that aligns with your authenticated domain gives receivers a consistent signal to trust.
The order of that list is the point. Authentication and reputation sit at the top because they are structural; content and formatting sit at the bottom because they only decide outcomes for senders who have already cleared the structural bar. If your mail is going to spam and you have not checked your authentication, you are optimising the bottom of the list while the top is broken.
What this means
For small-business owners, the spam problem you have been treating as a copywriting or “warm-up” issue is usually a DNS issue. When invoices, quotes, and booking confirmations land in a customer’s junk folder, the cost is missed revenue and a phone call that never comes — and with 56.8% of domains publishing neither SPF nor DMARC, you are almost certainly in the untrusted majority until you check. The fix is free to diagnose and cheap to deploy, and it is the single highest-leverage change you can make to how much of your mail actually arrives.
For marketers and anyone sending campaigns, authentication is now the gate in front of every deliverability metric you track. Open rates, click rates, and unsubscribe handling only matter for mail that reached the inbox — and Gmail and Yahoo will filter unauthenticated bulk mail before any of those numbers are earned. With only 9.3% of domains enforcing DMARC, meeting the sender rules is not a compliance checkbox; it is a competitive advantage over the 90.7% who have not.
For IT teams and MSPs, the census profile is a client-conversation opener. Most domains you inherit will be in the neither-record or SPF-only-on-~all state, and the remediation is standard, low-risk, and billable. Moving a client from unauthenticated to a fully aligned SPF-plus-DKIM-plus-p=reject posture removes both a deliverability problem and an impersonation exposure in the same set of DNS edits.
FAQ
Why are my emails going to spam? The most common reason is missing or weak authentication, not the content of your message. If your domain has no SPF, DKIM, or DMARC records, a receiving server like Gmail has nothing to verify and no reputation to trust, so it plays safe and filters the mail. In the August 2026 census, 214,276,774 domains — 56.8% — publish neither SPF nor DMARC, which is the leading structural cause of mail landing in spam. Even domains that publish records often weaken them with a soft-fail SPF or a monitor-only DMARC. Fix the authentication first, then look at content and sending habits.
Do I need DMARC?
If you send email from your own domain, yes — and increasingly you have no realistic choice. DMARC is what ties your SPF and DKIM to the address recipients actually see, and it is the record that lets you request reports on who is sending as you. Without it, receivers cannot run an alignment check, and bulk mail to Gmail and Yahoo can be filtered on that basis alone. Only 20.0% of domains (75,571,248) publish any DMARC record, so adding one already puts you ahead of most of the internet. You can start safely at p=none while you confirm your legitimate senders.
Is DMARC required?
For bulk senders to Gmail and Yahoo, effectively yes: since February 2024 those providers require a published DMARC record (at least p=none) alongside aligned SPF and DKIM, and two years on the requirement is enforced. For smaller senders it is not strictly mandated, but the same filters apply with less reputation to fall back on, so it remains strongly advisable. The census shows 90.7% of domains (341,945,132) still have no enforcing DMARC policy, meaning most of the internet meets the letter of the rule at best and the spirit of it rarely. Publishing and then enforcing DMARC is the reliable path to the inbox.
How do I check whether my domain is authenticated?
Run it through a free scanner. Check your domain free at defaults.exposed — it reads your published SPF, DKIM, and DMARC records directly from public DNS and tells you not just whether each exists but whether it enforces: whether your SPF ends in a hard -all, whether your DMARC is p=none or actually protecting you, and whether your setup can be spoofed. It takes about 30 seconds and needs no account. It is the fastest way to confirm whether your spam problem is an authentication problem before you spend time rewriting messages.
Will fixing SPF and DMARC break my legitimate email?
Not if you sequence it correctly. Publishing SPF with an accurate sender list and starting DMARC at p=none changes nothing about delivery while you gather the reports that show which services need aligning. Only after those reports confirm your real senders pass do you tighten SPF to -all and DMARC to quarantine then reject. Problems almost always come from skipping the listening phase and jumping straight to enforcement. Taken in order, the change improves deliverability without risking your own mail.
Data to cite
- “56.8% of domains (214,276,774) publish neither SPF nor DMARC, the leading cause of mail landing in spam.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “90.7% of domains (341,945,132) have no enforcing DMARC, the policy Gmail and Yahoo now require from bulk senders.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “56.4% of SPF publishers (82,539,695) use a soft-fail
~allthat gives receivers a weaker signal to work with.” — defaults.exposed August 2026 Domain Security Census (432M domains) - “Only 2.9% of domains (10,902,284) are fully authenticated across SPF, DKIM and DMARC.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Just 20.0% of domains (75,571,248) publish any DMARC record at all.” — defaults.exposed August 2026 Domain Security Census (432M domains)
See where your own domain stands
If your mail keeps landing in spam, the question is not “which words tripped the filter” — it is “can a receiving server verify that this message is really from me.” For most domains the answer is no, and the owner has never seen it stated plainly, because the records that would prove it were never published.
Check your domain free at defaults.exposed — it reads your live SPF, DKIM, and DMARC records from public DNS and tells you instantly whether you are authenticated, whether your settings actually enforce, and whether your domain can be spoofed. Takes 30 seconds. No account needed. If you want the gaps closed properly — SPF, DKIM, and an enforcing DMARC policy set up in the right order — see how the fix works.
Read the flagship census report: The State of Domain Security 2026 →
Related from this series: The Google and Yahoo Deadline, Two Years On · The Silent Domain · SPF Hard-Fail vs Soft-Fail · Domain Reputation: How to Check Yours
Aggregate data only. Data stored and processed in the EU.
Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from 432,127,908 scanned. All figures are counts of graded domains. References: RFC 7489 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM).
How to cite this report
Press / blog: defaults.exposed (2026). Why Are My Emails Going to Spam? The Authentication Gap Behind It. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/why-are-my-emails-going-to-spam
Academic: defaults.exposed. (2026, August 21). Why Are My Emails Going to Spam? The Authentication Gap Behind It. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/why-are-my-emails-going-to-spam
In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 graded domains)
About the defaults.exposed August 2026 Census
The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them for email authentication using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.
Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026
Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →