4

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.

|improve this question
  • 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
    There's two possible solutions: 1. example.org has to use Sender Rewriting Scheme (SRS) to make the mail look as if it's coming from @example.org. That works in all cases, but destroys/garbles the actual sender. So Replies won't work unless example.org routes them back.; 2. check SPF/DKIM/DMARC on example.org and add an ARC record stating everything is fine. otherdomain should find that record and let SPF pass. However, this is based on trust and for me, e.g. GMail has trust issues and still lets mails fail if SPF fails. – mbirth Jul 13 '18 at 12:33
  • 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