Can I fix 550 5.4.1 from my side?

Only if the address was mistyped. The rejection is made by the receiving Microsoft 365 tenant from its own directory, so a correct address that still bounces has to be fixed by the admin on that side. What you can do is confirm the scope, confirm where the domain’s mail is hosted, and show that your own authentication is clean.

Does 550 5.4.1 mean I am blocked or blocklisted?

No. Directory-based edge blocking rejects the message because the recipient address is not valid in that organisation, before any spam filtering runs. A reputation or authentication problem shows up as a different code, usually in the 5.7.x family. The address, not the sender, is what this bounce is about.

Why does internal mail work while outside senders get the bounce?

Mail between accounts inside the same tenant never passes the service perimeter where the recipient check happens. That is why a migration can look finished from the inside while customers and suppliers keep receiving 5.4.1 for aliases, shared mailboxes or groups that were never recreated. Always test from an outside account.

550 5.4.1 recipient address rejected: cause and fix

Say a 14-person logistics broker emails a new client at a company that runs Microsoft 365. The address came straight off a business card. A reply arrives in under ten seconds, and it is not from the client:

550 5.4.1 Recipient address rejected: Access denied. AS(201806281)

"Access denied" reads like a permissions problem, so the first instinct is to blame a spam filter, a blocklist or a firewall, and to start rewriting SPF records. We get called in at exactly that point more often than we would like. This bounce has nothing to do with your authentication or your reputation. It is the receiving side saying it has no such recipient.

What the bounce is actually telling you

Microsoft 365 checks the recipient address before it runs any filtering at all. The feature is called directory-based edge blocking, and Microsoft's own description of it is blunt: it rejects messages for invalid recipients at the service network perimeter, the message is blocked before filtering even occurs, and a non-delivery report goes back to the sender.

Two things follow. Your message never reached a mailbox, a transport rule or a quarantine, so there is nothing for the recipient to find and release. And the decision came out of the receiving organisation's own directory, not out of anything about you: you get the same bounce whether you send from Google Workspace, from Microsoft 365, from a CRM or from a shop's order script.

Ignore the bracketed code at the end of the line. The two parts that matter are the status code and the address it names.

Which 550 are you looking at

Most of the hours wasted on bounces come from treating every 550 the same. Match the string you actually received, then decide whether the next move is yours at all.

Bounce you received	What the receiving side decided	Who can fix it
`550 5.4.1 Recipient address rejected: Access denied`	Microsoft 365 found no valid recipient for that address and rejected it at the perimeter	The receiving admin, or you if it is a typo
`550 5.1.10 RESOLVER.ADR.RecipientNotFound`	The address lookup failed inside the receiving organisation, a common hybrid symptom	The receiving admin
`550 5.1.1 The email account that you tried to reach does not exist`	Gmail has no such account on that domain	The receiving admin, or you if it is a typo
`550 5.4.6 mail for example.com loops back to myself`	A mail server believes it owns the domain and has no local mailbox for the address	Whoever runs that server, often an old host of yours
`550 5.7.1` or `550 5.7.26`	Your authentication or your sending reputation, not the address	You

Only the last row is your problem in the ordinary sense. The rest are routing and directory problems, and three of them are on the other side of the fence. That changes what a useful next hour looks like: you are gathering evidence for someone else's admin, not tuning your own DNS.

What we check first, in order

This takes about ten minutes and it settles the question of whose problem it is.

Read the address character by character. Not the display name, the address in the bounce. Transposed letters, a .com that should be .com.mx, a trailing space pasted in from a PDF, a capital I where there is a lowercase l. This is still the most common cause and it costs nothing to rule out.
Find the scope. Send one short message to a different address at the same domain, ideally one published on their website. If every address at the domain bounces, the problem is in how that domain is configured. If only one bounces, the problem is that one recipient.
Confirm where the domain's mail really goes. A domain whose MX points at Microsoft's mail protection hosts is a Microsoft 365 tenant, and the 5.4.1 explanation applies. A domain whose MX points somewhere else is a different conversation.
Rule your own side out before you escalate. Nobody's admin moves quickly for a sender who cannot show their own authentication is clean. Check SPF, DKIM, DMARC and MX on your domain first, so the message you send to their IT is short and credible.

dig +short MX clientdomain.com
# 0 clientdomain-com.mail.protection.outlook.com.

Step four is the one that saves the most time. Run your own domain through the checker first, so that the note you send the other side can say in one line that your SPF, DKIM, DMARC and MX are clean and the rejection came out of their directory.

The fix when one address is affected

When a single recipient bounces and the rest of the domain is fine, something about that one recipient object is wrong or stale. The address may simply not exist any more, which is a two-second answer the recipient's IT can give you. If it does exist, Microsoft's guidance for a single affected mailbox in a hybrid setup is to reset the recipient's SMTP proxy address: change it to a temporary address, then change it back, which forces the directory to republish it. Mail-enabled public folders get checked the same way, by confirming the folder has actually synced to Exchange Online.

The part that trips people up is timing. Microsoft says to allow up to 24 hours for directory-based edge blocking to update fully. An admin who makes the change, tests three minutes later and sees the same bounce will often conclude the fix did not work and undo it. Make one change, note the time, and test again after the window.

The fix when the whole domain is affected

When every address at the domain bounces, look at the accepted domain type in the receiving tenant, under Mail flow and then Accepted domains. Microsoft defines the two settings that matter plainly. An authoritative domain means the organisation is completely responsible for delivering email to recipients in the domain and for generating non-delivery reports, and mail for unknown recipients is rejected. An internal relay domain is non-authoritative: the organisation receives the mail but relays it to an external email system under its control, and that external system is responsible for generating non-delivery reports for unresolved recipients.

Microsoft's repair step for a domain-wide case is to resync the directory by switching the accepted domain from authoritative to internal relay and then back to authoritative. In the admin center that is two clicks on the same screen. From PowerShell it is one command each way:

Set-AcceptedDomain -Identity "clientdomain.com" -DomainType InternalRelay
Set-AcceptedDomain -Identity "clientdomain.com" -DomainType Authoritative

One warning, because we have cleaned up after it: leaving the domain on internal relay is not a fix. Microsoft's own instruction is not to select that option when all of the recipients for the domain are in Microsoft 365, and the reason is that it stops the perimeter from rejecting unknown addresses and hands them to a system that may no longer exist. The symptom goes away, and mail to mistyped addresses quietly stops producing a bounce anybody reads.

The migration trap

The version of this we see most often is not a bug, it is a migration that was called finished too early. Microsoft's own setup advice is to set the accepted domain to internal relay while you build the tenant, add every intended recipient, let them replicate, and only then switch the domain to authoritative.

Switch to authoritative one evening too soon and the directory becomes the gate. Staff mailboxes are there, so internal mail looks perfect and the migration is declared a success. The addresses nobody rebuilt are the ones that start bouncing to the outside world: the shared mailbox on the invoice template, the distribution group the warehouse uses, two aliases on the old receptionist's mailbox, the contact record for an accountant who is not in the tenant at all. Customers and suppliers get 5.4.1. The business hears nothing, because the bounce goes to the sender, not to the recipient.

The mirror image is just as common: a domain left as an authoritative accepted domain in an old tenant that was never decommissioned, still answering for addresses that moved years ago.

What to watch afterwards

Once the recipient object or the domain type is corrected, test from outside the organisation, not from an account on the same domain, because internal mail never passes the perimeter check. Then walk the list of addresses the business actually publishes, not the list of staff: the one on the website contact page, the one on invoices and quotes, the one on the business listing, the sales and billing aliases, the address the online store sends order notifications to. Each of those is a path a customer uses, and each one can fail on its own.

Keep the bounce messages until you have a clean test. They carry the exact address and timestamp, which is what lets anyone reconstruct whether a change worked rather than argue about it.

How Guanacos Tech helps

Most of the work in a 5.4.1 is proving where the failure happened so the right person spends the right ten minutes on it. We read the bounce, check the receiving domain's routing, rule your own authentication in or out, and give you one short paragraph you can send to the other side's IT, or we make the change if the tenant is one we look after. It is part of email deliverability consulting for small business, and it comes up constantly in the weeks after a mailbox migration. Book a 30-minute call and bring one bounce with full headers; that is usually enough to tell you whose change this is.

550 5.4.1 "Recipient address rejected: Access denied": why a good address bounces