When you forward emails in cPanel, emails are forwarded as they're received from the external mail-service, this also means that spam will get marked as spam in our outgoing filter, and sending rules will get applied to all emails being forwarded - this can result in emails not being forwarded.
To explain a bit why emails might not be forwarded, we'll cover it in a few different sections.
Marked as spam
If our outgoing spam filter detects an email being spam, it will reject it during a forward to an external account. This is done to prevent spam from being forwarded to other ISPs, we do not differ email sending between forwarding and actual outgoing email, because both can result in unsolicited emails towards the recipient which is against the various spam acts across the globe, and at the same time, we try to keep our sender reputation high to ensure delivery of customer emails.
Forwarding spam will result in a "bounce" from the external mail filter, telling that the email has been rejected.
Violating SPF, DKIM and/or DMARC settings
The internet is made up of a lot of infrastructure and rules, for everything to function and work together in a unified way, we use something called an "RFC" - and RFC also known as Request for Comments is a publication from IETF and the ISOC that defines technical standards for the internet. In short, it's a "ruleset" of how things should work, and shouldn't work.
Within email-sending, there's a whole lot of RFCs defining different parts of the chain how to send, receive and secure emails, some of these RFCs, cover something called "SPF" (Sender Policy Framework), "DKIM" (DomainKeys Identified Mail) and "DMARC" (Domain-based Message Authentication, Reporting, and Conformance).
SPF roughly defines what IPs or subnets that are allowed to send an email on behalf of a specific domain. SPF is used as a safety measure to prevent email spoofing, spam, and phishing by allowing the owner of a domain to publish a list of allowed IPs that can send emails for that specific domain.
DKIM is a method designed to detect email spoofing by allowing the receiver to check that an incoming email indeed came from the specified domain. It works by generating a digital signature of the email and attaching it to the email and then later performing validation with a public key available via DNS.
DMARC again is another method to validate, reject and report emails based on SPF and DKIM, it's a possibility to receive reports on how emails are received if they're complying to SPF and DKIM and to detect possible spoofing of your email.
Let's assume you have an email called contact@example.com that is set up to forward to contact@hotmail.com
If contact@example.com receives an email from contact@gmail.com - we will try to forward this email to contact@hotmail.com - however, this will fail because Google publishes SPF records that tell that any server that is not a part of their subnets are not allowed to send an email on behalf of the gmail.com domain.
As a result, forwarding the email will cause an SPF violation, and since we're following the defined RFCs, the outgoing spam filter will automatically reject the forwarded email, because it's not allowed to actually send the email.
There's another feature in email-sending called "SRS" (Sender Rewriting Scheme) that allows bypassing this restriction of SPF violations, however, it will introduce other issues such as possible marking your domain or our servers as "spammers" because it would cause the "From" header within the email, to get rewritten to your own email account, and in case the forwarded content would actually be spam, it would again be rejected but at same time decrease the sender reputation, because your domain would suddenly be sending spam.
For the same reason, we do not implement SRS into our infrastructure.
To explain a bit why emails might not be forwarded, we'll cover it in a few different sections.
Marked as spam
If our outgoing spam filter detects an email being spam, it will reject it during a forward to an external account. This is done to prevent spam from being forwarded to other ISPs, we do not differ email sending between forwarding and actual outgoing email, because both can result in unsolicited emails towards the recipient which is against the various spam acts across the globe, and at the same time, we try to keep our sender reputation high to ensure delivery of customer emails.
Forwarding spam will result in a "bounce" from the external mail filter, telling that the email has been rejected.
Violating SPF, DKIM and/or DMARC settings
The internet is made up of a lot of infrastructure and rules, for everything to function and work together in a unified way, we use something called an "RFC" - and RFC also known as Request for Comments is a publication from IETF and the ISOC that defines technical standards for the internet. In short, it's a "ruleset" of how things should work, and shouldn't work.
Within email-sending, there's a whole lot of RFCs defining different parts of the chain how to send, receive and secure emails, some of these RFCs, cover something called "SPF" (Sender Policy Framework), "DKIM" (DomainKeys Identified Mail) and "DMARC" (Domain-based Message Authentication, Reporting, and Conformance).
SPF roughly defines what IPs or subnets that are allowed to send an email on behalf of a specific domain. SPF is used as a safety measure to prevent email spoofing, spam, and phishing by allowing the owner of a domain to publish a list of allowed IPs that can send emails for that specific domain.
DKIM is a method designed to detect email spoofing by allowing the receiver to check that an incoming email indeed came from the specified domain. It works by generating a digital signature of the email and attaching it to the email and then later performing validation with a public key available via DNS.
DMARC again is another method to validate, reject and report emails based on SPF and DKIM, it's a possibility to receive reports on how emails are received if they're complying to SPF and DKIM and to detect possible spoofing of your email.
Let's assume you have an email called contact@example.com that is set up to forward to contact@hotmail.com
If contact@example.com receives an email from contact@gmail.com - we will try to forward this email to contact@hotmail.com - however, this will fail because Google publishes SPF records that tell that any server that is not a part of their subnets are not allowed to send an email on behalf of the gmail.com domain.
As a result, forwarding the email will cause an SPF violation, and since we're following the defined RFCs, the outgoing spam filter will automatically reject the forwarded email, because it's not allowed to actually send the email.
There's another feature in email-sending called "SRS" (Sender Rewriting Scheme) that allows bypassing this restriction of SPF violations, however, it will introduce other issues such as possible marking your domain or our servers as "spammers" because it would cause the "From" header within the email, to get rewritten to your own email account, and in case the forwarded content would actually be spam, it would again be rejected but at same time decrease the sender reputation, because your domain would suddenly be sending spam.
For the same reason, we do not implement SRS into our infrastructure.
Comments
0 comments
Please sign in to leave a comment.