We’re building a brand protection tool for startups. As part of our research, we scanned 31 Indian SaaS startups (most based in Bengaluru) for email authentication and brand impersonation risks. These were companies in our outreach pipeline, all funded, mostly Seed to Series B, all actively shipping products.
The results were worse than expected.
The Numbers
Out of 31 startups we scanned:
- 35% have no DMARC record at all. Their domains have zero email spoofing protection. Anyone can send emails as @theircompany.com and those emails will land in inboxes looking legitimate.
- 41% have DMARC but set to p=none. They’re monitoring but not blocking. Spoofed emails still get delivered.
- 22% have no SPF record. No list of authorized email senders. Any server in the world can claim to send email for their domain.
- 76% have either no DMARC or DMARC in monitor-only mode. Combined, that means three out of four startups have no real protection against someone sending email as their domain.
- 0% had full protection (DMARC at p=reject with strict SPF). Zero. Not a single startup we scanned was actually enforcing email authentication.
Every single domain we checked had active MX records, meaning they all actively send and receive email. The attack surface is real.
Methodology note: We used our internal scanning tool to check DNS records for SPF, DKIM, and DMARC across the sample. The scan verifies the presence of records and the enforcement level of any DMARC policy. This is a snapshot of one sample of funded SaaS startups, not a national survey.
What This Means in Practice
If your domain has no DMARC and no SPF, here is what someone can do right now:
Send invoices to your clients as you. An attacker sends an email from accounts@yourcompany.com with a fake invoice and a different bank account number. Your client pays. You never sent the email. The email looks legitimate because your domain has no rules saying it shouldn’t.
Phish your own employees. An email from ceo@yourcompany.com asking the finance team to process an urgent wire transfer. Internal emails from your own domain are trusted implicitly. Without DMARC, there’s nothing to stop this.
Damage investor trust during due diligence. A Series A investor’s security team runs the same check we did. They see no DMARC, no SPF, and flag it in their assessment. Your fundraise slows down over something that takes 5 minutes to fix.
Undermine enterprise sales. An enterprise buyer’s procurement team checks your domain before signing. No email authentication shows up as a basic security gap. If you can’t protect your own email, why would they trust you with their data?
Why Most Startups Don’t Have This
It’s not negligence. It’s a gap in awareness.
Most CTOs and founders know about application security. They know about SQL injection, access control, API security. These are the things that come up in pentests and code reviews.
Email authentication (DMARC, SPF, DKIM) sits in the DNS configuration layer. Nobody teaches it in engineering courses. It doesn’t show up in OWASP Top 10. Your DevOps engineer might not know it exists unless they’ve specifically dealt with email deliverability issues.
The result: startups that build secure applications but leave their domain wide open for email spoofing.
How to Check Your Own Domain
Run these two commands in your terminal:
Check DMARC:
dig TXT _dmarc.yourdomain.com +shortIf you see nothing, you have no DMARC. If you see v=DMARC1; p=none, you’re monitoring but not blocking.
Check SPF:
dig TXT yourdomain.com +short | grep spfIf you see nothing with “spf” in it, you have no SPF.
How to Fix It (5 Minutes)
Step 1: Add SPF record
Go to your DNS provider (Cloudflare, Route53, GoDaddy, wherever your domain DNS is managed). Add a TXT record:
- Name: @ (or your domain)
- Value:
v=spf1 include:_spf.google.com ~all
If you use Google Workspace, this is the right value. If you use other email providers, add their SPF include. For example:
- Zoho:
include:zoho.in - Microsoft 365:
include:spf.protection.outlook.com - Resend:
include:resend.com
Multiple providers: v=spf1 include:_spf.google.com include:resend.com ~all
Step 2: Add DMARC record
Add another TXT record:
- Name: _dmarc
- Value:
v=DMARC1; p=none; rua=mailto:your@email.com
This starts in monitor mode. You’ll receive reports showing who is sending email as your domain.
Step 3: Upgrade over 4-6 weeks
- After 2 weeks of monitoring: change
p=nonetop=quarantine - After 2 more weeks: change
p=quarantinetop=reject
At p=reject, spoofed emails are blocked by compliant mail servers. Your domain is protected.
What We Learned Building the Tool
We built this scanning capability as part of a brand protection product we’re developing for startups. The email authentication check is one module. The full tool also scans for:
- Domains registered under your brand name across 1,700+ TLD extensions
- Lookalike domains with email infrastructure that could impersonate you
- SSL certificates using your brand name
- Active websites mentioning your brand
While building this, we wanted to understand how startups in Bengaluru actually handle brand protection. The answer, based on this scan: most don’t. Not because they don’t care, but because nobody flagged it.
If you’re a founder or CTO at a Bengaluru startup and want to check your own domain, reach out. We’re happy to share your specific findings as part of our research.
How We Scanned
This scan used publicly available DNS records only. No intrusive testing was performed. We queried DMARC and SPF TXT records, the same checks any mail server runs when it receives an email from your domain. No authentication was attempted, no systems were accessed, and no vulnerability testing was conducted.
Check your email security | How we approach security assessments | Cyber Threat Intelligence services | Talk to us