Can a business email address contain accented characters?

For a public-facing small business, prefer a simple role address that uses plain ASCII characters, such as bookings@<short-name>.au, quotes@<short-name>.au, or sales@<short-name>.au, then test the exact setup before printing or publishing it.

Why accented / non-ASCII characters are a poor public choice

RFC 5321 defines the traditional SMTP mailbox local part using ASCII characters from the atext set. RFC 6531 later introduced SMTPUTF8, which allows UTF-8 characters in email addresses, including accented letters and scripts beyond Latin. While this extension makes it technically possible to send mail to addresses containing characters like é, ü, ñ or ø, both the sending and receiving mail servers must support SMTPUTF8, and the downstream systems that capture, validate, store, and display the address must also preserve the encoding correctly.

In practice, many mail providers, website forms, booking tools, CRMs, accounting packages, email validation libraries, and imported contact lists do not reliably support SMTPUTF8 or non-ASCII characters in addresses. Some systems reject such addresses outright as invalid or malformed. Others accept them but strip diacritics, replace accented characters with ASCII approximations, mangle the encoding into mojibake, or store a corrupted version of the address that no longer matches the intended mailbox. The result is unpredictable: some customers can reach the address, some cannot, and the business often does not learn of the failure until a reply or quote never arrives.

Mail providers rarely create or recommend public business addresses that rely on accented or non-ASCII characters because the disconnect between what the standards permit in theory and what everyday customer-facing systems support in practice creates workflow friction. When customers see an address containing an accented character, they may not know how to type it on their keyboard, may paste it incorrectly and introduce corruption, may confuse it with a similar unaccented character, or may contact the business to confirm whether the character is required. The same workflow concerns that make giving an email address over the phone challenging are amplified when the address includes diacritics or characters not present on common keyboards.

Hard to say, spell, and type

Picture a business telling a customer an address that contains an accented character: café@<short-name>.au, josé@<short-name>.au, or münchen@<short-name>.au. Over the phone, the customer hears the word, but must then work out which character carries the accent, which specific diacritic is required (acute, grave, umlaut, tilde, cedilla, circumflex, ring), and how to produce that character on their keyboard. Most people are not familiar with keyboard shortcuts for diacritics, and mobile keyboard layouts vary widely in how they present accented characters.

The customer may type the unaccented version instead: cafe@..., jose@..., or munchen@.... If the mail server treats accented and unaccented local parts as distinct mailboxes, the email will bounce or go to the wrong inbox. If the customer tries to spell the character over the phone, they must explain the diacritic by name ("e with an acute accent", "u with an umlaut", "n with a tilde"), which is awkward and error-prone. Many people do not know the English names for diacritics, and some languages use different names or conventions.

On many keyboards, accented characters are hidden behind long-press menus on mobile, Alt or Option key combinations on desktop, or completely absent if the keyboard layout does not include the required script. Customers who type addresses from a business card, invoice, van sign, or website footer may replace the accented character with the nearest unaccented equivalent, skip it entirely, or insert the wrong diacritic. That variability does not mean every customer will mistype the address. It means accented characters introduce an interpretation and input choice where none would exist if the address were bookings@<short-name>.au, quotes@<short-name>.au, or sales@<short-name>.au instead.

Form validation and CRM rejection / mangling

Even though RFC 6531 and SMTPUTF8 make it technically possible to use non-ASCII characters in email addresses, the vast majority of email validation libraries, form validators, CRMs, and contact management systems either reject addresses containing accented characters as invalid or strip the diacritics and store an ASCII-only approximation that may no longer match the intended mailbox. Validation logic that checks for ASCII-only characters is widespread because it reflects the original SMTP standards and the reality that SMTPUTF8 support is not universal.

Website contact forms, CRM imports, booking systems, accounting packages, and quote generators often treat accented characters as validation failures. An address like café@<short-name>.au entered into a form may be rejected immediately with an error such as "Invalid email address" or "Please use only letters, numbers, and common punctuation". Some systems may accept the address but silently strip the accent during sanitization, turning café into cafe, which then no longer matches the intended mailbox if the mail server treats them as distinct.

Other systems may accept the address initially but mangle the encoding when the data is exported, synchronized to a CRM, or passed through an integration that does not preserve UTF-8 correctly. The accented character may be corrupted into mojibake (such as café), replaced with a question mark or placeholder character, or stripped entirely. The business may not discover the corruption until a reply to a stored address bounces, goes missing, or arrives at an unintended mailbox.

Contact lists, CRMs, email service providers, and automated systems that validate email addresses often reject or normalize addresses containing accented characters because the pattern is rare in public business addresses and because preserving the encoding correctly requires every system in the chain to support UTF-8 and SMTPUTF8. Even systems that initially accept the address may later flag or reject it when backend validation, mail server checks, or downstream integrations apply stricter ASCII-only rules.

Print and signage friction

When printed on a business card, invoice, quote PDF, van sign, or website footer, accented characters in the email address create practical friction because they are not universally easy to reproduce from visual inspection alone. At small print sizes (such as on a business card footer or invoice header), diacritics can be difficult to see clearly, easy to confuse with similar marks, or misread as printing artifacts or dust.

A customer looking at an address like café@<short-name>.au on a business card, invoice header, or van sign may not immediately recognize the accent, may assume it is optional decoration, may type the unaccented version, or may contact the business to confirm whether the character is required. The same address that is rejected or mangled by web forms becomes even more problematic when printed on physical materials that customers must transcribe by hand or by typing from memory.

Consider what happens when the address appears in different contexts:

On a business card handed to a customer at a trade show or meeting, the customer must notice the accent, remember which character carries it, and reproduce it correctly when they type the address later from the card.

On an invoice or quote PDF sent to a customer's email, the customer may copy and paste the address into a reply, but if their email client or CRM does not preserve the encoding correctly, the paste may introduce corruption or strip the accent.

On a van sign seen in passing, the customer may write down the address by hand, but if they cannot see or remember the diacritic clearly, they will guess the unaccented version or contact the business to confirm.

On a website footer or contact page, the customer may copy the address, but if they later paste it into a form that does not support UTF-8, the paste may fail validation or produce a mangled address.

The risk is not that every customer will make one of these errors. It is that accented characters introduce multiple plausible paths to failure where a simpler ASCII address like sales@<short-name>.au, bookings@<short-name>.au, or quotes@<short-name>.au would work reliably across print, screens, forms, and phone dictation.

Safer alternatives for public-facing business addresses

For a public-facing small business, the simplest and most reliable approach is to choose a role or person address that uses only plain ASCII characters. Addresses like quotes@<short-name>.au, bookings@<short-name>.au, sales@<short-name>.au, or info@<short-name>.au work across forms, CRMs, email clients, printed materials, and phone dictation without introducing validation errors, encoding corruption, or keyboard-access friction.

If the business name or a person's name contains accented characters, use the ASCII approximation or a role descriptor in the email address instead. For example, a business called "Café Martin" could use bookings@<short-name>.au or cafe@<short-name>.au rather than café@<short-name>.au. A person named José could use jose@<short-name>.au, or the business could use a role address like sales@<short-name>.au that avoids the question entirely.

If the business currently uses a longer address and is considering a shorter matched .au address as an alternative, the key advantage is that shorter addresses are easier to say, print, type, and remember, without requiring accented characters or diacritics that customers struggle to reproduce or that forms and CRMs reject or mangle. A shorter .au address can forward to the existing inbox (subject to setup and approval), so the business does not need to abandon the existing address or change the website immediately. An account manager confirms fit, availability, .au eligibility requirements, setup steps, and provider compatibility manually before anything changes.

How to test before you publish

Before printing a business email address on cards, invoices, quotes, van signs, or website footers, test the exact address through the full workflow:

Send a test email from a personal account (Gmail, Outlook, etc.) to the address and confirm that the email arrives in the intended inbox within a few minutes. Pay particular attention to whether the sending system supports SMTPUTF8 and whether the receiving system accepts the address.

Enter the address into the business website contact form (if one exists) and confirm that the form accepts the address, sends a confirmation, and that the confirmation arrives at the intended inbox. Pay particular attention to validation errors, which are highly likely with accented characters.

Import the address into a CRM or contact list (such as HubSpot, Salesforce, Mailchimp, or a spreadsheet) and confirm that the address is stored correctly without being rejected, stripped, or mangled. Export the contact list and verify that the accented character is preserved correctly after a round trip.

Create a test invoice or quote PDF containing the address and ask a colleague or friend (who was not involved in choosing the address) to type the address into their email client from the printed or on-screen PDF. Confirm that they can type it correctly without assistance, and that they do not replace the accented character with the unaccented version.

Dictate the address over the phone to a colleague or friend and ask them to write it down and type it into their email client. Confirm that they can do so without requiring spelling assistance for the diacritic, and that they do not type the unaccented version or a different accented character.

Copy and paste the address from a test document into several different systems (email clients, CRMs, web forms, spreadsheets) and confirm that the accented character is preserved correctly in each system. Watch for mojibake, stripped accents, or validation failures.

If any step reveals that the address is rejected, altered, mistyped, or misunderstood, adjust the address before printing or publishing it. Testing the exact workflow before committing to printed materials or public listings prevents costly reprints, customer confusion, and missed communications. With accented characters, the overwhelming likelihood is that validation will fail, encoding will be corrupted, or customers will type the unaccented version at multiple points in the workflow.