Delivery error "550 5.7.1 sender id (pra) not permitted" occurs when Messaging Gateway attempts message delivery

Products

• Messaging Gateway

Issue/Introduction

Outbound messages sent through Symantec Messaging Gateway (SMG) are rejected by destination servers. The Message Audit Logs (MAL) or bounce messages (NDRs) contain the following SMTP response:

550 5.7.1 sender id (pra) not permitted

Cause

This error is generated by the recipient's mail server when it fails to validate your message using the Sender ID framework. 

What is PRA?

The Purported Responsible Address (PRA) is the email address that the Sender ID framework identifies as technically responsible for the message. Unlike standard SPF, which typically validates the Envelope From (MAIL FROM), Sender ID examines the message headers to find the 'most responsible' sender.

How PRA is Determined

The receiving server follows a specific heuristic to extract the PRA from headers in this order of priority:
1.  Resent-Sender
2.  Resent-From
3.  Sender
4.  From

If the IP address of the SMG appliance sending the mail is not authorized in the SPF record for the domain found in these headers, the recipient server rejects the message with the PRA not permitted error.

 

Resolution

Because this is an external validation failure, you must ensure your public DNS records align with your mail flow.

1. Identify the PRA Header

Review the headers of the original message to see which address is being used as the PRA. 

• If you use 'Send on Behalf' or 'Forwarding' features, the PRA may differ from the visible From address.
• Ensure that the domain of the PRA address has a valid SPF record.

2. Update SPF Records

Ensure the public SPF record for the sending domain includes the public IP address or FQDN of your SMG appliance. 
If you have recently added new SMG scanners or changed ISPs, update your SPF record to include the new egress IPs.

3. Verify DNS Propagation

Use tools like nslookup or dig to verify that the updated SPF record is visible to external DNS servers. Recipient servers will continue to reject mail based on cached or old records until propagation is complete.

4. Contact Recipient Admin (If Necessary)

If your SPF and Sender ID configurations are correct, the recipient's security gateway may be misconfigured or using an outdated version of the Sender ID specification. Contact their IT administrator to whitelist your sending IP or domain.