I believe that DNS settings (at least for superuser.com) is incorrect.

DNS's TXT record for SPF on superuser.com is (as of Jule 18, 2018):

superuser.com.          300     IN      TXT     "v=spf1 -all"

that tells all email servers in the world that domain superuser.com - don't sent emails and asking receiving servers to reject any emails that comes as [email protected], but in fact emails sent via mx-out.stackexchange.com from user: [email protected]

There also no MX record for superuser.com that authorize email server that sends emails for domain superuser.com

So, as result receiving email server reject emails that sent kinda from superuser.com: (I replaced real recipient's email address for obvious reason)

policyd-spf[91067]: None; identity=helo; client-ip=; helo=mx-out.stackexchange.com; [email protected]; [email protected]
policyd-spf[91067]: Fail; identity=mailfrom; client-ip=; helo=mx-out.stackexchange.com; [email protected]; [email protected]
postfix/smtpd[90542]: NOQUEUE: reject: RCPT from mx-out.stackexchange.com[]: 550 5.7.1 <[email protected]>: Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.org/Why?s=mfrom;[email protected];ip=;[email protected]; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mx-out.stackexchange.com>

So, some1 @stackexchange who is responsible for email servers need to read this:

http://www.openspf.org/Why?s=mfrom;[email protected];ip=;[email protected]

As a suggestion - all stackexchange's sites need to authorize mx-out.stackexchange.com as their primary MTA by adding to DNS MX record that point to mx-out.stackexchange.com and adjust SPF record that tells other servers in the world that mx-out.stackexchange.com or IP(s) of your MTA are only responsible to send emails for all forums.

Or at least set (I hope as temporary fix)

superuser.com.          300     IN      TXT     "v=spf1 ~all"

so emails would be tagged on receiving side as SPF rule violation but at least would be passed to recipient instead of telling other servers in the world to reject emails that comes from [email protected].

1 Answer 1


Thanks for the heads up. We shouldn't have been sending emails from @superuser.com at all. Everything is now (well as of yesterday) sent from @stackoverflow.email which has a correctly configured DMARC policy.

  • And now all of a sudden, gmail is complaining that mail that I redirect to them from stackoverflow.email is violating DMARC -- I'm guessing this change is why. So I changed my global email setting to go straight to gmail, but all my alerts are still coming via the redirection and bouncing. Any suggestions? Commented Sep 10, 2018 at 0:42
  • @FredDouglis which alerts are you referring to?
    – Dean Ward
    Commented Sep 10, 2018 at 8:17
  • Posts matching my filters Commented Sep 10, 2018 at 11:39
  • In addition, it's worth noting that the "newsletters" are going to the new address, while the "posts matching your filter" emails are going to the old one. Commented Sep 11, 2018 at 19:12
  • @FredDouglis urgh, yes you've noticed the one area we haven't fully ported yet. It's on the radar just not for a little while longer yet
    – Dean Ward
    Commented Sep 11, 2018 at 20:21
  • Aha. OK, I'll just miss the alerts in the meantime... thanks. Commented Sep 11, 2018 at 20:25
  • Dean, on thing not to “port” and another not to take an email update and apply it. Isn’t that straightforward? And if not, could you do a one-off database update to reconcile? Commented Sep 18, 2018 at 11:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .