Free · 8 checks
Email Spoofing Checker
Can someone send email pretending to be you? Check your domain's SPF, DKIM and DMARC records, with a plain-English verdict, a score out of 100 and a fix for every gap.
Free tool · security.txt Generator and Checker
Make it easy to report a security flaw.
If someone finds a security problem on your website, would they know who to tell? A security.txt file answers that in a standard place every researcher checks. Create one in two minutes, check the file you already have, and get a disclosure policy to go with it.
The generator
Create your security.txt.
Fill in a contact and the file is ready. Everything else is optional. The preview updates as you type.
The checker
Check the file you already have.
Open your file in a browser, copy everything and paste it below. We'll check it against the standard and tell you what to fix.
Your result
Your security.txt check
Check by check
Fixes first, then improvements, then passes.
Want us to check it's live and working?
Send us your website and we'll check your security.txt loads in the right place, in the right format, on your main domain and subdomains, and reply personally with anything to change. Free, with no obligation.
This tool creates and checks a text file. It isn't a security audit, and GMK Digital doesn't handle vulnerability reports for other businesses.
The guide
What is security.txt?
security.txt is a small plain text file that tells people who find a security problem on your website how to report it. It lives at yourdomain.com/.well-known/security.txt, a standard address that researchers and their tools check first.
Without one, someone who spots a flaw has to guess: a general enquiries form, a social media account, or nobody at all. Reports get lost, or end up posted publicly before you've had a chance to fix anything. Two required lines, a contact and an expiry date, solve that.
Here's a minimal file:
Contact: mailto:security@example.co.uk
Expires: 2027-05-01T00:00:00ZWhy it matters
- security.txt is defined in RFC 9116, published by the IETF in April 2022. Contact and Expires are the only required fields.
- The NCSC's Vulnerability Disclosure Toolkit recommends publishing security.txt on all your domains and subdomains, alongside a disclosure policy.
- The IANA security.txt fields registry now lists 10 fields, including CSAF and Bug-Bounty, which were added after the RFC.
You can see a real example in the NCSC's own file at ncsc.gov.uk/.well-known/security.txt.
security.txt fields explained
Each line is a field name, a colon and a value. Lines starting with # are comments.
| Field | Required | Can repeat | What it's for |
|---|---|---|---|
Contact | Yes | Yes | Where to send reports: an email address (mailto:), a web form (https://) or a phone number (tel:). List them in order of preference. |
Expires | Yes | No | The date and time after which the file should be treated as out of date. Keep it less than a year ahead. |
Policy | No | Yes | A link to your vulnerability disclosure policy: what finders should and shouldn't do, and what happens after they report. |
Encryption | No | Yes | A link to a public key finders can use to encrypt their report. Link to the key rather than pasting it in. |
Acknowledgments | No | Yes | A link to a page thanking people who have reported issues. |
Preferred-Languages | No | No | The languages you'd like reports in, such as en. English is assumed if it's missing. |
Canonical | No | Yes | The address where this file officially lives. Finders should be wary of a file found anywhere else. |
Hiring | No | Yes | A link to security job openings. |
CSAF | No | Yes | A link to machine-readable security advisories in the Common Security Advisory Framework format. Mostly for software and hardware makers. |
Bug-Bounty | No | No | True if you may pay rewards for reports, or False if you don't. |
Every web link in the file must start with https://. The Expires date uses a full date and time, such as 2027-05-01T00:00:00Z, where the Z means UTC.
How to add security.txt to your website
- Create the file with the generator above and download it. It must be called
security.txt. - Make a folder called
.well-knownin your website's root folder, the one that holds your homepage (oftenpublic_htmlon shared hosting). Your file manager may hide folders that start with a dot, so look for a setting to show hidden files. - Upload the file into that folder.
- Open it in your browser at https://yourdomain.com/.well-known/security.txt. You should see plain text, not a web page or a download prompt.
- Check it by pasting it into the checker above, and add a calendar reminder a month before the expiry date.
If you use a website builder that doesn't let you upload files to .well-known, ask its support team how to publish one, or ask your web developer. Repeat for each subdomain that runs its own site.
What the checker looks for
-
Contact field
Whether the file has at least one Contact line, and whether each one is written as a proper link:
mailto:for email,tel:for phone andhttps://for a web form.How to fix: Add
Contact: mailto:security@yourdomain.com, using an inbox someone checks. Putmailto:in front of email addresses. -
Expiry date
Whether the file has exactly one Expires line in the standard's date format, whether that date has passed, and whether it's less than a year away.
How to fix: Set
Expires:to a date less than a year ahead, written like2027-05-01T00:00:00Z, and put a reminder in your calendar to update it. -
Secure links
Whether every web link in the file uses
https://. The standard requires it, so finders know the pages haven't been tampered with on the way.How to fix: Change any
http://links tohttps://, and make sure the pages they point to load securely. -
Policy link
Whether the file links to a vulnerability disclosure policy that tells finders what they can test, how to report and what you'll do next.
How to fix: Publish a short disclosure policy on your site, such as the template on this page, and add
Policy:with its address. -
File format
Whether every line is a recognised field or a comment, fields that may only appear once do, and the file is plain text rather than a web page.
How to fix: Write one field per line as
Field: value, start comments with#, check field names for typos and make sure your server sends the file as plain text. -
Signature
Whether the file carries a digital signature, which lets finders confirm it came from you. Signing is recommended but optional, and needs a Canonical line to confirm the file's address.
How to fix: If you sign the file, add
Canonical:with the file's full address before signing. If you don't manage encryption keys already, it's fine to leave the file unsigned.
How to read your result
- Fix first
Needs fixing
Something in the file stops it doing its job: a missing contact, an expired date or an insecure link. Fix the items marked Fix, then check again.
- Improve
Valid, could be better
The file has what it needs, but a few changes would make it more useful or more reliable for the people reading it.
- All good
Looks good
The file follows the standard. Keep the expiry date current and check the contact inbox regularly.
Free vulnerability disclosure policy template
The Policy field should point to a page that tells finders how to report, what they shouldn't do, and what you'll do in return. This template covers the basics for a small or medium-sized business. Add your company name below; the email and website come from the generator. Then publish it as a page on your site and add its address to your security.txt. It's a starting point, not legal advice.
Vulnerability disclosure policy for Your company
1. Introduction
Your company wants to keep its website and systems secure. If you think you've found a security problem with your website, we'd like to hear about it, and we'll work with you to fix it.
2. How to report a problem
Email your security email address with:
- the address or part of the website affected
- a description of the problem and the steps to reproduce it
- what you think someone could do with it
- how we can contact you, if you'd like a reply
Please don't include personal data you may have seen, beyond what's needed to show the problem.
3. What you can expect from us
We'll acknowledge your report within five working days, keep you updated while we look into it, and tell you when it's fixed. If we decide it isn't a problem, we'll explain why.
4. What we ask of you
- Only access, change or delete data where it's needed to show the problem, and stop as soon as you've confirmed it.
- Don't attempt to disrupt our services, for example with denial of service attacks or heavy automated scanning.
- Don't use social engineering, phishing or physical attacks against our staff, customers or premises.
- Give us reasonable time to fix the problem before you share it with anyone else.
5. Our commitment
If you report a problem in good faith and follow this policy, we won't take legal action against you for doing so.
6. Rewards
We don't run a paid bug bounty programme, but we're grateful for every report and will thank you publicly if you'd like us to.
7. Scope
This policy covers your website and its subdomains. It doesn't cover services run by other companies that we use, such as our hosting or email provider. Please report problems with those to the company concerned.
Before you publish
A security.txt only helps if someone reads the inbox it points to. Agree who checks it, how quickly, and who they pass a report to, such as your web developer or hosting provider. While you're looking at your domain, the Email Spoofing Checker and Domain Hijack Checker cover two other common gaps.
Frequently asked questions
What is a security.txt file?
A short plain text file at yourdomain.com/.well-known/security.txt that tells people who find a security problem on your website how to report it to you. It's defined in RFC 9116, published by the IETF in April 2022.
Is security.txt a legal requirement?
Not for most businesses. It's a published standard and good practice, and the NCSC recommends it in its Vulnerability Disclosure Toolkit. Without one, someone who finds a problem may not know who to tell, or may give up.
Where should the file go?
In a folder called .well-known at the root of your website, so it loads at https://yourdomain.com/.well-known/security.txt. It must be served over HTTPS as plain text. You can also put a copy, or a redirect, at /security.txt for older tools. Each subdomain that runs its own site should have its own file.
What email address should I use?
One that reaches someone who can act on a report, and that's checked even when people are on holiday. A shared address such as security@yourdomain.com works well, because it doesn't change when staff do. Don't use a personal inbox.
How often should I update it?
Before the Expires date, and whenever your contact details change. The standard recommends an expiry date less than a year ahead, so the file gets checked at least once a year.
Does it make my site a target?
No. It doesn't reveal anything about your systems. It only tells people who have already found something where to send it, so the report reaches you instead of being posted publicly or ignored.
Do I need to pay a bug bounty?
No. Most businesses don't. If you want to say so, the generator can add Bug-Bounty: False, and the disclosure policy template makes clear there are no payments.
Do I need to sign the file?
No. Signing is recommended in the standard but optional. It needs an OpenPGP key that you manage and keep up to date, which most small businesses don't have. An unsigned file with a working contact is far more useful than no file.
Is anything I enter stored?
No. The file is generated and checked in your browser. Nothing you type or paste is sent or saved unless you send us the form.
Keep going
Related free tools.
Free · 8 checks
Domain Hijack Checker
Could someone hijack your domain? Check its registrar locks, renewal date, DNSSEC, CAA record and forgotten subdomains, with a score out of 100 and a fix for every gap.
Free · 18 AI bots
AI robots.txt and llms.txt Generator
Decide which AI bots can read your site. Build robots.txt rules for 18 verified AI crawlers, check your current file and create an llms.txt.