postmaster@ and abuse@: The RFC 2142 Addresses Every Domain Must Have

If you run email on your own domain, other mail administrators, blocklist operators and hosting providers will assume two addresses exist: postmaster@ and abuse@. They are not a courtesy; postmaster@ is required by the SMTP standard itself, and abuse@ is where the complaints go that decide whether your domain stays off blocklists. This guide explains what the standards say, what actually lands in those mailboxes, and how to handle it in ten minutes a week.

Quick summary

• RFC 5321 (the SMTP standard) says every mail server must accept mail for "postmaster" at every domain it handles, matched case-insensitively. A domain that bounces postmaster@ is technically non-compliant and some receivers treat that as a spam signal.
• RFC 2142 ("Mailbox Names for Common Services, Roles and Functions", 1997) lists the conventional role addresses: postmaster@ for mail, abuse@ for reporting misuse, hostmaster@ for DNS, webmaster@ for the website, security@ for vulnerability reports, and noc@ for network operations. It also lists info@, sales@, support@ and marketing@ as business roles.
• Blocklist operators such as Spamhaus and abuse databases such as abuse.net look up abuse@ when they need to reach you. If it bounces, they escalate to your hosting provider or simply list you.
• Feedback loops from large mailbox providers send complaint reports in Abuse Reporting Format (ARF, RFC 5965); abuse@ is the default destination.
• Create postmaster@ and abuse@ on your domain. On OquMail they are free mailboxes or aliases; there is no reason to leave them bouncing to save a seat.

What the standards require

• RFC 5321 (the SMTP standard) says every mail server must accept mail for "postmaster" at every domain it handles, matched case-insensitively. A domain that bounces postmaster@ is technically non-compliant and some receivers treat that as a spam signal.
• RFC 2142 ("Mailbox Names for Common Services, Roles and Functions", 1997) lists the conventional role addresses: postmaster@ for mail, abuse@ for reporting misuse, hostmaster@ for DNS, webmaster@ for the website, security@ for vulnerability reports, and noc@ for network operations. It also lists info@, sales@, support@ and marketing@ as business roles.
• Blocklist operators such as Spamhaus and abuse databases such as abuse.net look up abuse@ when they need to reach you. If it bounces, they escalate to your hosting provider or simply list you.
• Feedback loops from large mailbox providers send complaint reports in Abuse Reporting Format (ARF, RFC 5965); abuse@ is the default destination.

What arrives at postmaster@

Mostly machine-generated mail. Delivery status notifications when your users send to addresses that do not exist, warnings from receiving servers about rate limits or authentication failures, mailing-list administrative notices, and messages from other administrators who noticed something odd about your domain. If you point your DMARC aggregate report address at postmaster (many people use dmarc@ instead, as in v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com), you will also receive daily XML reports from Google, Microsoft and Yahoo describing who sent mail as your domain and whether it passed SPF and DKIM. Those reports are the single most useful thing in the mailbox: they tell you when a forgotten tool or a spoofer is sending as you.

What arrives at abuse@

Human complaints and automated reports about mail or web content coming from your domain. Typical examples: a recipient forwarding a message they believe is spam; a phishing report from a takedown service such as Netcraft or PhishLabs about a page or a reply drop-box address hosted on your domain; a notice from your registrar or host that a complaint has been received and a response is due within 24 to 48 hours; and ARF complaint reports from feedback loops. Most small businesses receive very little here for months, then one message that matters enormously. Miss that one and the next message is your hosting account being suspended.

Set them up in five steps

1. Create postmaster@ and abuse@ on your domain. On OquMail they are free mailboxes or aliases; there is no reason to leave them bouncing to save a seat.
2. Point both at the person who administers email, and add a backup. If you use aliases, forward them into a mailbox that is actually read, not a founder's overflowing personal inbox.
3. Add hostmaster@, webmaster@ and security@ as aliases into the same mailbox. They cost nothing and a bounced security@ makes responsible researchers give up and post publicly.
4. Create a filter that flags anything with "abuse", "complaint", "phishing", "takedown" or "suspension" in the subject and sends a phone notification. Everything else can wait for the weekly review.
5. Register for Google Postmaster Tools and Microsoft SNDS with your domain so you can see reputation and complaint rates alongside what lands in abuse@. OquMail's per-message delivery logs show the other side: what the remote server said when your mail was delivered or refused.

How to respond to an abuse report

1. Reply within one business day, even if only to say you are investigating. Silence is what gets domains listed.
2. Identify the mailbox involved. Check whether it was compromised (unexpected sent mail, unfamiliar logins) or whether a teammate genuinely sent bulk mail without consent.
3. Stop the behaviour: reset the password, suspend the mailbox, remove the offending page.
4. Write back with what you found, what you changed, and what prevents a repeat. Keep it factual and short.
5. File the thread in an "Abuse - closed" folder. Providers and registrars ask about history when a second report arrives.

Mistakes that get domains blocklisted

• Creating postmaster@ as a mailbox that nobody logs into, so bounces and DMARC reports pile up unread for a year.
• Setting an auto-reply on abuse@. Automated reporters treat auto-replies as noise, and some blocklists penalise them.
• Using a catch-all address as a substitute. A catch-all accepts spam for every non-existent address and is itself a reputation risk.
• Ignoring a registrar or host notice because "we did not send any spam". Often the report is about a reply address hosted on your domain, not your outbound mail, and it still needs a response.
• Routing abuse@ to an external ticketing tool that strips the original headers, which are the evidence you need.

Common questions

Do I really need these if I only send a few emails a week?

Yes. The requirement is on the domain, not the volume. A tiny domain that bounces postmaster@ looks abandoned or fake, and a single compromised password can make a small domain send a lot of spam overnight.

Should postmaster@ and abuse@ go to the same person?

In a small company, yes. In a larger one, postmaster@ goes to whoever runs mail infrastructure and abuse@ to whoever owns trust and safety. Either way, both need a backup.

What about mailer-daemon@ and noreply@?

mailer-daemon@ is the conventional sender for bounce messages and is generated by the mail server, not a mailbox you create. noreply@ is a business choice rather than a standard, and it is covered in a separate guide on this site.