Contact email: which address to publish, and where

One contact email per job, not one for everything#

A contact email is the address you publish so that people outside your organisation can reach you: customers, buyers, journalists, security researchers, the registrar that holds your domain. The common mistake is to publish one address, usually a founder’s own, and send every kind of message to it. It works until that person goes on holiday, leaves, or simply misses a refund request under forty newsletters.

The better pattern is one address per job. Each address names what it is for, so the person writing picks the right one and the person reading knows what is waiting for them. Each lands in a mailbox that a named team answers, so nothing depends on one inbox. And because the address belongs to the job rather than to a person, it survives staff changes: the people behind support@ change, the address on your website does not.

The format itself is fixed by the standard for message headers: a local part, the @, and a domain, and the plain “dot-atom” form (letters, digits and a few symbols, with single dots between them) should be used whenever it can be.^[1] The local part can be at most 64 octets long.^[2] In practice, a short lowercase word is the whole design brief.

The role addresses, and where each one comes from#

Some role addresses are conventions; a few are written into Internet standards. RFC 2142, published in 1997 and still current, lists the mailbox names organisations should support “for which the associated function exists within the organization”, and adds that if a service is offered, “the associated mailbox name(es) must be supported”.^[3] The table separates what a standard names from what is only common practice.

The two you cannot skip if you run mail#

postmaster@ is the strictest: any system with a mail server that accepts or relays mail “MUST support the reserved mailbox ‘postmaster’ as a case-insensitive local name”.^[2] RFC 2142 adds that the servers accepting mail for a domain must accept these names for that domain even if they do not run the service themselves, and that only the organisation’s top-level domain is required for names like abuse@.^[3] So when you move your mail to a hosted mailbox, create postmaster@ and abuse@ as aliases into a mailbox someone reads.

Case is the one detail that trips people up. The SMTP standard says the local part “MUST BE treated as case sensitive” by servers in general, while also saying that exploiting this “impedes interoperability and is discouraged”.^[2] RFC 2142 requires its role names to be recognised in any case.^[3] Publish every address in lowercase and make sure your mailbox treats Support@ and support@ as the same address.

hello@ or info@?#

Unproven Nobody has published a study showing that one of these gets more replies, more sales or less spam than the other, so treat any claim that it does as opinion. What the record does show is what each name was for. RFC 2142 files info@ under marketing, for “packaged information about the organization, products, and/or services”, and notes that it “is often tied to an autoresponder”.^[3] hello@ and contact@ appear in no standard; they are a newer habit that reads as an invitation to write to a person.

Pick one general address for people, publish only that one, and make the others aliases that land in the same place. If you choose hello@, keep info@ working anyway: people guess it, and a guess that bounces is a lost message. The general address should also say who answers it and roughly when, which matters more than its spelling.

Where to publish each address#

Put each address where the people who need it already look. Most of these places ask for an address by rule, not by taste.

• Your website’s footer and contact page. The general address and support@, as text a visitor can read and copy. In the UK, a business providing an online service (an “information society service”) must make available, “easily, directly and permanently”, details including an email address that make it possible to contact them “rapidly” and “in a direct and effective manner”.^[4]
• Your app store listings. Apple’s review guidelines say: “Make sure your app and its Support URL include an easy way to contact you.”^[5] Google’s Play Console asks for “an email address that Play Store users can use to contact you about this application” when you create the app.^[6] Use the support address in both, not a developer’s own.
• A security.txt file. RFC 9116 defines a plain text file at /.well-known/security.txt whose required Contact field tells researchers how to report a vulnerability, and says security addresses should follow RFC 2142’s naming, which means security@.^[7]
• Your domain registrar. ICANN requires registrants to give accurate contact information, keep it current and respond to their registrar within fifteen days.^[8] The registration data published for your domain usually hides that address: where it is redacted, the registrar publishes an address or a web form that “MUST NOT identify the contact email address”.^[9] Use an address a team reads, so a renewal or transfer message does not go to someone who has left.
• Your email footers. In the United States, CAN-SPAM requires a valid postal address in commercial email and a working way to opt out, such as “a return email address or another easy Internet-based way”, but it does not require a contact address as such.^[10] A footer that names where to reply saves readers from answering a no-reply address.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

The Expires field is required too, and RFC 9116 recommends a date less than a year ahead so the file does not go stale.^[7]

Route every address into a shared mailbox#

An address published to the world should never be the private inbox of one person. Route each role address into a shared mailbox that the people doing that job can all open, and give each mailbox an owner who makes sure nothing sits unanswered.

1. Point your domain’s mail at a mailbox host. Receiving mail on your domain needs an MX record; RFC 2142 makes the same point for role names on hosts that do not take mail directly.^[3]
2. Make the extra names aliases. info@, contact@ and hello@ can all land in one general mailbox; billing@ can land with support if the same people answer both.
3. Reply as the shared address. Replies go to the Reply-To address when there is one, and otherwise to the From address.^[1] Answer from a personal address and the customer’s next message goes to that person, outside the shared mailbox.
4. Agree a response time and say it. A target the team actually meets, written on the contact page, sets expectations better than any auto-reply.

If your product also receives mail programmatically, such as replies to receipts or messages to a ticketing address, the same domain can do both: see how to receive email with a webhook.

Auto-replies that do not start a loop#

An automatic acknowledgement on a role address is usually helpful, RFC 2142 says, with a caution against “duelling mail robots” and the mail loops they cause.^[3] RFC 3834 sets out how to avoid them.^[11]

• Mark every auto-reply with Auto-Submitted: auto-replied, and never answer a message whose Auto-Submitted header has any value other than no.^[11]
• Send the same notice to the same sender at most once in several days; RFC 3834 recommends a seven-day default.^[11]
• Send it to the message’s Return-Path, and never to an empty one.^[11]
• Say in the subject that it is automatic; the prefix Auto: may be used.^[11]

From:           Example Support <support@example.com>
Subject:        Auto: Re: Order 4471 has not arrived
Auto-Submitted: auto-replied

Thanks, we have your message. A person on the support team
replies within one working day, Monday to Friday.

Many questions are answered at https://example.com/help

What the reply says is editorial judgement: when a person will answer, where the help pages are, and nothing that promises more than the team delivers. Keep it short, because it is the first thing your company says to someone who already has a problem.

Protect it from spam without hiding it#

Publishing a well-known address does attract junk. RFC 2142 said so in 1997: flooding a mailbox becomes easier when more systems use the same names.^[3] The answer is filtering, not hiding.

• Unproven Obfuscation is not a reliable shield. Writing support [at] example [dot] com, or showing the address as an image, is common advice, but we found no independent study showing how much it stops, and it breaks copying, mailto: links and screen readers for real people.
• Never publish a person’s own address. A role address can be filtered harder, moved, or retired; a person’s address follows them everywhere.
• Use an alias per place. A separate alias for the app store listing, or for a directory you are listed in, shows where unwanted mail comes from and can be closed without touching the main address.
• Filter at the mailbox. A shared mailbox with a spam folder and rules by sender and content does more than any trick on the web page.

When a contact form is the better choice#

A form earns its place when you need structured information before you can help: an order number, an account, a product, a category that routes the message to the right team. It also gives you a place to add abuse protection before a message reaches anyone.

It is the worse choice when someone wants a record of what they sent, wants to attach a file the form does not accept, or cannot use it at all because a script failed to load. The safest pattern is both: a form for the common cases and a plain address beside it for everything else. Where a law asks for an email address, as the UK rule above does, a form on its own may not be enough.^[4]

Step by step: set up your contact emails#

The order matters: decide the jobs first, then the addresses, then where they appear.

1. 1

   List the jobs people write to you about

   General questions, support, billing, sales, security reports, press. Each job that really exists in your organisation gets an address; a job that does not exist gets none.

2. 2

   Create one address per job on your own domain

   Use short lowercase role names such as hello@, support@ and security@, following RFC 2142 where it names one. If you receive mail on the domain, also create postmaster@ and abuse@.

3. 3

   Route every address into a shared mailbox

   Point the role addresses at shared mailboxes the right people can all open, make the extra spellings aliases, and give each mailbox an owner who makes sure nothing goes unanswered.

4. 4

   Publish each address where its readers look

   The general and support addresses on your website's footer and contact page, the support address in your app store listings, security@ in a security.txt file, and a team address at your registrar.

5. 5

   Add an auto-reply that cannot loop

   Mark it Auto-Submitted: auto-replied, never answer automatic mail, send it to the Return-Path, and send the same sender the same notice at most once in several days.

6. 6

   Protect it with filtering, not hiding

   Publish the address as plain text, filter spam at the mailbox, use a separate alias for each directory or listing, and never publish a person's own address.

Create it on your own domain#

A contact email on your own domain is the one address you control whatever happens to your mail provider, and the only kind that matches the website people found it on. Before it can receive anything, the domain has to be connected and its records checked; see how email domain verification works.

In Rasket Inbox, a shared mailbox is one your whole team opens, or one you restrict to the members you choose. Every mailbox takes extra addresses that land in the same place, so hello@, info@ and contact@ can be one mailbox. Anyone on the team can reply, from the shared address or from their own; rules label, star or archive new mail by who sent it and what it says; and spam lands in its own folder. You can connect the domain with Cloudflare in one click or paste a few records at any other DNS host. The receiving docs cover the records.