550 5.4.1 Recipient Address Rejected: Access Denied (What It Means for Senders)

550 5.4.1 Recipient address rejected: Access denied means the recipient's domain runs on Microsoft 365, and Microsoft could not find the address in that organisation's directory, so it refused the message at the door. It is a bad-address bounce, not a block on your sending. Check the spelling, then suppress the address. If every address at one domain is bouncing this way at once, the problem is on the recipient's side and only their admin can fix it.

Senders often read it the wrong way round. "Access denied" sounds like Microsoft has banned you. It hasn't. The phrase refers to the recipient address being denied entry to that tenant, not you.

Where the bounce comes from

Microsoft's support article on 550 5.4.1 (updated 2 October 2026, read 2 November 2026) says the bounce "is generated when directory-based edge blocking in Microsoft Exchange Online blocks an incoming email message because the recipient's email address is invalid."

Directory-Based Edge Blocking (DBEB) is a Microsoft 365 setting that rejects mail for addresses that do not exist in the organisation's directory. It runs at the edge, before anti-spam and anti-malware filtering. Your message is never scored, because Microsoft never gets that far.

That ordering matters for diagnosis:

What you might suspect	Is it involved in a 5.4.1?
Your sender reputation	No. DBEB runs before filtering
SPF, DKIM or DMARC	No. Authentication failures come back as 5.7.x
Your content or links	No. The message body is never evaluated
Your sending volume	No. Throttling shows as 4.x.x deferrals
The recipient address	Yes. This is the whole test

You will often see a tag at the end, for example Access denied. AS(201806281). Microsoft does not document a separate meaning for that tag, and it appears on ordinary invalid-recipient bounces. Treat the whole line as one 5.4.1 rejection.

The three situations behind it

1. The address really does not exist

This is the common case for cold email. The person left, the address was guessed from a pattern, or a data provider had it wrong. Microsoft is telling you plainly that there is no such mailbox.

What to do: check for an obvious typo, then add the address to your suppression list. Do not retry it.

2. A typo or formatting problem

jon.smith@ instead of john.smith@, a trailing dot, an invisible character pasted from a spreadsheet. The domain is right and the mailbox is wrong.

What to do: fix it if you can tell what was intended, otherwise suppress it. The email typo corrector catches the common domain-side typos, but it cannot guess a misspelled first name.

3. The recipient's directory is out of step

Microsoft's article lists fixes that only the recipient's admin can apply. If every address at a domain triggers the bounce, they resync the accepted domain. In hybrid setups, an on-premises mailbox, public folder or dynamic distribution group may not have synced to Exchange Online. Microsoft also notes that directory changes can take up to 24 hours to reach edge blocking.

This is the case where a real person, at a real address, bounces with 5.4.1. It usually appears during a mail migration, when a company is moving onto Microsoft 365 and DBEB is switched on before every mailbox has been synced.

What to do: if you have another channel to the contact (phone, LinkedIn, a reply from a colleague), you can tell them. Otherwise pause the domain and recheck it in a few days. Do not keep sending, because every attempt is another hard bounce on your account.

How to tell which situation you are in

Look at the pattern across your bounces, not one message at a time.

1. Export your bounces with the full bounce text. Instantly, Smartlead, lemlist and most ESPs let you export bounced leads with the reason. Paste them into Bounce Doctor, which sorts each one into bad address, sender block, security gateway or temporary and builds a suppression file.
2. Group the 5.4.1s by domain. Scattered across many companies, one or two each: case 1. These are dead addresses. Suppress them.
3. Check for clusters. If most addresses at one domain bounced with 5.4.1 on the same day, including ones you had verified recently, suspect case 3. Our guide to bounces concentrated on one domain walks through that pattern.
4. Confirm the domain is on Microsoft 365. The Microsoft 365 email checker or an MX lookup shows whether the domain's mail goes to *.mail.protection.outlook.com. A 5.4.1 from a domain that is not on Microsoft usually means it has a gateway relaying to Microsoft, or the text came from somewhere else.

Does 550 5.4.1 hurt my sender reputation?

The bounce itself is not a reputation judgement. But a high rate of hard bounces of any kind is a signal that mailbox providers and your sending tool watch. Instantly and Smartlead pause campaigns on bounce rate, and Microsoft's own bulk-sender guidance expects senders to keep invalid addresses off their lists.

So 5.4.1 bounces count against you the same way 550 5.1.1 user unknown does. They are evidence of a stale or guessed list. A campaign that throws off dozens of them is telling you the list was not checked, or was checked too long ago. Our bounce rate thresholds by platform post lists where each tool draws the line.

Can verification catch it before you send?

Mostly, yes. A verifier connects to the domain's mail server and asks, at the RCPT TO stage, whether it would accept mail for the address. On a Microsoft 365 tenant with DBEB on, Microsoft runs the same directory check and gives the same answer. An address that would bounce with 5.4.1 normally comes back as invalid.

There are two limits, and they are worth knowing before you blame a verifier:

Situation	What a verifier sees	Why
DBEB on, address missing	Invalid	Microsoft refuses the recipient at RCPT TO
DBEB on, address exists	Valid	Microsoft accepts the recipient
Tenant accepts everything at the edge (DBEB off, or a gateway in front)	Catch-all (risky)	Every address is accepted at check time, so none can be confirmed
Directory changed after the check	Whatever was true on the day of the check	A mailbox removed last week bounces this week

The last row is why timing matters. B2B addresses go stale as people leave. A list verified in the spring and sent in the autumn will produce 5.4.1 bounces that were valid when checked. Re-verify close to the send. Our post on B2B contact data decay covers how fast that happens.

A simple routine for cold email

1. Verify the list within a few days of the first send. Send only to valid addresses on the first pass. Upload on the verify page, or use the CSV email verifier.
2. Handle catch-all rows separately. Microsoft 365 tenants without edge blocking come back catch-all. Send higher-likelihood ones in a smaller, slower campaign. See should you email catch-all addresses.
3. Suppress every 5.4.1 after step 1. Do not let a dead address go on to receive steps 2, 3 and 4. Our post on follow-up emails bouncing explains why later steps often bounce more.
4. Watch for clusters. Three or more 5.4.1s from one domain on one day is a reason to pause that domain, not to delete every lead at it.
5. Re-verify anything older than about a month before it goes into a new sequence.

550 5.4.1 compared with similar Microsoft bounces

Bounce	Meaning	Whose problem
550 5.4.1 Recipient address rejected: Access denied	Address not in the tenant's directory	The address (or the recipient's directory)
550 5.1.10 RESOLVER.ADR.RecipientNotFound	Recipient not found, reported after acceptance	The address
550 5.7.515 Access denied, sending domain does not meet the required authentication level	Microsoft consumer mail wants SPF, DKIM and DMARC	Your sending setup
550 5.7.606 Access denied, banned sending IP	Your sending IP is on Microsoft's block list	Your sending infrastructure
451 4.7.650 ... temporarily rate limited due to IP reputation	Temporary throttle on Microsoft consumer domains	Your sending reputation, see 451 4.7.650

Only the first two are list problems. The rest are about how you send, and verifying the list will not fix them.

Where SimpleVerifier fits, and where it doesn't

SimpleVerifier checks Microsoft 365 addresses at the RCPT TO stage like any other domain. When a tenant refuses an address, the row comes back invalid. When the tenant accepts everything, the row comes back risky and is graded by likelihood, never called valid. Microsoft's consumer domains (Outlook.com, Hotmail, Live, MSN) at times refuse checks from verifier networks altogether. Those rows come back unconfirmed rather than valid or invalid, so plan to handle them as risky.

What verification cannot do is fix a recipient's broken directory, or stop an address that was valid on Monday from being deleted on Tuesday.

The first 100 checks are free with a Google sign-in on the verify page. Monthly plans are on the pricing page.