53% of YC Companies Don't Enforce DMARC
A scan of every active Y Combinator company domain: how many publish no DMARC or a monitoring-only policy, how close their SPF records are to the 10-lookup limit, and how many websites send HSTS and a Content-Security-Policy.
Published by AuthDrift · Last updated
53% of active Y Combinator companies don't enforce DMARC on their main domain. 15.5% publish no DMARC record at all, and another 37.5% publish p=none, which asks receivers to report on spoofed mail but not to reject it. For those domains, nothing in DNS tells Gmail or Outlook to refuse a message that pretends to come from the company's own address.
These are the numbers for the domains startups use to send invoices, password resets and investor updates. Below is how we measured them, the other four numbers from the same scan, and how to fix each problem.
How we measured
On 22 October 2026 we took every company marked Active or Public in the public YC company directory that lists a website: 4,368 companies. We reduced each website to its registrable domain (app.example.com becomes example.com) and ran the same checks as the free checker on this page against each one, from a single machine, using public DNS resolvers.
4,363 domains could be scanned (the rest no longer exist). Each percentage below uses only the domains where that check got a definite answer, so the denominators differ slightly. 97% of the domains have MX records and receive mail, so "they don't use email" doesn't explain the DMARC result: among mail-receiving domains the figure is 52.4%.
We then checked 40 randomly chosen failing domains by hand with dig and curl, and re-scanned 300 more. One web result in the 40 differed on the re-check; none of the DMARC results did. We only publish totals. No company is named here.
The five numbers
| Check | Result | Sample |
|---|---|---|
No DMARC record, or p=none |
52.9% (15.5% none + 37.5% p=none) |
4,354 domains |
| SPF at 9 or more of its 10 DNS lookups | 3.5% (1.3% over the limit) | 3,936 domains with SPF |
| Website sends no HSTS header | 23.3% | 4,303 HTTPS sites |
| Website sends no Content-Security-Policy | 76.4% | 4,304 sites |
| Passes all four | 12.2% | 4,302 domains |
Two details stood out. Companies from 2024 onward are slightly worse at DMARC than older ones (55.6% not enforcing vs 50.9%). But SPF records near the lookup limit are almost entirely an older-company problem: 5.8% of companies from 2023 and earlier, against 0.4% of newer ones. SPF records grow as a company adds sending tools, and nobody removes the old ones.
What causes each problem, and how to fix it
No DMARC, or p=none
Most domains start at p=none deliberately: it's the safe first step, and it produces reports showing who sends mail as you. The problem is that the second step, moving to quarantine or reject, needs someone to read those reports and confirm every legitimate sender is covered. At a startup that job has no owner, so p=none becomes permanent.
Fix: publish a record with a reporting address if you have none, check the reports for a few weeks, make sure your workspace, transactional email provider and marketing tool all pass with aligned DKIM, then move to p=quarantine and later p=reject. Our guide to the DMARC enforcement gap walks through it.
We also found 15 domains whose DMARC record is broken: two or more records published at once, or a malformed policy. Receivers ignore those records entirely. They aren't counted in the 52.9%.
SPF close to the 10-lookup limit
SPF allows at most 10 DNS lookups. Every include: for a sending service costs one or more, and a record that goes over the limit fails for every message, so receivers treat the whole policy as an error. Being at 9 or 10 means the next tool someone adds breaks SPF for all your mail.
Fix: remove includes for services you no longer use, and move bulk senders to a subdomain with its own SPF record. See the SPF 10-lookup limit.
No HSTS
Without Strict-Transport-Security, a browser that types the bare domain makes its first request over plain HTTP, which an attacker on the same network can intercept. Most hosting platforms redirect to HTTPS, but a redirect isn't the same as telling the browser to never use HTTP.
Fix: send Strict-Transport-Security: max-age=31536000; includeSubDomains from your site or CDN. Start with a shorter max-age if some subdomains still serve HTTP.
No Content-Security-Policy
CSP limits where a page can load scripts from, which is the main defense against injected JavaScript. It's missing from most sites because frameworks and site builders don't add one, and writing a policy means listing every analytics and chat script the marketing site loads. A further 8% of sites send a CSP that allows inline scripts, which removes most of its protection.
Fix: start with Content-Security-Policy-Report-Only, collect violations for a week, then enforce the policy. Even frame-ancestors 'none'; object-src 'none'; base-uri 'self' is better than nothing. See security headers and HSTS monitoring.
Check your own domain
Run your domain through the free checker on this page. It needs no signup and shows the same DMARC, SPF, HSTS and CSP results we used for this scan. These settings also change over time: someone adds a sending tool, a CDN setting is reset, and a record that passed last month fails today. AuthDrift can monitor the domain and email you when that happens.