What causes '550 administrative prohibition' bounces not due to recipient policy?
Updated on 15 Oct 2026: We added routing and relay checks and clarified the evidence needed to diagnose a 550 administrative prohibition bounce.
A "550 Administrative prohibition" bounce without a clear mailbox-level rule means an SMTP server refused the delivery attempt. The refusal can come from the recipient gateway or an intermediate relay. It is not proof that the mailbox owner blocked the sender.
Possible causes include authentication failure, a domain impersonation rule, a routing or relay mistake, sender reputation, a blocklist (blacklist) hit, malformed envelope data, an invalid SMTP identity, or a gateway rule that uses a generic 550 response. The bounce text alone rarely names the real cause. The useful evidence is in the full delivery status notification, the sending path, the message headers, and the receiving gateway logs.
What 550 administrative prohibition means
When this bounce follows a message sent through Gmail or Google Workspace using a company domain, identify the rejecting server in the delivery report before assigning the cause. The phrase "administrative prohibition" is broad. It can come from a mail gateway, a hosted filtering layer, an on-premises server, or an intermediate relay.
- Authentication: An SPF or DKIM failure, or a DMARC failure, triggered the receiver's authentication rule on the actual sending path. An individual SPF or DKIM failure does not necessarily mean DMARC failed.
- Impersonation: The receiving gateway thought the message used its own domain, a lookalike domain, or an unauthorized sender identity.
- Routing: The message reached the wrong MX, a decommissioned gateway, or a server that refuses mail for that domain.
- Reputation: The sender IP, envelope domain, DKIM domain, or visible From domain had a negative reputation signal.
- Formatting: The envelope sender, recipient syntax, header structure, or MIME content triggered a hard rejection.
Read the wording carefully
A 550 code means permanent failure for the message in its current form. It does not prove the address is invalid. "Administrative prohibition" indicates an administrative refusal, but the exact rule and the server responsible require the full diagnostic. Do not keep resending the unchanged message.
|
|
|
|---|---|---|
Authentication failure | Explicit SPF, DKIM, or DMARC diagnostic | Validate the failed check on the actual path |
Impersonation rule | Local-domain or unauthorized-sender wording | Ask the gateway owner which identity matched |
Routing or relay refusal | Unexpected Remote-MTA, relay denied, or 5.4.x | Check MX, next hop, and connector permissions |
Reputation block | Named IP/domain or blocklist in the diagnostic | Confirm the listing and remediate its cause |
Fast triage map for a generic 550 administrative prohibition bounce.
Read the enhanced status code first
The three-part enhanced status code narrows the cause more reliably than the 550 reply alone. The first digit gives the result class, the second identifies the subject area, and the third adds detail. A 5.x.x result is permanent for the message as submitted, while a 4.x.x result is a temporary deferral that the sending system can retry. The code families are defined in RFC 3463; the server's full diagnostic still determines the next check.
|
|
|
|---|---|---|
5.0.0 | Other or undefined status | Use the full diagnostic and gateway log |
5.1.x | Addressing problem | Verify the recipient and domain |
5.4.x | Network or routing failure | Check MX and next-hop routing |
5.5.x | SMTP protocol problem | Inspect command syntax and session logs |
5.6.x | Content or media problem | Inspect MIME, headers, and attachments |
5.7.x | Security or policy refusal | Check authentication, authorization, and reputation |
Use the exact enhanced code and diagnostic text together.
A 5.7.1 response means delivery was not authorized and the message was refused, but it does not identify one universal cause. Per-host filtering, relay restrictions, sender authentication, spoof controls, or a recipient-side rule can all produce it. A generic 5.0.0 removes even that subject-level clue, so the Remote-MTA, timestamp, SMTP stage, and receiver logs become more important.
Identify the server that rejected Gmail-sent mail
A common pattern is a company address sent through Gmail to a customer domain that normally accepts mail. Then one message bounces with "550 Administrative prohibition" and a delivery report that names the customer's edge server as the Remote-MTA. That detail matters. Gmail attempted delivery to that server, which returned the refusal. A Remote-MTA entry does not establish that the server accepted the message for delivery.
That still does not mean a person created a recipient-level rule. Gateways often return the same phrase for many checks: inbound spoof controls, DMARC rejection, relay restrictions, sender verification, attachment rules, or an internal route that no longer accepts mail. Some systems also use a generic 5.0.0 enhanced status code, which removes the detail that would normally help.
If the diagnostic includes gsmtp, Google SMTP returned that error. The additional marker gcdp identifies a custom Google Workspace administrator rule. Check which hop emitted the response before assigning it to the sender's or recipient's administrator.
Recipient-specific restriction
- Scope: The rule targets one user, group, or mailbox.
- Evidence: Only one recipient fails during comparable tests. This suggests a recipient-specific restriction but does not prove who configured it.
- Owner: The mailbox or group administrator checks delivery restrictions, including external-sender permissions.
Gateway-wide restriction
- Scope: The rule targets a sender, domain, route, IP, or gateway condition.
- Evidence: Comparable messages fail across multiple recipients at the same gateway. Remote-MTA identifies the server, not the rule's scope.
- Owner: The administrator of the rejecting gateway checks its SMTP and filtering logs.
The sender still has useful work to do before asking the recipient admin for help. Collect available authentication results and confirm the actual route and source IP. Include unknown results explicitly so the receiving admin can investigate without treating a successful test elsewhere as proof of acceptance.
Evidence to collect before changing DNS
Avoid changing SPF, DKIM, DMARC, or routing records until the full bounce is available. A short copy-paste of the top error line hides the useful fields. The delivery status notification (DSN), also called a non-delivery report (NDR), normally includes the final recipient, status, and diagnostic text. Look for Remote-MTA and the attempt time as well; use sending logs when those fields are absent.
Example delivery status notificationtext
550 Administrative prohibition Final-Recipient: rfc822; name@customer.example Action: failed Status: 5.0.0 Remote-MTA: dns; portal.customer.example Diagnostic-Code: smtp; 550 Administrative prohibition Last-Attempt-Date: Fri, 7 Aug 2026 11:55:35 +1000
- Timestamp: Capture the exact local time, timezone, and delivery attempt time.
- Remote server: Record the Remote-MTA host and the destination IP from the sending log so the responsible admin can search the right gateway.
- Message ID: Save the original Message-ID and the SMTP transaction ID if the bounce includes one.
- SMTP stage: Note whether rejection followed EHLO, MAIL FROM, RCPT TO, or the end of DATA. Before DATA, the receiver has not received the headers or body, so it cannot verify this message's DKIM signature or inspect its attachments.
- Headers: Save the original message headers and a successful comparison message when available. A rejected message often has no Authentication-Results header from the rejecting server.
A controlled test helps narrow the cause. Send plain text without attachments to the same recipient through the same route. Separately, inspect authentication on that sending path with Suped's email tester. If the recipient accepts plain text but rejects the original, investigate content and header differences. If both fail, inspect the server diagnostic; this alone does not distinguish identity, routing, or recipient restrictions. A test at another receiver cannot reproduce the original gateway's decision.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The goal is to build a short evidence pack: the bounce, the original headers, one fresh test, and the DNS state at the time. That pack prevents random DNS edits and gives the receiving admin enough detail to find the exact rejection rule.
Authentication and DNS checks
Authentication is the first sender-side area to check because it changes more often than people expect. A new sending service, a changed Gmail routing rule, a broken DKIM signature, or an SPF lookup limit can turn a routine message into a hard refusal.
Start with a domain health check for the visible sender domain. Then confirm the exact identity used: the visible From domain, the SMTP MAIL FROM (envelope sender) domain, the DKIM signing domain, and the sending IP. Return-Path records the envelope sender on delivered copies; a sent copy does not always contain it. DMARC passes when SPF or DKIM passes with the required domain match to the visible From domain. It does not require both methods to pass.
Illustrative authentication fields from an accepted comparison messagetext
From: user@company.example Return-Path: bounce@mailer.company.example DKIM-Signature: d=company.example; s=google; Authentication-Results: mx.customer.example; spf=pass smtp.mailfrom=mailer.company.example; dkim=pass header.d=company.example; dmarc=pass header.from=company.example
Use Authentication-Results added by the receiving system you trust. Results added by the sender or a different gateway do not establish what the rejecting server evaluated. Forwarding often breaks SPF, while a surviving DKIM signature with the required From-domain match can still produce a DMARC pass.
Suped's product combines DMARC aggregate reporting with SPF and DKIM checks and guided repair steps. DMARC monitoring helps identify failing sending sources in reports from participating receivers. Reports cover reporting intervals, commonly a day, and do not identify an individual bounce or provide the rejecting gateway's rule. Correlate the report period and source IP with SMTP logs.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a Gmail or Google Workspace sender, also check whether the domain has DKIM enabled in the admin console, whether SPF authorizes Google's sending hosts, and whether third-party systems send with the same domain without authorization. A single unauthorized sender can cause intermittent failures that look like random recipient-side bounces. Publish one SPF record for the envelope sender domain and check SPF's limit of 10 DNS-lookup-causing terms during evaluation, including nested includes. Verify the DKIM selector actually used, not a selector from an older setup. After DNS repairs, allow cached records to expire according to their TTL before retesting. The lookup limit is defined in RFC 7208.
If SPF, DKIM, and DMARC pass, verify the SMTP connection identity. The sending IP should have reverse DNS, the PTR name should resolve back to that IP, and the EHLO name should be a valid fully qualified domain name associated with the sender. A missing PTR record or an EHLO value such as localhost can trigger a 5.7.x refusal even when message authentication passes. For hosted sending, ask the sending provider to investigate PTR and EHLO settings; those records belong to its infrastructure.
Do not lower DMARC first
Changing your domain's DMARC policy from p=reject to p=none does not fix relay permissions, reputation, or gateway rules. First establish whether the rejected message failed DMARC, repair the authorized sending source, and retest. A receiver can still reject mail that passes DMARC.
Check routing and relay permissions
A valid message can reach a server that is not configured to accept or relay it. Microsoft's 550 5.7.1 troubleshooting guidance identifies wrong-server routing and missing relay permissions as causes. Compare the actual next hop with the intended delivery path before changing authentication.
- Compare the recipient's current MX records with Remote-MTA and the sending log. Check stale routing overrides or smart hosts after a migration, and verify connector scope in hybrid mail deployments.
- Ask the gateway admin whether the recipient domain is configured as an accepted or relay domain and whether connector trust matches the expected source IP or certificate. For application submission through your own relay, verify its required SMTP AUTH settings.
- On Exim servers, inspect the access control list (ACL) active at the rejecting SMTP stage. Custom ACL conflicts can produce "550 Administrative prohibition." Back up the configuration and correct the specific rule identified in the logs.
- If logs show "sender verify failed," check routing for the MAIL FROM address and whether it accepts bounce messages. Exim sender callouts test return-address reachability separately from SPF and DKIM.
A server that refuses relay access needs a routing or authorization fix from its administrator. A public DNS authentication pass does not establish relay permission.
Reputation and blocklists
A generic administrative prohibition can also be reputation-driven. Some gateways translate a domain or IP reputation decision into the same 550 text they use for local rules. Check blocklist and blacklist status alongside authentication instead of waiting through days of back-and-forth. A clean public blocklist result does not rule out a receiver's private blacklist, internal reputation score, or sender restriction. Confirm the exact domain or sending IP named in the diagnostic and whether the receiver uses the identified list.
In Suped's product, blocklist monitoring connects domain and IP listing checks with DMARC context. An authenticated message can still be refused because of the shared IP's or domain's reputation. Treat a listing as a clue until it matches the rejected path and the receiver's diagnostic.
Reputation triage priority
Qualitative investigation priorities, not measured reputation scores or acceptance guarantees.
Low
Watch
One isolated bounce, authentication verified, and no listing found. Inspect the diagnostic.
Medium
Investigate
Multiple bounces at one receiver or one gateway family.
High
Fix now
Broad rejections or a relevant listing tied to the rejected source.
The fix depends on the source. If the listed asset is a third-party sending IP, open a ticket with that sending provider and include the full diagnostic. If the listed asset is your domain, review recent campaign behavior, compromised accounts, forwarding loops, and unauthorized systems using your domain. Correct the cause before requesting removal under the list owner's process.
A practical troubleshooting sequence
Use a fixed sequence because this bounce invites guesswork. The right order is to prove where the rejection happened, prove what identity the receiver evaluated, and then decide whether the fix belongs to the sender, the sender's platform, or the recipient gateway administrator.
Flowchart for checking the full bounce, Remote-MTA, authentication, reputation, sender fixes, and gateway logs after a 550 administrative prohibition.
- Confirm scope: Send comparable tests to another recipient at the same domain and a different external domain, keeping the sending route unchanged. Scope is a clue, not proof of the exact rule.
- Read the DSN: Use the Remote-MTA, status, diagnostic code, and attempt time as the starting point.
- Check auth: Validate SPF, DKIM, and DMARC for the actual sender path, and identify which receiver supplied each result.
- Check reputation: Review domain and IP blocklist (blacklist) status at the time of the bounce, then confirm any listing is relevant to the rejecting gateway.
- Simplify content: Retest plain text through the same route to look for content differences after checking the SMTP stage.
- Escalate cleanly: Send the responsible admin the full diagnostic, available headers, timestamp, source IP, and Message-ID if available. Include the envelope addresses and SMTP stage; before DATA, the gateway cannot see the Message-ID header.
If the investigation starts showing broader 550 behavior, compare it against common SMTP 550 causes so you do not overfit one bounce phrase. The same family of SMTP replies can mean invalid address, relay denial, access denied, authentication rejection, or content refusal.
Fix on the sender side
- Use this: The diagnostic identifies an authentication failure, an unauthorized sender, or a submission/relay configuration problem.
- Proof needed: Trusted receiver results or SMTP logs identify the failing check on the rejected path.
- Next step: Repair DNS or sender setup, then retest with the same route.
Ask the recipient admin
- Use this: Only their gateway rejects the message, the diagnostic names their restriction, or sender-side checks do not explain the refusal.
- Proof needed: A full DSN, timestamp, source IP, envelope sender and recipient, SMTP stage, and Message-ID if available.
- Next step: Ask for the gateway log reason tied to that SMTP attempt.
