What this RFC defines
RFC 2142 defines a set of standard mailbox names that every internet-connected domain should maintain for common services, administrative functions, and support roles. The most important for email operators are postmaster@ (required by RFC 5321 for any domain accepting mail) and abuse@ (for spam and policy complaints).
Where you see it in practice
When a receiving MTA rejects your mail and includes “contact postmaster@yourdomain.com” in the bounce message, the postmaster@ address is defined as a mandatory mailbox by this RFC. When Spamhaus or a blocklist operator asks you to contact abuse@yourdomain.com for a delisting request, that address convention comes from RFC 2142. Domains that do not maintain postmaster@ and abuse@ risk failed complaint handling and slower blocklist removal.
How it connects to other RFCs
RFC 2142 is referenced directly by RFC 5321, which requires every domain that accepts mail to maintain a valid postmaster@ address. The abuse@ mailbox feeds into complaint handling systems like FBLs (Feedback Loops) that use the ARF format defined in RFC 5965. These mailboxes are also what blocklist operators and postmaster tools use to reach domain administrators.
Current status
RFC 2142 is a current standard, published May 1997. The mailbox names it defines remain in wide use and are referenced by major mail operators and blocklist policies. postmaster@ is a hard requirement of RFC 5321, making RFC 2142 compliance mandatory for any domain that accepts email.
Reserved role addresses
RFC 2142 defined a list of mailbox names that every organization should provide for common services and roles: postmaster (mail issues), abuse (spam/policy issues), noc (network operations), security (security incidents), webmaster, hostmaster, info, sales, marketing, and several others. These reserved names let outside parties reach an organization about specific concerns without needing to know an internal employee name. The postmaster address in particular is required by RFC 5321 for any domain that sends or receives mail.
Why abuse@ matters most
The abuse@ mailbox is the single most important role address for mail operators. Spam sources are reported to abuse@ of the sending domain, ISPs escalate policy violations there, and reputation services like Spamhaus and Abusix check whether abuse@ is monitored when evaluating a domain reputation. A domain without a working abuse@ address is treated as unresponsive by the mail community and often listed on reputation blocklists. Every mail-sending organization should have abuse@ configured, monitored, and responsive.
Practical setup
Configuring RFC 2142 addresses is straightforward: create aliases that forward to the appropriate team distribution list. The mechanics of that list, and when a shared mailbox beats an alias, are set out in the group email address guide. Postmaster typically forwards to mail operations; abuse to security and mail operations; security to the security team; sales, marketing, info to the appropriate business units. Monitoring should include reasonable response SLAs (24 hours for abuse and security, 48-72 hours for others). Automated bounce processing should suppress mail to these addresses from unrelated sources but must not silently discard genuine reports.
RFC 2142 (May 1997) defines role-based mailbox names that every well-run domain should accept: postmaster, abuse, hostmaster, webmaster, and others. Users, receivers, and abuse-response services can rely on these addresses reaching a responsible party. Foundation for abuse reporting, deliverability escalation, and DNS/hosting contact. postmaster is universally mandatory per RFC 5321; abuse is critical for reputation management; others are per-role.
RFC 2142 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Reserve standard role-based mailbox names for common contact roles |
| Universal requirement | postmaster@domain per RFC 5321 |
| Anti-abuse critical | abuse@domain per RFC 2142 |
| Response expectations | Postmaster and abuse: 24h response goal; others 48-72h |
| Published | May 1997 |
Role-based mailbox names by category
| Category | Address | Purpose |
|---|---|---|
| Universal service | postmaster@ | Mail-related contact (RFC 5321 mandatory) |
| Anti-abuse | abuse@ | Report spam, phishing, malicious behavior |
| DNS | hostmaster@ | DNS operations contact |
| Web | webmaster@ | Website-related issues |
| Security | security@ | Security incidents, vulnerabilities |
| News | usenet@, news@ | Usenet news administration (largely legacy) |
| File service | ftp@ | FTP server contact (largely legacy) |
| Web feedback | www@ | Website feedback |
| Sales / Info | sales@, info@ | General inquiries (contextual per business) |
| Support | support@, help@ | Customer support |
| Marketing | marketing@ | Marketing communication |
Common role-address mistakes
Related standards and further reading
- RFC 5321 SMTP Guide: postmaster requirement
Frequently asked questions
Which role addresses are strictly required?
postmaster@ per RFC 5321 for any mail-accepting domain. abuse@ per RFC 2142 for domains that send mail (so recipients have a place to complain). Others are contextual: hostmaster@ if you manage DNS, security@ if you have security operations, webmaster@ if you host a website. Universal advice: implement postmaster@ and abuse@ regardless.
Should I publish abuse@ on my website?
Yes, for domains sending mail. Users need a clear reporting channel. Publish on your contact page, terms of service, and abuse reporting docs. Automated abuse-detection services (Spamhaus, Google Postmaster, Microsoft SNDS) may check for a functioning abuse@ before actioning your reputation; visible on WHOIS or IANA registries also helps.
How quickly should I respond to abuse reports?
Within 24 hours per common practice. Faster is better for genuine reports (compromised accounts, phishing campaigns) where every hour matters. Automated triage (recognize the report format, extract identifiers, take action) speeds response. For high-volume senders, dedicated abuse-response teams are standard.
Can I forward all role addresses to one inbox?
Yes; common pattern. Aliases postmaster@, abuse@, hostmaster@, security@ all forward to a monitored inbox (either shared, or with tagging to distinguish). Ensure the aggregate volume is manageable; if abuse@ receives thousands of complaints daily, it needs its own dedicated team, not a shared inbox with other roles.
Are role addresses subject to unsubscribe rules?
Not per traditional mail conventions. postmaster@, abuse@, hostmaster@ are for administrative and abuse-related contact; they should always accept mail. Marketing lists should never automatically add role addresses. If someone sends unsolicited marketing to abuse@, that itself may be reportable behavior.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
