Reporting a security issue

Email security@spf.guru. You will get a reply. This page says what is worth reporting, what is not, and what happens next, so that nobody spends an afternoon on something that was never going to go anywhere.

In scope

Anything on https://spf.guru and the DNS names this service answers on:

• Anything that lets one visitor see another visitor's query or result.
• Anything that makes the site return a record that did not come from the domain's own DNS, since people publish what this site hands them.
• Injection of any kind: into a rendered page, into a DNS query, or into the generated record itself.
• Access to the host, the container, or the DNS resolvers behind it.
• A way to make the evaluator loop, exhaust memory, or amplify traffic at a third party. It reads DNS on request, so amplification is worth thinking about and worth telling us about.
• Anything that defeats the rate limiting badly enough to be usable against someone else's nameservers.

Not in scope

Not because these are unwelcome, but because they are already known, already decided, or not this site's to fix:

• Missing security headers beyond the ones already set. The policy is deliberately strict; if you have found a way around it, that is in scope and interesting.
• The absence of DNSSEC validation in what we report. The tool shows what a receiving server sees, and most do not validate either.
• Wrong answers caused by someone else's resolver. Public resolvers occasionally return incomplete records; that is worth telling us about, but as a bug report rather than a vulnerability.
• Rate limits being reachable at all. They are meant to be. Being able to spend your own budget is the design.
• Reports from an automated scanner with no working example. A scanner's opinion that a header is missing is not a finding.
• Anything requiring you to already control the domain being checked, or to have access to the machine.

What to send

Enough to reproduce it. A URL, the input, what you expected, what happened. If it needs a specific domain or a specific sending address, say which. Video is rarely necessary; the exact request usually is.

What happens next

• You will get an acknowledgement, from a person, within a few days.
• If it is valid you will be told what the fix is and when it ships. The code is small and deploys quickly, so that is usually days rather than months.
• If it is not, you will be told why rather than ignored.
• Please give it a reasonable window before publishing. There is no fixed number here because it depends on the finding; ask and we will agree one.

Testing against the live site

Reasonable testing is fine and needs no permission. Automated scanning at volume is not: it costs real DNS queries against other people's nameservers, which is unfair to them rather than to us. If you need to run something heavy, say so first and we will work out how.

Never test with a domain you do not control if the test involves anything other than reading its public DNS.

This is a free, best-effort service. The disclaimer covers what that means for relying on it.