Recipient address rejected: access denied

The exact bounce

This rejection appears in several forms:

Recipient address rejected: Access denied
550 5.4.1 Recipient address rejected: Access denied
554 5.7.1 Recipient address rejected: Access denied
Remote Server returned '550 5.7.1 Recipient address rejected: Access denied'

The phrase is not specific enough to name one root cause. It means the receiving system refused the recipient address or refused to accept mail for that recipient under its current policy.

First split: recipient route or authentication?

A recipient rejection often happens during the SMTP RCPT TO stage, before the message body is accepted. That makes recipient-side routing and directory checks more likely than content filtering.

But some gateways combine recipient checks with sender reputation and authentication policy. Use the bounce details to split the problem:

• If the bounce mentions mailbox unavailable, user unknown, accepted domain, or relay access denied, start with recipient routing.
• If it mentions DMARC, SPF, DKIM, authentication, or unauthenticated email, check sender authentication.
• If only one recipient domain rejects mail, the recipient gateway is likely involved.
• If many unrelated recipients reject mail at the same time, investigate sender DNS, reputation, and authentication first.

Sender checklist

1. Confirm the address and domain

Check for typos, stale contacts, renamed domains, and addresses copied from CRM records. A generic access-denied response can hide a simple invalid-recipient problem.

2. Check the recipient domain's MX records

Make sure the domain still accepts mail where you think it does:

dig MX recipient.example +short

If the domain has no MX records, stale MX records, or a migration in progress, the rejection may come from an old filtering service that no longer has the recipient directory. You can also use the MX lookup tool to inspect the published mail servers, priorities, resolved IPs, and detected provider.

3. Inspect the full bounce

Do not rely on the short error shown by a mail client. Get the full non-delivery report and capture:

• Remote server hostname
• SMTP status code
• Enhanced status code, such as 5.4.1 or 5.7.1
• Sender and recipient addresses
• Timestamp with timezone

The remote server hostname often tells you whether the rejection came from Microsoft 365, Google Workspace, Proofpoint, Mimecast, a regional ISP, or a legacy gateway.

4. Check your own SPF, DKIM, and DMARC

Even when the recipient wording looks generic, poor authentication makes gateway rejection more likely. Verify your domain:

• SPF exists and does not return permerror.
• DKIM signs mail from the service you are using.
• DMARC exists and the sending service passes aligned SPF or aligned DKIM.
• The visible From: domain is the one you intend to send as.

Use the DMARCTrust DMARC checker to validate the DNS side before asking the recipient to investigate. It gives you a cleaner escalation if your domain passes.

Recipient admin checklist

1. Verify the domain is accepted by your mail system

In hosted mail systems, the domain must be configured as an accepted or verified domain. During migrations, it is common for MX to point to a gateway that no longer knows the domain is local.

Check whether the domain is authoritative, internal relay, or external relay in your platform. A mismatch can produce access-denied recipient rejections.

2. Verify the recipient object exists

Confirm the address belongs to a mailbox, shared mailbox, mail-enabled user, contact, or distribution group. Also check aliases. If directory-based edge blocking is enabled, the gateway may reject valid aliases until directory synchronization catches up.

3. Check external sender restrictions

Distribution groups, shared mailboxes, and helpdesk addresses often have rules that block external senders. Look for settings such as:

• Only authenticated senders allowed
• Allowed senders list
• Blocked senders or domains
• Moderation rules
• Transport rules that reject based on sender, recipient, or header

4. Check MX, connectors, and filtering services

If MX points to a filtering provider, the filter must route to the current mailbox provider and must have a current recipient directory. Stale configurations commonly cause this error after Microsoft 365 or Google Workspace migrations.

Also check inbound connectors, smart-host routes, IP allowlists, and TLS requirements. A connector that only trusts old source IPs may reject mail before it reaches the mailbox.

5. Check security gateway logs

Search by timestamp, sender, recipient, and source IP. The gateway log usually reveals the real reason: invalid recipient, blocked domain, SPF fail, DMARC fail, geo block, policy route missing, or directory lookup failure.

When it is actually a DMARC problem

Treat the rejection as a DMARC issue when you see evidence like this:

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=vendor.example;
  dkim=fail header.d=vendor.example;
  dmarc=fail header.from=example.com

Or when the bounce includes wording such as:

Message rejected due to DMARC policy
Unauthenticated email from example.com is not accepted
DMARC validation failed

In that case, fix the sending source so it passes aligned SPF or aligned DKIM for the visible From: domain. Do not weaken your DMARC policy to make one sender work; configure the sender correctly instead.

What to send when escalating

If you need the recipient admin or sender provider to investigate, include the details that let them find the log entry quickly:

• Sender address
• Recipient address
• Timestamp in UTC
• Full SMTP error
• Remote server hostname
• Sending source IP, if available
• Message-ID, if available
• Current SPF, DKIM, and DMARC validation result for your domain

This prevents the common loop where the sender says "recipient problem" and the recipient says "sender problem" without anyone looking at the actual gateway decision.

Validate the fix

After changing routing, recipient policy, or sender authentication, send a new test message. If the message delivers, inspect the headers and confirm authentication:

Authentication-Results: mx.receiver.example;
  spf=pass ...;
  dkim=pass ...;
  dmarc=pass header.from=example.com

Then validate the sender domain with the DMARCTrust DMARC checker so you know your DNS foundation is not contributing to future access-denied rejections.

Related fixes

• If the bounce mentions DMARC policy evaluation, read 554 5.7.5 permanent error evaluating DMARC policy.
• If your domain has no enforced DMARC policy, read DMARC policy not enabled.
• If SPF returns errors, read SPF errors.
• If DKIM fails on forwarded or modified mail, read DKIM failures.