Google seems to have broken email forwarding

Basically: I'm finding it impossible to reliably convince Google that email from my employees, to my employees, is not spam.

I run my own mail server, but most of my employees use Gmail. So I have forwarding set up: simply forwards to When sending mail using their Gmail account, they set their From line to (Google lets you do this if you jump through some hoops to verify that you can actually receive mail at that account.)

So when one of them mails another, the mail goes from their phone up to Google's SMTP server, with "From:, To:". That hits the MX (my machine) and is forwarded back to "" -- where it then ends up in B's spam folder, because Google (maybe?) thinks it's a "forgery".

I have proper DMARC and DKIM records ("dig TXT; dig TXT"). TLS is configured properly. I have SPF set to "v=spf1 a mx ptr ~all" (since I do, in fact, want my employees to be able to originate their mail on their ISP's servers.)

What do I have to do to make Google stop fucking me?

Allowing Google to host the domain is not an acceptable answer. Not having "" in the From and To fields is not an acceptable answer.

Forcing all of my employees to use my own IMAP server instead of Gmail would be a moderately terrible answer.

Previously, previously, previously, previously.

Tags: , , ,

87 Responses:

  1. Peter says:

    I had a similar problem and I just used the address in the To: field. This is also a moderately terrible answer I suspect.

    • jwz says:

      No, that is a completely unacceptable answer.

      • Anon says:

        No, what's completely unacceptable is having employees use Gmail as their email and expecting everything to work fine.

        • Alex says:

          Exactly. If you want to use GMail for your business, subscribe to Google Apps. If your users are relying on personal e-mail for work then don't expect business-class service, especially when you are trying to game the system to get the same features Google Apps offers for free.

          If your business can't afford Google Apps, then you have more problems than some false-positive spam detections.

          • jwz says:

            Oh, fuck off.

            • johnnyLoyd says:

              Alex is right.
              Each tool for each task.
              If they accept that as valid e-mail without raising flags, spam would be worse.
              Get Apps or setup a f*cking GOOD mail server so that your employees can use imap, exchange or something else.
              Lazy admins, can't setup a mail server properly and use this workarounds and even complain because it's not working. LOL. LOL...

            • furd_terguson says:

              My God. You created fucking Netscape and now you can't set up an e-mail server. That's so fucking depressing. How far can one person fall? If I ever got to be as senile as you I hope my loved ones would abandon me on an ice floe or take me behind a shed like Old Yeller and blow my brains out with a shotgun.

          • Neil says:

            This is bullshit.

            > If your users are relying on personal e-mail for work then don't expect business-class service,

            Personal Gmail is marking a messages as spam that clearly aren't spam. There's nothing about "my contacts' emails arriving in my inbox" that's a "business class service".

            > especially when you are trying to game the system to get the same features Google Apps offers for free.

            Exactly what feature here is a Google Apps feature that he's trying to "game the system" to get? He's just trying to run his own SMTP server, and his employees are using their client of choice (Gmail). He's not obligated to use Google Apps in order to get delivery on Gmail.

            If jwz wrote that his employees are not receiving messages sent through his SMTP server, you wouldn't respond with "he should use Google Apps". And that's basically what's happening -- Gmail's Send-As feature effectively turns Gmail into a SMTP client for another SMTP server; they don't even allow plain aliasing anymore. Assuming the messages are not in fact spam, where they originate from prior to his mail server is irrelevant.

      • Jason says:

        where is the like button?

  2. Vitorio says:

    I assume you've checked your headers to made sure you're not accidentally breaking DKIM? Per this.

    I have SPF set to "v=spf1 a mx ptr ~all" (since I do, in fact, want my employees to be able to originate their mail on their ISP's servers.)

    Do you actually want that? Most people use Gmail's mail servers (or Yahoo, or Hotmail, or whatever), not their ISP's. Shouldn't the SPF record be Gmail + Yahoo + SBC Internet or whatever? Something like v=spf1 ~all ? Surely you have few enough employees that that won't be completely insane.

    Also, since Gmail's spam filter uses everyone's email, it may help to have everyone log into Gmail on the web and unmark all email as spam.

    Unfortunately, if email delivery was remotely guaranteed any more, there wouldn't be Mandrill/Sendgrid/Amazon SES/etc.

    • jwz says:

      I assume DKIM is ok because Google inserts "Authentication-Results:; dkim=pass".

      But it also says "Received-SPF: softfail ( domain of transitioning does not designate as permitted sender) client-ip=;"

      • Vitorio says:

        Just to be clear, these two headers are on a mail that roundtripped from Gmail to cerebrum to Gmail again?

        It looks like SPF forwarding is breaking; I just set up four forwarded accounts (Gmail -> my server -> other Gmail) and tried to email between them, and got that SPF softfail only on Google's attempted validation email.

        I didn't change my SPF at all, and I have failures in my headers when Gmail proper is the source, but also none of my test mail is ending up in marked as spam:

        Received-SPF: fail ( domain of does not designate 146.6.xx.xx as permitted sender) client-ip=146.6.xx.xx;
        spf=fail ( domain of does not designate 146.6.xx.xx as permitted sender)

        It also doesn't seem to matter if "Treat as an alias" was selected when the new reply address was set up in Gmail. This suggests to me that it's not really an SPF or DKIM problem, but rather that any of your mail is flagged as spam in your employees' inboxes. Unflagging all of it in all of their mailboxes might be the right answer.

        This may also mean that the more complicated diagnosis of "SPF breaks forwarding" and answer of "you have to set up SRS" might be avoidable.

        Also, interestingly, sending from a Google Apps account to Gmail doesn't have failure headers:

        Received-SPF: pass ( domain of designates 69.164.xx.xx as permitted sender) client-ip=69.164.xx.xx;
        spf=pass ( domain of designates 69.164.xx.xx as permitted sender)

        • Jered says:


          SRS is unnecessary here. jwz has set his SPF to allow any sender IP address, so something else is borked.

          You're on the right track here with the test data, though. In your first case you're sending from a address, which is not on the SPF for How did you send this message? Was this:
          1) Inside the GMail web application?
          2) Via a phone or other mail client using Google's SMTP submission servers?

          If 1, then Google has borked their send-as-alias feature badly.
          If 2, then Google has borked send-as-alias for SMTP submission. I'm not sure if that was ever allowed, however.

          Note that this _still_ shouldn't affect jwz because his SPF is much more permissive than yours.

          Also, please don't obscure the IP addresses; it's a minor annoyance that doesn't help diagnose things:
 text = "v=spf1 ip4: -all"

          • Jered says:

            Nevermind what I just said; corrected answer is below. This, sadly, requires either SRS (under jwz's control) or Google using the correct envelope sender for Send Mail As aliases relayed to external SMTP servers (under Google's control.)

      • Jered says:

        Well, shit, nevermind what I said before. Even if you're using the Gmail interface with Send-Mail-As and a valid SMTP server, Google is setting the envelope sender to the gmail account address. (This is presumably to prevent SPF failures submitting to your SMTP server, but that's what using an authenticated account is for. This is bullshit.)

        I've verified your problem with some of my domains.

        Options are:
        1) Sender envelope rewriting on cerebrum (i.e. SRS)
        2) Don't use GMail Web Client to send as non Google-hosted domains
        3) Complain to Google (good luck)

        Received-SPF: softfail ( domain of transitioning does not designate as permitted sender) client-ip=; is logged in to GMail Web Client as and sends a message to Google's SMTP servers deliver that to with an envelope sender of (THIS IS WRONG ON SO MANY LEVELS.) cerebrum turns around and bent-pipe forwards back to Google's SMTP servers, who determine that Google's SPF record doesn't list cerebrum as a designated sender for (given the preserved envelope sender of

      • Jim Fenton says:

        The Authentication-Results header field you're seeing was added by your own mail server at; it's not an indication of whether the message passed DKIM verification at GMail. That's what the hostname there means.

        When you forward the mail back to Google, are you doing any rewriting at all? Signing happens via the Milter API, which is executed prior to any rewriting rules. So it's possible to break the signature that way. Is there another Authentication-Results header field from It should indicate whether DKIM (as well as SPF) passed or not.

  3. solarbird says:

    It sucks. There is a cleaner but more difficult answer in coding, or a somewhat derpier answer that involves a second machine (or VM) and requiring more specific behaviour out of your employees and I don't know how easy that will be.

    (All this is kind of dancing around how they destroyed all the traditional-style mailing lists in the world. We have ours limping along in that we wrote custom code so that all our mailing lists send From: our mailer, with the actual original address in munged but recoverable form in the name field, plus a few other things. I am not suggesting this as a solution as it is clearly not acceptable; even we don't think it's acceptable. But it was the only way to keep our mailing lists working for gmail users.)

    So if you want this to have any chance of working cleanly (HA!) without additional employee behaviour demands, write something to completely rewrite the header of every message handled this way with new information that says it came directly from your machine and was never involved with at all. Strip out everything involving Google (including the Message-ID, which will fuck up threading, sucks) and treat it as a new message originating from from a user on your server. That should work. Sorry.

    Alternatively, since these are employees, you can maybe get them to set up the accounts differently on the phone so they use your server as their outgoing SMTP host for messages involving work. That basically do the same thing. Mail involving dnalounge must initially hit dnalounge servers. I can't rule out you running into the mailing list problem at that point (see above), but I'm reasonably confident you won't.

    There are a couple of ways to do this, the least bad being to set up a second dedicated host for SSL authenticated email relay for account holders. (This prevents you from being used as a spam relay, of course.) exim is acceptably good at this.

    • Jan Ingvoldstad says:

      SRS is already decently implemented by pretty standard software, and combined with SPF records that don't soft fail, plus putting the From: address in the recipient's Gmail contact list, you stand a good chance to have decent deliverability.

      • Do you have a source for that? As far as I see, implementing SRS in postfix or exim can't be done with standard debian packages, even in sid..

        exim has some EXPERIMENTAL_SRS support.. but that's experimental and not included in any distribution as far as I see.

  4. Jered says:

    I'd need to see your full headers, but this step is where things may be going awry:

    So when one of them mails another, the mail goes from their phone up to Google's SMTP server, with "From:, To:".

    Google stopped allowing you to authenticate for sending as non-Google hosted domains a while ago, requiring actual authentication credentials for a MTA authorized to send as your domain. Older authenticated senders are grandfathered in but deprecated. So, at the very least, if your employees are actually sending as you're going to need to enable them to use your SMTP server.

    I speculate that the current mechanism is flagging the sender and/or domain. It's really hard to diagnose without access to test messages, though. I fought my way through a similar mess (and won) a few months ago.

    • That has been done.
      We all have set gmail to use dnalounge servers for sending as dnalounge addresses.

      • Jered says:


        If you're one of the senders getting filtered (and there's the "Received-SPF: softfail" header that jwz posted above in your messages), could I ask you to double-check your GMail Web Client settings?

        I got bit by this when I checked earlier -- clicking on "edit info" makes it look like you might have something configured even if you don't. Under Settings->Accounts and Import->Send Mail As there should be a stanza that looks like:

        Your Name <>
        Mail is sent through:
        Secured connection on port 597 using TLS

        If those last two lines are missing you are using the legacy Send Mail As support which fails in the way you are encountering; you need to click on "edit info" and provide the SMTP settings.

    • adfgg says:

      they are not sending as. it's a innocuous reply-to header.

  5. John Morton says:

    (I'm going to assume LJ's openid is busted and ate my last comment.)

    Try the following:

    * Have an employee pull up their Gmail in a browser
    * Put “To:(” into the search bar
    * Select “Create filter” from the “More” drop down menu
    * Click “Create filter with this search »” on the bottom right of the filter box
    * Ticky box “Never send it to Spam” and “Also apply filter to n matching conversations.”
    * Drink the cocktail of victory

    Ok, modestly terrible on account of needing to do it to a large subset of employee's gmail accounts, but at least you teach them how to filter their mail into folders in the process.

    It has worked for the few instances of misclassified spam I've experienced; worth a try on a test account, at least.

    • Glaurung says:

      "(I'm going to assume LJ's openid is busted and ate my last comment.)"

      I have not been able to use LJ for openid for posting to _any_ blog that supports openid, for a very long time. Just assume that it does not work, despite LJ's claims that it does, and use some other account for openid.

    • Viqsi says:

      I was going to suggest something like this, except the search bar would be ""

  6. Have you tried adding an "" to the TXT record? That should take care of it.

  7. Have you tried adding an "" to the TXT record? That should take care of it.

  8. zecege says:

    By the way, this ability to use a custom From: is still offered with old gmail account, but it's completely disabled in newly created ones :-/

    Painfully experienced that setting up an email account for grandma at Xmas time. Don't be evil.

  9. Derek says:

    YOUR spf, et al, records are irrelevant.

    Example: mail is from to ... you're forwarding to

    When you forward it to gmail's SMTP servers it is:

    coming from YOUR IP address

    So the question is whether or not YOUR IP address is in the SPF record for "" (which, almost certainly, it's not).

    This is one of the "well known and documented" problems with SPF/DKIM/etc., (because it breaks the shit out of poorly designed mailing list software as well).

    There are no good and clean answers to this problem, other than (as someone else suggested) having your users create filters in gmail SPECIFICALLY to tag as "not spam" anything which has their address in a recipient field (but then they lose any/all spam-protection gmail might offer).

  10. I have a similar setup; My solution is to use Gmail's POP3 support.

    I still get SPF fail headers, but Gmail doesn't seem to spam bucket them when they come via POP3.

    The horrible part is the extra 30-60 minutes for delivery while you wait for the poll interval. You can kick it manually but it's a pain in the rear.

  11. foo says:

    your problem is your ip. if it has ever been suspected of sending spam, google will not relay properly from it. i had the same problem trying to send voicemail messages to gmail addresses from asterisk.

    maybe there's a way to get them to clear it. i had to get a new ip but then it worked.

    • phessler says:

      if you are just going to make something up, at least come up with something more interesting than "bad ip".

  12. fd says:

    You're probably too smart to get caught by such things, but clueless me had real trouble when forwarding stuff to gmail (stuff getting tagged as spam) until I stumbled across this "envelope sender" advice:

  13. Same problem here. Took me a while to notice that all my mail ended up in the spam folder.

    The solution seems to be SRS , which I can't be bothered to implement.

    As it was only a handful people I forward / domains to that use gmail I just set up POP3 (yes, no IMAP fetching in gmail) mailboxes on my server for those users and myself.

    I am not a fan of SPF and DKIM anymore.

  14. Buddy Casino says:

    I had the same issue when I moved my mail server to Digital Ocean. Everything went straight to the spam folder. Then one day a mail came from Google, asking me if they could analyze my mails for better spam filtering. I suspected they noticed something went wrong. So I agreed, and a a few weeks later, it magically fixed itself.

    See how instead of a solution, I give hope instead? It feels so much better.

  15. whatever says:

    The only non-terrible (but still pretty bad) solution I found is to make Gmail retrieve email via pop3 from my other accounts rather than forward from them to Gmail. This adds up to an hour of delay but works reliably. You send mail the same way you do now (I presume: from Gmail but through your SMTP server).

  16. Jered says:

    Ignore my previous answers; I've done more testing with my domains.

    This will only happen with your users that have not configured to use the SMTP submission servers -- i.e. they have the old grandfathered configuration.

    If you have the old "Send Mail As" configuration (where it does not show you an SMTP server name right under the anddress on the Settings page), Google correctly sends with the user as the envelope sender, which leads to the breakage you describe under normal SPF processing.

    If you configure the SMTP submission server, you get the correct results w.r.t. envelope sender and SPF processing.

    This is a user configuration problem.

  17. I had a similar problem, where I was forwarding my work mail (from whatever Outlook setup they have) to my Gmail account. This worked fine for some time, until a few months ago, I started missing important email sent from other addresses to my, and severely delayed deliveries. (Not much ended up in Spam, but just would be several weeks(!) later.) The headers for these mails had the same "Received-SPF: softfail ( domain of transitioning" tag you mention.

    (This was very irritating, as only a certain amount of mail went missing - small enough that it was hard to detect at first - and seemingly mainly really important mail, like "if you don't do such and such by this date you'll never get tenure" - I exaggerate, but only slight.)

    Having asked around, I ended up signing up for to route mail to my Gmail (actually through an intermediate step, involving forwarding from to, for which I set Mailgun as my mail handler, and I have Mailgun forward to my Gmail.).

    Under a certain volume of mail, Mailgun is free (and I'm well under), so this solution has worked well for me. It's irritating to have had to set it up, but it works. I don't get "softfails" anymore, and I don't get severely delayed mail delivery. If you and your employees are not really receiving massive amounts of mail to your addresses, it might be under the "free" limit too.

  18. Otto says:

    Slightly confused by that final forward here. Is the final "to" address a address? What are the resulting headers on that final received email there?

    A ~all is a softfail, and yeah, that can make it go into spam. A ?all would not. Because gmail. Because Google.

  19. jwb says:

    If you send me a message-id, the name of the account that received the message in the spam folder, and the date on which it was sent, I can investigate this. I work on gmail delivery.

  20. Scroogled says:

    Fuck google

  21. tie says:

    Drop SPF completely. Seriously. DKIM is enough, and much better. SPF should die a quick death. This article explains it quite well, and it was written a decade ago.

    • jwz says:

      I am fully aware that SPF is a worthless piece of shit, but Google appears to be lending credence to it. Unless you have evidence that Google reacts to "no SPF at all" in some more pleasant way than "permissive SPF" (which seems tremendously unlikely) your suggestion is not helpful.

      • tie says:

        I do not have such an evidence, though I would defend the usefulness of my suggestion on a larger scale :) I think it's worth trying even in your case.

  22. Drew says:

    Have you tried using "Google apps for businesses" or maybe it's called "Google apps for work"? It's simpler than what you have now - you basically set up a domain account with Google, and then set your MX server to be

    The disadvantage is that EVERYONE in your business must use gmail now. That seems to already be the case.

    If it was me, I'd try Forcing all of my employees to use my own IMAP server instead of Gmail. Sorry :(

    • jwz says:

      Did you not read the part where I said "Allowing Google to host the domain is not an acceptable answer"?

      • Drew says:

        If you use "Google apps for businesses", Google only runs your MX, not your domain. The rest of the domain (website, etc.) would still be under your control. This doesn't allow them to do anything worse than they are already doing to you.

        But really, give some serious thought to just running your own server on your own, and not doing any forwarding to gmail. Gmail's spam filters are the problem, so it's best to cut those out, which means stop forwarding to them. I know this seems moderately terrible, but it gives your business control and privacy that Google wants to take away from you.

        Tell your employees that they unfortunately don't get to use that gmail interface they want, because it comes with too much baggage - in the form of incorrect spam filters.

        • jwz says:

          "Hi, I'm going to just repeatedly keep suggesting something that you -- up front -- said was off the table."

  23. Elizabeth says:

    You can have each gmail user set up their gmail account to receive mail from your server (not a great answer but works reliably)

    • jwz says:

      I am what you might call less than excited about the idea of telling my employees to type their DNA passwords into a third party server.

      But that link you sent isn't even about receiving mail (IMAP), it's about sending mail (SMTP).

  24. The best thing to do is have your employees use your IMAP server to receive email and use your SMTP server to send email. You shouldn't care what client they use (gmail, their phone's shitty default mail app, whatever).

    Since they are all going to use gmail anyway configure their gmail to fetch the dnalounge email via IMAP, and send mail via your IMAP server. In gmail go to "Settings -> Accounts and Import -> Send mail as" to configure it.

    Be sure to check "Reply from the same address the message was sent to"

    I can't imagine a good reason to run the SMTP part of your mail system in house. You should use a hosted SMTP service like Amazon SES, mailgun, or sendgrid rather than running your own SMTP server unless you are some kind of masochist. I've used SES and it is very easy.

    Change your DNS records to only allow sending through your SMTP servers (follow the instructions provided by the SMTP service) since all clients will be using your SMTP server.

    This may be moderately terrible, but this is better than forwarding.

    After you've done all that realize email is dead and you should all be using a chat service like hipchat or campfire or whatever anyway.

  25. Steve Jones says:

    Is it possible that you are communicating with Google via IPV6? I've had this problem and it turns out Google are really picky about RDNS when you're using IPV6, on the assumption that you can absolutely afford a dedicated IP address for your MX if you're using it.

  26. Paul Saab says:

    When your employees are sending email through gmail are they using your server to smtp relay or letting gmail send it. Have you thought about enabling smtp-auth and having the employees do that? This is what I do for my personal domain and no spam problems for me.

    gmail -> (ssl/tls) smtp.mydomain:465 -> recipient (gmail or yahoo or whatever)

  27. kris weston says:

    hi there, youre a total nobber. all the best now.

    • asan110 says:

      OK, surely this was cross-posted somewhere other than HN. Those guys are just painfully self-important, not painfully-stupid, right?

      • Tim says:

        What makes you say they're not painfully-stupid? Painfully self-important but intelligent is a transitory phase, lasting only as long as it takes for the victim to realize that the self-importance is unjustified because there's plenty of other smart people in the world. HN is full of surface level cleverness glossing over badwrongstupid.

        • Tim's right. HN may have been a place where more intelligent technical discourse took place, but that was years ago. Especially since Dang took over, they've been actively driving those people away. These days they prefer to discuss social and political matters than technology.

  28. John Howe says:

    In the GMail interface for the dnalounge employee, if they add each sender@dnalounge to their contacts list, that should bypass the spam flagging.

    Another option is to have the users on gmail make a whitelist filter for

    Step 1: In Gmail, click the “Create a Filter” link which is placed just next to the search box.

    Step 2: In the From: field, enter the email addresses, domain names or even actual names of people who you would like to whitelist. You can separate multiple entries using OR (in Caps) or with the bar (|) sign.

    Step 3: Once your filter is ready, click Next and select “Never Send it to Spam.”

    See also:


  29. BillKaos says:

    I'm afraid your problem will require to implement SRS, as others have pointed out. Sorry buddy.

    • jwz says:

      The thing that worries me about SRS is not that it is a pain in the ass -- and yes, it is -- but that Google's documents pretty clearly say "thou shalt not rewrite the envelope", in strong enough terms that it makes it sound like something they penalize.

      So it would suck to go through that pain in the ass only to discover that it actually made things even worse.

      Note that nobody here has said "I had your problem and SRS fixed it."

      • BillKaos says:


        using a .forward file should allow you to do some quick testing for SRS.

        It is assumed that not having SRS will break forwarding with Gmail, see for instance:

        Anyways it is difficult to tell without seeing all the headers. What does the sender header says? If from your domain to google you preserve the Sender: then you are busted I guess.

        (I can't test myself as I refuse to let google handle my mail)

  30. Force all the employees off Google. They have no business propping up GOOG shares on your dime unless GOOG actually pays you for the service.

    • jwz says:

      It shouldn't surprise you to learn that I don't give a flying fuck about the political bone you have to pick. I just want email to fucking work. You are not helping, go away.

  31. asan110 says:

    What portal to hell have you opened here, Jamie?

  32. Morgan says:

    After spending hours last night banging my head against the Gmail email-forwarding wall for my own organization, I've come to the conclusion that the undocumented answer to most "how do I get email forwarding to work with my domain?" questions is, "pay for Google Apps". I would find this less frustrating if they would actually come out and say, "You have to pay us to get email forwarding to work properly," but they seem to want to pretend that it still works properly with unpaid accounts.

    Incidentally, Hotmail seems to just work, which is a pretty sad state of affairs.

  33. This is a recent problem that I noticed as well. The solution that worked for me is to use my gmail address as the From address and use the company address in the Reply-To header. Gmail allows you to set this up as a default.

    • jwz says:

      I find that workaround unacceptable too. When an employee is communicating with a customer, the From field should contain the business address.

  34. Anthony says:

    For the record (since some of you seem confused), this still sucks even if you DO have a paid Google Apps for Business setup. The forwarding is fucked in an opaque fashion.

    I've used G.Apps for a while, but some (like 4 out of 7) of the people I work with prefer to use their own gmail accounts for a number of sensible reasons.

    I usually make a "group" for them in Google Apps, with them as the sole member, and the "group" forwards to their gmail account in question. This, however, sometimes causes emails inbound to to bounce with a message about "Bulk Sender Guidelines", but only sometimes (when you least expect of course). At some point I filed a ticket about this to be told that some flag has been reset on my account so this won't happen for a while (it eventually did again).

    The only reliable way is to make a real Google Apps account (and possibly pay for it), and then have the user enable forwarding inside it to the gmail in question.

    This has made me angry before, this is the future we got. Infinite hugs, dear jwz.

  35. charley horse says:

    May as well face it, eventually you will have to move everyone off gmail. Either that or surrender, Dorothy. If you play in the toilet, you get shit on your hands. Period. End of story.

  36. andyjpb says:

    On the MX where you receive addresses you either deliver "locally" or have an alias that points at

    Traditonally, in the alias case, one just "forwards" the mail to the address by keeping the message contents intact, putting the destination address in the envelope to and leaving the envelope from as it was.

    These days, aren't you expected to rewrite the envelope from in some special way?

    Having said that, the MX is allowed to originate mail (as per your SPF rule) so surely, in the case where the envelope from is an address you strictly don't need the rewriting as it's indistinguisable from a fresh mail originated on that machine? (tho maybe they can smell it from the message-id or something?)

    This totally doesn't make any sense!


  • Previously