Situation: I am sending emails from me@mydomain.com to alice@example.org. My DNS for mydomain.com is correctly configured with an SPF record. The recipient at example.org is able to receive my emails just fine (it says "SPF: pass" in the headers).

Now, Alice configures alice@example.org to redirect any email to bob@otherdomain.com. So alice@example.org no longer has a mailbox or account attached to it, it's simply a forwarding address to bob@otherdomain.com.

I send an email to alice@example.org again. However, the receiving end at otherdomain.com now thinks the email is coming from example.org (as that's the last forwarding server or IP address), which of course does not have the SPF record that I have on mydomain.com. So it now marks my emails as failed for the SPF check, and puts in the spam folder.

So in short, the problem is: Due to redirecting email (on which I have no influence) the final recipient erratically thinks my email fails the SPF check, and discards it as spam. Is there a way to avoid this?

Also, I noticed sometimes that if I don't have a DKIM record (and not using DKIM) but the forwarding server does, then the recipient thinks my message failed the DKIM check as well. Whereas I don't even use DKIM, nor do I have a DNS record for this. It's the forwarding server (example.org in this example) that makes the recipient think the email should be DKIM signed.

(edit) Note that if I email to bob@otherdomain.com directly, the problem does not occur. My email is then considered to be valid (it passes the SPF check) and does not get filtered as spam. However I can't know in advance if someone is using a forwarding address.

closed as unclear what you're asking by Simon Hayter Dec 14 '17 at 16:21

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Your question is missing vital information such as whom hosts the email, e.g Googe G Suite, Microsoft Online Exchange or if you host it include information about your setup, e.g cPanel with Spam Filter enabled. (include both send and receive setups). – Simon Hayter Dec 14 '17 at 16:23
  • 1
    @SimonHayter What I'm asking is: I have a SPF record properly set up. However often people are using forwarding addresses (which I can't tell from the address) and when I mail from A to B, it's automatically being redirected from B to C, and then C somehow thinks the mail originates from B instead of A. But B obviously does not have the right SPF record for my original sending address (A). So C decides my email fails the SPF criterium, and discards it as spam. Is there a way to avoid this problem? E.g. configure my SPF to just approve all senders? (which kinda defeats the purpose) – RocketNuts Dec 14 '17 at 22:25
  • 1
    @RocketNuts this is actually a good question, however you haven't framed it properly in the original post. If you can reword it to add the bold text as a question I would vote to take it off hold. – Steve Dec 15 '17 at 1:18
  • 1
    @SimonHayter No it's not unique, unfortunately I encounter this problem in multiple environments, with very different setups. I'm feeling the problem is more fundamental. It involves the general case of emailing from a domain with SPF record (which I'd say is standard) to a forwarding/redirecting address, and then the recipient erratically thinking the forwarding/redirecting server is the originating server, instead of my original domain. This is regardless of setup or specific software. It seems to happen in general when people use forwarding or redirecting addresses (which is quite common). – RocketNuts Dec 15 '17 at 10:59
  • 1
    @SimonHayter With all due respect, the question has all needed information and your linked question is about mails showing up as "spam" in general. This one here is about mails only showing up as "spam" WHEN FORWARDED to a third party. Which is a whole different issue (mainly with SPF) in itself. – mbirth Jul 14 '18 at 21:16