Can a business email address contain square brackets?

For a public-facing small business, prefer a simple role or person address that avoids square brackets—such as quotes@<short-name>.au or bookings@<short-name>.au—then test the exact setup before printing or publishing it.

Why square brackets do not work in practice

RFC 5321 section 4.1.2 defines the normal SMTP mailbox local part using characters that do not include [ or ]. RFC 5322 section 3.4.1 permits square brackets in the domain literal syntax for IPv6 addresses—such as user@[IPv6:2001:db8::1]—but that syntax is for technical routing contexts, not a public business address. Square brackets are not supported in the local part of a standard email address, and even in a quoted-string local part they are not accepted by most mail providers for public addresses.

Mail providers rarely create addresses containing [ or ]. Website forms, booking tools, CRMs, accounting packages and imported contact lists often reject square brackets outright, strip them, or interpret them as syntax errors. Many validation libraries treat square brackets as invalid characters in email addresses because they are reserved for domain literal syntax and IPv6 addresses, not for the mailbox identifier.

When speaking the address, the square brackets are described as "open square bracket", "close square bracket", "left square bracket", "right square bracket", or simply "bracket". Regional and technical conventions differ. Customers typically omit them, confuse them with round brackets (parentheses) or angle brackets, type the word "bracket", or assume they indicate optional or technical syntax rather than part of the address. The same workflow concerns that make giving an email address over the phone challenging are amplified when [ ] cannot be reproduced reliably from speech.

What customers hear and type

Picture a business telling a customer on a noisy call: info[main]@example. The customer hears "info open square bracket main close square bracket at example dot ..." or "info open bracket main close bracket at example dot ..." or "info bracket main bracket at example dot ...". Do they type info, infomain, info-main, info[main], info(main), or assume the square brackets indicate a note or variant rather than being part of the literal address?

Now imagine the same address on a printed invoice, quote PDF or van sign. The [ ] are visible, but they look like optional text, a technical annotation, array or index syntax from programming, or editorial clarification. When a customer retypes the address from a mobile screen or physical paper, they may drop the square brackets, replace them with hyphens or parentheses, type the words "open bracket" and "close bracket", or wonder whether the text inside the brackets is required or optional.

This variability does not mean every customer will mistype the address. It means there are several ways to interpret [ ] where none would exist if the address were info@<short-name>.au or bookings@<short-name>.au instead. Compare this to the narrower concern around hyphens, underscores and spaces in business email addresses, where the character can be seen but may still be confused, missed or rejected.

Form validation and CRM import rejection

Most email validation libraries and form validation tools reject square brackets in email addresses because they are reserved for domain literal syntax (IPv6 addresses) and are not part of the standard unquoted local-part character set defined in RFC 5321 section 4.1.2. Even lenient validation that permits special characters in quoted local parts typically excludes square brackets because of their reserved role in RFC 5322 address syntax.

Website contact forms, CRM imports, booking systems, accounting packages and quote generators often validate or normalise email addresses before storing them. Square brackets may be rejected outright with an error message like "Invalid email address", stripped silently (turning info[main]@example into infomain@example or info@example), replaced with hyphens or parentheses, or URL-encoded as %5B and %5D, depending on how the form processes the input.

The business may not see the alteration until a reply to a stored address bounces or goes missing. A customer who enters info[main]@example into a website form may receive a confirmation message sent to info-main@example, infomain@example, info(main)@example or info%5Bmain%5D@example, depending on how the form processed the input.

CSV imports into CRMs, accounting tools and mailing list platforms often reject rows containing addresses with square brackets, or silently drop the brackets during import. This means contact lists exported from one system and imported into another may lose or alter addresses containing [ ] without any visible error.

Phone and spoken ambiguity

When spoken aloud, [ can be called "open square bracket", "left square bracket", "open bracket", or "opening bracket". The ] can be called "close square bracket", "right square bracket", "close bracket", or "closing bracket". Regional and technical conventions differ. In Australia, "bracket" without "square" often refers to round brackets (parentheses), so "square bracket" is clearer but longer to say.

A customer hearing "info open square bracket main close square bracket" may type info, info-main, infomain, info[main], info(main), or assume "main" is a clarification about which info address to use rather than part of the literal address. A customer hearing "info open bracket main close bracket" may not know whether "bracket" refers to square brackets [ ], round brackets ( ), or angle brackets < >.

A customer hearing "info bracket main bracket" without the word "square" may type info(main), info[main], info<main>, info-main, or omit the brackets entirely and type infomain or info. This ambiguity between bracket types is shared with parentheses and creates multiple points of confusion when speaking or transcribing the address.

This spoken ambiguity does not exist for a simple address like info@<short-name>.au or bookings@<short-name>.au. For the wider phone workflow, see this guide to giving an email address over the phone without spelling.

Print and signage: looks like optional text or array syntax

When printed on a business card, invoice, quote PDF, van sign, or website footer, square brackets in the email address create visual confusion. To most readers, [ ] signals optional information, editorial clarification, array or list syntax from programming, or technical annotation—not literal characters that must be included in the address.

Customers seeing info[main]@<short-name>.au on printed material may assume the address can be typed as info@<short-name>.au, with [main] being an optional clarification indicating it is the main info address. Readers familiar with programming or technical documentation may also interpret the brackets as array index syntax, placeholder syntax, or a template variable that should be replaced with actual text.

Compare this to a simple address like info@<short-name>.au or bookings@<short-name>.au, which reads clearly and unambiguously on any printed surface. The goal is not to prove that an address can be technically created or quoted, but to choose an address customers can use without hesitation or guesswork.

Confusion with parentheses and angle brackets

In spoken and written contexts, "bracket" without qualification can refer to square brackets [ ], round brackets ( ) (parentheses), or angle brackets < >. When a customer hears "info bracket main bracket" or sees handwritten notes mentioning brackets, they may not know which type is intended.

Square brackets [ ] are used for IPv6 addresses, array indexing in programming, optional parameters in documentation, and editorial clarifications. Round brackets ( ) are used for optional text, alternatives, clarifications and grouping in general writing. Angle brackets < > are used in email headers to delimit the address from the display name: Business Name <info@example>. None of these are practical in a public business email address, but the ambiguity between them adds another layer of confusion when speaking or transcribing an address containing any bracket character.

A customer who hears an address with "brackets" may type the wrong bracket type, omit them, replace them with hyphens, or assume the business meant to use a display name format like Business Name <info@<short-name>.au> rather than including brackets in the address itself. For the same concerns around parentheses, see can a business email address contain parentheses.

Trading name and email address are different

A business that trades under a name containing square brackets—such as "Tech [AU]" or "Events [Sydney]"—does not need to reproduce the square brackets in the email address. The trading name remains on the letterhead, website, business card, invoice PDF, quote footer and email display name. The email address is only the technical routing identifier.

Use a simpler role address—such as events@<short-name>.au or bookings@<short-name>.au—or a person address—such as chris@<short-name>.au—that drops the square brackets. The email display name can still show the full trading name with square brackets: Tech [AU] <info@<short-name>.au> or Chris Lee — Events [Sydney] <chris@<short-name>.au>.

This separation keeps the public contact workflow simple without removing the business identity. For the wider naming choice, see this guide to professional email address formats for small business. For display name guidance, see what your business email display name should be.

Prefer a simple role or name address

For a public customer-facing business, use a simple role address (such as quotes@<short-name>.au or bookings@<short-name>.au) or a person address (such as chris@<short-name>.au) without square brackets, parentheses, spaces, quote marks or other special characters.

A role address does not create a shared mailbox or give several people access by itself. The routing rule, destination mailbox, staff login, shared access and storage policy are separate parts of the setup. The public address is only the visible entry point.

When choosing the format, prioritise what customers can hear, say and type consistently. Read the separate guide to common mistakes customers make when entering email addresses for the wider picture.

Run a harmless test before publishing

Before printing, publishing or giving out a public business address:

1. Confirm that the provider can create or route the exact address without square brackets, quote marks or other special syntax.
2. Send harmless fictional content from an unrelated inbox and confirm that it reaches the intended destination.
3. Enter the address into the real website, quote, booking, CRM and accounting workflows the business uses.
4. Copy it from a PDF and a mobile screen. Check that the format remains visible and unchanged.
5. Have someone who is not already familiar with the address hear it over a call and write down what they heard. Compare their version to the original.
6. Test the address in any form validation, CRM import, contact list and quote generation workflows the business relies on. Pay special attention to how square brackets are handled by validation libraries and CSV imports.
7. Record who owns the public address, routing rule and mailbox access. Set a retest trigger for any provider or configuration change.

This test proves only the exact route, provider and configuration tested at that time. It does not guarantee delivery or inbox placement.

The public address is only 1 layer. A square-brackets-free address does not create a routing rule, mailbox, login, shared access, storage policy or permission to send from that address. Confirm mailbox access, storage, display name and reply-from behaviour separately.

Where Short Mail may fit

If your current public address is awkward to say, print or type—or if your trading name includes square brackets and you want a clearer public email identifier—a Short Mail account manager can check whether a shorter matched .au address may fit and forward to the inbox you already use. Fit, availability, .au eligibility, setup requirements and provider compatibility are confirmed manually before anything changes.

The public address, routing, mailbox, access and storage remain separate parts of the setup. Sending permission and the From and Reply-To details customers see also require separate checks for your business.