Beg Bounty Emails: How to Tell Them From Real Security Reports
A stranger says your site has a critical flaw such as missing DMARC and asks about a reward. Here is how to judge the email, what to fix, and how to reply.
The email usually looks something like this: "Hi, I am a security researcher. I found a critical vulnerability on your website. Do you have a bug bounty program? I will share the details once we agree on a reward." Then, in the second message, the "vulnerability" turns out to be a missing DMARC record or a missing security header.
This guide is for business owners who receive these messages. It explains what these "beg bounty" emails are, how to tell them apart from genuine reports, what is still worth fixing, and how to reply, if at all.
In short: You don't owe anyone a reward, and you shouldn't click their links, open attachments or give them access. Most of these emails point out things anyone can see with free public tools, so check those yourself. A genuine report names a specific page, explains how to reproduce the problem, and doesn't make payment a condition. A simple security.txt file tells real researchers how to reach you.
What a "beg bounty" is
Security researcher Troy Hunt popularised the term in his post Beg Bounties: someone runs a public scanning tool against a website that has no bug bounty programme, then emails the owner hoping to be paid. He describes the findings as typically easy to discover, publicly observable and minor in nature, such as DMARC records or a missing Content Security Policy, and quotes Sophos describing the practice as "scaremongering for profit".
These emails are sent in bulk. Getting one doesn't mean anyone has targeted your business in particular.
How to tell a beg bounty from a real report
| Sign | Beg bounty | Genuine report |
|---|---|---|
| Opening | "Do you have a bug bounty?" before any detail | Describes the issue straight away |
| Finding | Missing DMARC or SPF, missing headers, clickjacking, "version disclosure" | A specific page, parameter or exposed file with impact explained |
| Evidence | Screenshot of a scanner grade, or nothing | Steps to reproduce, request and response, or a safe proof |
| Severity | "Critical" for a configuration gap | Severity proportionate to what an attacker could actually do |
| Money | Payment asked for, or details held back until you agree | Help offered without conditions; may mention your bounty if you publicly run one |
| Follow-up | Repeated chasing, sometimes threats to "go public" | Gives you reasonable time to fix |
One sign alone doesn't settle it. Real researchers write clumsy emails too. What matters is whether the report is specific and whether the information is offered without conditions.
Watch out: Treat links and attachments in these emails as you would any unexpected email. Don't install "verification" software, don't give anyone a login, and don't run commands they send you.
The findings are usually real, so check them yourself
The irritating part is that the findings are often technically true. A missing DMARC record or missing security headers aren't emergencies, but they're worth fixing, and you don't need the sender to do it.
Missing DMARC or SPF. Without them, it's easier for someone to send email that pretends to come from your domain. That's an email spoofing risk, not a hole in your website. Look up your domain with the free DMARC & SPF checker, then follow SPF, DKIM and DMARC explained to set them up. When you're ready to tighten the policy, moving DMARC from none to reject shows how to do it without blocking your own mail.
Missing security headers or clickjacking. "Clickjacking" in these emails usually means your pages can be shown inside another site's frame because a framing control header is missing. Check with the free security headers checker, then add the security headers every small business website needs.
"Server version disclosed." A header that shows your server or PHP version doesn't make you vulnerable on its own, but it helps attackers pick targets. Hide it if your host allows, and more importantly keep the software updated.
If you'd like everything checked in one go, the free Safe Scan on pentest.lordevo.com passively checks headers, TLS, cookie flags, a short list of files that should never be public, and your SPF, DMARC and DKIM records. It's automated and nothing is attacked. It also won't email you asking for a reward.
How to reply, or not
You have three reasonable options:
- Ignore it. This is fine for vague emails that don't name a specific problem.
- Send a short, neutral reply. For example: "Thanks for getting in touch. We don't run a paid bug bounty programme. If you have found a specific issue, please send the details and steps to reproduce, and we will look into it." This costs nothing, and a genuine researcher will usually send the details.
- Forward it to whoever runs your website if the email is specific and you can't judge it yourself.
Don't promise payment to see the details, and don't argue. If you do decide to thank a genuine reporter, that's your choice, not an obligation.
What if they threaten to "disclose"?
Some senders escalate: "If you don't respond, I will publish this vulnerability." Stay calm. Publishing that your domain lacks a DMARC record reveals nothing that anyone can't already look up in public DNS.
- Keep the emails as a record.
- Fix anything real, using the steps above.
- Don't pay. Paying for silence encourages more of the same.
- If the threat becomes extortion, mentions stolen data, or comes with proof of actual access to your systems, treat it as a security incident. Contact your web developer or host, and report it to the police or your national cybercrime reporting service.
Make it easy for real researchers: add security.txt
Genuine researchers sometimes struggle to find the right contact, and their emails get ignored as spam. A security.txt file fixes that. It's a small text file at /.well-known/security.txt on your site, defined in RFC 9116. Two fields are required: Contact (an email address or web page for reports) and Expires (a date after which the file should be treated as out of date; the RFC recommends less than a year ahead). An optional Policy field can link to a page explaining that you don't pay bounties. The securitytxt.org site has a generator.
Contact: mailto:security@yourdomain.com
Expires: 2027-10-31T23:59:59Z
Policy: https://yourdomain.com/security-policyA published contact doesn't stop beg bounty emails, but it gives real reports a clear route.
Key takeaways
- A "critical vulnerability" email asking about a reward is usually a beg bounty, not an attack.
- You're under no obligation to pay, click links, or grant access.
- Check the claims yourself with free tools, and fix what's real: DMARC, SPF and security headers are worth having anyway.
- Genuine reports are specific, reproducible and unconditional.
- Threats to disclose public configuration details are hollow, but anything involving real data or access needs proper incident handling.
These emails feed on the same fear as unsolicited "your SEO is broken" pitches. Our guide to spotting a fake SEO offer covers that side.
FAQ
Is it illegal for them to scan my site? That depends on your country and what they did. Passive checks like reading DNS records or response headers use public information. Anything that tried to break in is different, so keep the emails if you're concerned.
Should I set up a bug bounty programme? For most small businesses, no. A security.txt file and a polite policy are enough.
Can a missing DMARC record get my website hacked? No. It affects how easily your email can be spoofed, not the security of your website.