550 5.7.1 Sender ID (PRA) Not Permitted: what is it and how to solve it
Looking for some help regarding bounced-back emails with a ‘SMTP diagnostic: 550 5.7.1 Sender ID (PRA) Not Permitted’ error message?
As email experts ?, we’ll explain you what this error means and what you can do about it.
The Problem: Email Sender Identification
To start with, you should know this issue is related to the identification of the sender of an email.
Sender ID tries to improve on a principal deficiency in the Sender Policy Framework (SPF): that is SPF does not verify the header addresses that indicates the sending party. Such header addresses are typically displayed to the user and are used to reply to emails. Indeed such header addresses can be different from the address that SPF tries to verify; that is, SPF only verifies the ‘MAIL FROM’ address, also called the envelope sender.
However there are many similar email header fields that all contain sending party information; therefore Sender ID defines in RFC 4407 a Purported Responsible Address (PRA) as well as a set of heuristic rules to establish this address from the many typical headers in an email.
In essence, in addition to verifying the ‘MAIL FROM’ address, a mail server running Sender ID may also check whether the IP address from which we deliver your email matches the SPF records for the header address.
In case your domain has a Hardfail SPF record defined without listing the necessary IP addresses (such as eEvidences’ if you send registered emails), your email will be rejected as illegitimate.
The Solutions: How To Solve 550 5.7.1 Sender ID (PRA) Not Permitted
Don’t worry if you are facing this issue, there are several things you can do:
- List your email service provider IP range in your SPF record. By doing so, your SPF record will still protect others from spoofed emails pretending to be yours, whilst allowing your email service provider to be a legitimate source for the emails you send. If you are sending registered emails through eEvidence, you can contact our support team for some help.
- Switch your SPF record from Hardfail to Softfail. By doing so, an email coming from your email service provider IPs may still look suspicious to others, but it will be up to the recipient’s mail server to decide whether to accept it as legitimate or not.
- Ask us to take action. As an eEvidence client we can help you get through this. This Sender ID drawback does not only affect us, but also any forwarder and mailing list sending emails on behalf of others. Being aware of this, Sender ID had to provide some way to identify as legitimate any email being legitimately forwarded by others. And there is: Sender ID proposes that we add a line to the email header, informing the recipient’s mail server that we are resending an email we’ve received from you. This solution will certainly do the trick however, it is not clear within the Internet community whether it conflicts with the Simple Mail Transfer Protocol standard. For this reason, we will only apply this solution upon demand and only when no other alternatives can be applied.
We are eEvidence, the world’s leading Electronic Registered Delivery Service and we allow individuals and companies to send certified emails.
In 2012, we created our registered email technology because we thought everyone deserved to communicate safer and with legal certainty. Since then, our US and EU patented technology has been deployed in more than 90 countries and is currently registering more than 50 million emails.
Visit this page if you’d like to know more about what registered email is and why you may need to send some.
This blog post is an updated version of the original post “550 5.7.1 Sender ID (PRA) Not Permitted“, published on the eEvidence blog on June 20th, 2017 by Carlos Ticó.