security.txt, abuse@, postmaster@ and security@: RFC 2142 and 9116

When a researcher finds a hole in your website, a mail administrator sees spam from your domain, or a receiver wants to tell you your DKIM is broken, they look for two things: the standard role addresses defined in RFC 2142, and a security.txt file defined in RFC 9116. If neither exists, they either give up or post about it publicly. Both take twenty minutes to set up and cost nothing on a plan with spare mailboxes.

Quick answer

Create postmaster@, abuse@, and security@ on your domain and deliver them to a person who will read them. Publish a plain-text file at https://yourdomain.com/.well-known/security.txt containing at least a Contact: line and an Expires: line. Then use those same addresses in your DMARC record and at your domain registrar so all operational reports reach one inbox.

RFC 2142: the role addresses receivers expect

• postmaster@ is the one address every mail-receiving domain is expected to have; SMTP standards require servers to accept mail for it. bounce (when an email cannot be delivered and comes back) and delivery problem reports from other administrators go here.
• abuse@ receives complaints about spam, phishing, or attacks originating from your domain or servers. Blocklist operators and feedback-loop programmes often send to it automatically.
• hostmaster@ for DNS matters and webmaster@ for the website are also defined and still used by some automated systems.
• security@ is not in RFC 2142 but has become the de facto address for vulnerability reports and is what most security.txt files point to.

Setting up the addresses

1. Create them as aliases or mailboxes that deliver to a real person, such as the founder or whoever owns IT. On OquMail you can create them as mailboxes on the free plan (up to 15) or point them at an existing mailbox; either way the mail must be read.
2. Add a filter that labels mail to these addresses so it is visible, but do not auto-file it somewhere nobody looks.
3. Do not put an auto-responder on abuse@ or postmaster@ that replies to every message; automated reporters do not read replies, and a loop between two auto-responders is a classic problem.
4. Make sure they are not caught by your own spam filtering. Reports often quote the spam they are complaining about.
5. Reuse them: set rua=mailto:dmarc@yourdomain.com in your DMARC record (or route it to postmaster@), and use abuse@ or security@ as the registrant contact at your registrar rather than a personal address.

RFC 9116: the security.txt file

security.txt is a small text file that tells researchers how to report a vulnerability. It lives at /.well-known/security.txt, must be served over HTTPS as plain text, and has two required fields: Contact and Expires. A minimal file:

Contact: mailto:security@yourdomain.com
Expires: 2027-06-30T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourdomain.com/.well-known/security.txt
Policy: https://yourdomain.com/security-policy

• Contact: one or more ways to reach you; mailto:, https:, or tel: URIs are all allowed. List the most preferred first.
• Expires: a date after which the file should be considered stale. Set it a year out and put a calendar reminder to update it; an expired file is treated as unreliable.
• Optional fields: Encryption (a link to your PGP key if you accept encrypted reports), Acknowledgments (a page thanking reporters), Policy (your disclosure policy), Hiring, and Preferred-Languages.
• You may sign the file with PGP; the signature covers the content and lets researchers confirm it has not been altered.

Handling what arrives

1. Acknowledge human reports within a business day, even with a one-line reply. Researchers who hear nothing escalate publicly.
2. For a vulnerability report, ask for details, reproduce it, fix it, then tell the reporter. Do not threaten legal action for a good-faith report.
3. For an abuse report about spam from your domain, check your mail provider's delivery logs to see whether the mail actually came from you. OquMail's per-message logs show exactly what your domain sent; if the log is clean, you are being spoofed and the fix is DMARC enforcement.
4. For a blocklist notice to postmaster@, follow the delisting instructions in the notice after fixing the cause.
5. Keep a short log of reports and outcomes; it is useful evidence of responsible handling if a regulator ever asks.

Mistakes to avoid

• Creating the addresses and letting them fill unread. An unread abuse@ is worse than none, because reporters assume you saw the report.
• Serving security.txt over HTTP only, at the site root only, or as an HTML page. It must be plain text at /.well-known/ over HTTPS (a root copy is optional extra).
• Letting Expires lapse.
• Pointing Contact at a personal address that changes when someone leaves.

Common questions

We are a tiny business. Will anyone actually use these?

Yes. Automated systems send to postmaster@ and abuse@ regardless of size, and researchers scan for security.txt at scale. A working file makes you the easy, cooperative case.

Can all three addresses go to the same person?

In a small business they usually should. Separate addresses matter because different systems look for different names, not because different people must read them.

Do I need a bug bounty to publish security.txt?

No. The file says how to contact you, not what you pay. A simple line in your Policy page saying you welcome reports and will not pursue good-faith researchers is enough.