5.1.6 Recipient Addresses In Single-Label Domains Not Accepted | Fix Steps

5.1.6 Recipient Addresses In Single-Label Domains Not Accepted And What It Means

You’ll hit this error when an email is addressed to something like alex@contoso instead of alex@contoso.com. That “contoso” part is a single-label domain. It has no dot, so it isn’t a fully qualified domain name.

Many mail systems refuse that format during the SMTP handoff. The rejection happens before delivery, so the sender gets a non-delivery report that includes the status code and the text “recipient addresses in single-label domains not accepted.”

It often feels random because the sender thinks they typed a normal address. In reality, it usually came from auto-complete, an old contact card, a CSV import, a hidden list member, or an internal-only address someone copied from an ancient directory.

It also shows up after a routing change. A stricter gateway, a new relay, or cloud filtering can start enforcing checks that weren’t enforced on an older path. The address was still malformed. The new hop just stopped letting it slide.

Why Single-Label Domains Fail In Real Mail Flow

Email delivery needs DNS to route a message. The domain after the @ is used to find where mail should go, usually via MX records. A single word like contoso can’t be resolved the same way on public DNS as contoso.com.

Inside a company network, short domains can exist as a convenience. Active Directory and legacy mail setups sometimes used them, and people got used to typing short forms. That habit breaks the moment the address needs to travel across the public internet.

There’s also a safety angle. Malformed addresses are common in spam, malware blasts, and sloppy automation. Rejecting them early cuts noise and reduces risk of misrouting. That’s why modern mail systems often treat the dotless domain as a hard fail, not a soft warning.

If you’re seeing this while sending to “normal” recipients, it’s usually because one recipient in the send is not normal. One bad address is enough to generate a bounce, even if the rest of the message delivered to other recipients.

Fast Ways To Spot The Bad Address Before You Change Anything

Start by finding the exact recipient that triggered the bounce. Don’t guess. Copy the address from the non-delivery report into a plain text editor, then read it slowly. You’re looking for a domain that ends right after the first word.

• Copy The Failed Recipient — Paste the failed address into a note so line breaks and hidden characters are visible.
• Scan For A Missing Dot — Look right after the @ and confirm there is at least one dot in the domain.
• Check Auto-Complete — Delete the suggested entry, type the full address again, then send a one-recipient test.
• Expand Group Members — If you mailed a group, expand it and review each member for a dotless domain.
• Review Imported Lists — If a CSV or CRM export was used, search the domain column for values without a dot.

If the bounce text shows the same phrase across many recipients, don’t assume all those recipients are wrong. It can be one repeated bad contact record that keeps getting reused, or one list member that appears in multiple lists.

If the mail came from an app, check the app’s recipient field, templates, and contact mapping. Apps often store addresses once, then reuse them forever. A single wrong record can keep failing until the source data is corrected.

How To Fix 5.1.6 Recipient Addresses In Single-Label Domains Not Accepted In Microsoft 365 And Exchange

In most cases, the clean fix is simple: correct the address so the domain is fully qualified. Server-side policy changes can be appropriate in narrow internal scenarios, but they should be treated as a short-term bridge while address data gets cleaned up.

Fix The Address Where It Was Created

1. Edit The Contact Card — Open the saved contact and replace the dotless domain with the full domain, then save.
2. Replace The Auto-Complete Entry — Remove the cached suggestion and re-add the recipient using the correct address.
3. Repair Distribution Lists — Remove the bad member, add the corrected address, then test with a small send.
4. Clean CSV And CRM Records — Fix the stored email field so future exports stop reintroducing the same mistake.

When this comes from a signature or a template, fix the template and then fix the address book entry. If you only fix one, the mistake tends to come back the next time someone copies the old version.

Fix Internal Addressing So People Stop Copying Short Forms

If staff routinely copy internal-style addresses, give them a consistent internet address to copy instead. That usually means users, shared mailboxes, and groups all have addresses on a verified domain, and that address is what shows in the directory and email client.

• Set A Clear Default Address — Ensure the primary SMTP address is the one people see and copy.
• Align Directory Display Fields — Make sure the directory shows the full address, not an internal alias.
• Review Hybrid Rewrite Rules — Confirm any rewrite logic preserves the full domain during routing.

Once the visible address is always the full address, the volume of “short domain” mistakes drops fast. People copy what they see. If what they see is correct, the habit fixes itself.

Handle Exchange Receive-Connector Settings With Tight Scope

Exchange can be configured to reject single-label recipient domains at the receive connector. If you have a trusted internal app that still emits dotless recipients, you might be tempted to relax that check. If you do, keep the blast radius small.

• Use A Dedicated Internal Connector — Apply any allowance only to a connector that is not internet-facing.
• Restrict Source IPs — Allow only the specific server or app IP range that needs the behavior.
• Reduce Relay Rights — Keep permissions narrow so the connector can’t be abused as a relay path.
• Plan A Cleanup Deadline — Treat the connector change as temporary while the app and data are corrected.

Even for internal mail, it’s usually better to fix the app to send fully qualified addresses. That keeps mail behavior consistent across on-prem, cloud, and any future migration work.

A Simple Table To Diagnose The Bounce In Minutes

Use this table to separate typos from system policy. It’s also handy for delegating the first pass to a helpdesk teammate without losing accuracy.

Prevention That Keeps 5.1.6 From Returning Next Week

After you fix the immediate bounce, the next step is to stop the same bad address from getting re-saved. Most teams find the same sources again and again: shared contacts, CRM imports, templates, and old distribution lists.

• Audit Shared Contacts Monthly — Export contacts and search for domains without a dot, then correct them in bulk.
• Validate At Data Entry — Add a simple rule in forms so the domain must include a dot before saving.
• Harden List Hygiene — Require list owners to review members after imports and before large sends.
• Fix Templates And Signatures — Update any place people copy addresses, then remove older versions.
• Track Repeat Bounces — Group non-delivery reports by failed address to locate the original source record.

If you need a quick internal rule of thumb for training: a public email domain nearly always includes a dot, and the part after the @ should look like a real website domain. That simple check catches most cases before they turn into a bounce.

If you’re documenting the issue for your team, include the exact error text in your notes: 5.1.6 recipient addresses in single-label domains not accepted. Seeing it written out makes it easier for others to match the symptom and apply the same fix the next time.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback