security-txt.eu

AdviceAs of 6 min read

Spam after security.txt: what the file can do about it

Shortly after your security.txt goes live, the first emails arrive that sound like vulnerability reports and ask about a reward. That is normal, not a mistake in your file. A few settings in the file, the policy and the mailbox cut it down noticeably, without losing a single real report.

Where the spam comes from

security.txt is built for machines: it always sits at the same address, /.well-known/security.txt, in a fixed format. That is exactly why it is found not only by security researchers and CERTs, but also by programs that crawl domains in bulk and harvest addresses.

What lands in the mailbox afterwards usually follows one of three patterns:

  • Beg bounty. A tool finds a run-of-the-mill finding, such as a missing HTTP header or DMARC record, and a template turns it into a "vulnerability report" asking for a reward. Sophos described the pattern back in 2021.
  • Unverified scanner output. Attached tool output with no manual verification and no description of impact.
  • Machine-written reports. Long, fluent, full of jargon, but unrelated to the actual system. The open source project curl counted only about 5 percent valid submissions in 2025 and ended its bounty programme in January 2026.

Somewhere in between is the one email that matters: short, often from a free mail address, sometimes in broken English. Every measure against spam has to be judged by whether that email still gets through.

What the file itself can do

security.txt cannot prevent spam, but it can set expectations before anyone writes. Three fields help.

Bug-Bounty: False

Since March 2026 the Bug-Bounty field is in the IANA registry. With False you state in machine-readable form that you do not pay rewards. Anyone filtering domains for paying targets drops you; anyone who writes anyway has nothing to point to.

A policy that says it plainly

The Policy field points to your coordinated vulnerability disclosure policy. Two sentences there take the ground from under most beg bounty emails: that there is no reward programme, and that reports without evidence of impact are not considered vulnerabilities, with examples such as missing headers or SPF and DMARC hints. BSI TR-03183-3 requires you to publish what counts as a valid vulnerability anyway (section 4.4.5). Our CVD template creates a draft with all required items.

Acknowledgments instead of money

A hall of fame page, linked from the Acknowledgments field, is an incentive without money. Serious researchers value it, and it makes clear what recognition looks like with you.

Contact: mailto:security@example.com
Contact: https://example.com/security-contact/
Policy: https://example.com/security-policy/
Acknowledgments: https://example.com/security-thanks/
Bug-Bounty: False
Expires: 2027-10-01T00:00:00.000Z

The right address and a form

A dedicated address helps more than any field. If info@ is in the file, the spam reaches everyone who reads info@, and the real report gets lost between job applications and invoices. A role mailbox such as security@, or under the TR separate psirt@ for products and csirt@ for your own IT, keeps the spam in one place where someone knows what to look for.

A reporting form with required fields for product, version, steps to reproduce and observed impact produces better reports than a free-form email. Under RFC 9116 the Contact fields are listed in order of preference, so the form may come first. If you follow the TR, list the PSIRT mailbox first (4.2.3) and ask in your policy for the form to be used where possible. The email address has to stay in either case.

Filtering without losing anything

The spam filter on the security mailbox should sort and flag, never reject or delete. A rejected sender gets a bounce, you see nothing, and reports from private addresses or new domains are exactly the ones that fall through. Order matters: first highlight anything that sounds like exploitation, only then sort out the rest.

An example in Sieve, the filter language of many mail servers (RFC 5228). Adjust folder names and keywords to your setup:

require ["fileinto", "imap4flags", "body"];

# 1. Signs of exploitation: always keep in the inbox and flag
if anyof (
    header :contains "subject" ["exploit", "in the wild", "ransom", "breach", "compromised"],
    body :text :contains ["actively exploited", "in the wild", "we were attacked"]
) {
    addflag "\\Flagged";
    stop;
}

# 2. Typical beg bounty mails into their own folder, never delete
if anyof (
    header :contains "subject" ["bug bounty", "bounty", "reward"],
    body :text :contains ["do you offer a bug bounty", "do you have a bug bounty", "eligible for a reward"]
) {
    fileinto "Security/Bounty-requests";
    stop;
}

The Security/Bounty-requests folder still gets looked at every day, just faster. An automatic acknowledgement tells harvesters the address is live; if you use one, keep it short and link to your policy. It does not replace the personal reply: under the TR every vulnerability report gets a response within 5 working days that is not automatically generated (4.4.8).

What to avoid

  • Removing the file. The spam does not stop, the address has long been harvested. All you lose is the channel for serious reports.
  • Hiding the address. As an image, obfuscated or behind a login: that defeats the purpose of the file, and manufacturers under the EU Cyber Resilience Act need an easily findable contact address from 11 December 2027.
  • Putting the file behind bot protection. A challenge such as Cloudflare Bot Fight Mode also blocks the tools of CERTs and scanning services; the TR requires that they can fetch the file automatically (4.2.11). The guide shows how to exempt it.
  • Arguing or paying "as a goodwill gesture". One friendly reply pointing to your policy is enough. Pay once and you are on the list of payers.
  • Sorting by form. Poor English, a free mail address or a missing subject line say nothing about the content.

Frequently asked questions

Will security.txt get me more spam?

Usually yes, mostly beg bounty emails and scanner output. The address becomes machine-findable, which is the point of the file. With Bug-Bounty: False, a clear policy, a dedicated address and filter rules that sort rather than delete, it stays manageable.

What is beg bounty?

An email that reports a run-of-the-mill finding as a vulnerability and asks for a reward, usually sent automatically to many companies. The term plays on bug bounty, the real reward programme, and on "to beg".

Does Bug-Bounty: False really help?

It will not stop every email, but it sets expectations before anyone writes and gives your reply something to point to. Together with a "no reward programme" sentence in your policy it is the simplest measure.

Do I have to reply to beg bounty emails?

Not under RFC 9116. If you follow BSI TR-03183-3, every vulnerability report gets a personal reply within 5 working days, weak ones included. A template pointing to your policy is enough. Advertising and phishing are not reports and get no reply.

Can I delete spam in the security mailbox automatically?

Better not. Sorting into folders yes, deleting unseen no. For manufacturers under the Cyber Resilience Act an incoming report triggers the initial assessment, and the TR requires that no report is closed by a single person.

Sources