Servers have forwarding disabled by default, it can be enabled, however, it can only be used to forward emails to email-accounts hosted within the same hosting account. Forwarding to external email-accounts will result in the majority of the email to be blocked by our outgoing filtering. This will affect your deliverability for all other emails that you send out from your account.
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.
What's the solution then?
There isn't a single solution because support differs on the destination when you try to forward emails, however, we have a few suggestions.
- Some major ESPs (email service providers) offer the possibility to do a POP3 import of your external accounts into their service, it's a great solution to import your email from your email at your custom domain to a general email, it imports emails using the POP3 implementation, which results in that our servers will not be seen as spam. It won't violate SPF, DKIM, and DMARC in any way.
- Don't forward, but rather register with your email that you're forwarding to, it's a whole lot easier.
- Add your email account to your email application
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.
What's the solution then?
There isn't a single solution because support differs on the destination when you try to forward emails, however, we have a few suggestions.
- Some major ESPs (email service providers) offer the possibility to do a POP3 import of your external accounts into their service, it's a great solution to import your email from your email at your custom domain to a general email, it imports emails using the POP3 implementation, which results in that our servers will not be seen as spam. It won't violate SPF, DKIM, and DMARC in any way.
- Don't forward, but rather register with your email that you're forwarding to, it's a whole lot easier.
- Add your email account to your email application
Comments
0 comments
Please sign in to leave a comment.