Contact data for

Good afternoon,

So I’m looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list.

Best Regards,

Daniel Walters

You are not alone sir, for reasons as yet unknown has recently started blocking my range as well.
If I make progress in contacting someone with clue I will pass that information along privately.

Sam Moats

If you haven't done this yet - start with the outlook postmaster troubleshooting documentation and open a support ticket with them.


You may also try the mailops list.

Here are some suggestions for improvements, for both of you, below...

Many postmasters (/networks) out there, are actually very strict on RFC
/ BCP compliance, where the slightest violation equals potentially
severe consequences:

Looking at, the domain itself has the caveat of going
directly against the Internet's RFC2182 / Best Current Practice #16.

... Are you by any chance using "Mail in a Box", or any of the other
packages, where the maintainers do not wish to follow standards / BCP's,
but instead suggests their users to ignore those?

-> Recommendations - Improvements - Mail-in-a-Box Forum

Those "temporary network glitches" the author actually mentions having
"from time to time", is the exact consequence of violating the RFC2182 /
Best Current Practice #16.

I would be very happy to see the whole world reject for such things like
that. Or said in another way: if you don't care enough about your own
stuff - why should any third party care about it, at all? :slight_smile:

Next, it seems like your mail server DKIM signed your message, however,
there is no DKIM record on the relevant ""
TXT record, it yells DKIM.

Literally, for what seems to be against all kind of advice from the
whole email community, it seems like your server is actually rewriting
the client's original IP address ("Received:" header), to one of your
server's IP addresses, perhaps for some privacy reasons:

Received: from authenticated-user ( [])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(No client certificate requested)
by (Postfix) with ESMTPSA id 59CE72A001B;
Tue, 9 Mar 2021 12:07:56 +0000 (UTC)

When Google (MX records of @NANOG.ORG) got your message, it arrived to
Google, from another IP address, with a dynamic / generic looking
hostname. This IP address was not authorized by your SPF record.

Received: from ( [])
by with ESMTPS id i8si2272841qki.324.2021.
for <>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 09 Mar 2021 04:07:57 -0800 (PST)

Received-SPF: neutral ( is neither permitted nor
denied by domain of client-ip=;

dkim=temperror (no key for signature) header.s=mail
spf=neutral ( is neither permitted nor denied by
domain of

Literally no kind of authentiation (valid SPF, valid DKIM, ...), at all.
Rumours goes that is strict at SPF.

Ideally, your SMTP HELO/EHLO name should be identical to the PTR,
"" is not equal to "" above.

For both of you, I would actually lean towards cleaning up / maintaining
your SPF records a little better:

- Always use ip6: ip4: directives for your own (static) mail servers.
- Then add the include: or whatever mechanisms that your third parties
require you to, for example "", *** if they are
really needed, at that specific (sub)domain level ***.
- Then end your record, preferably with "-all" (hardfail), but
absolutely minimum of softfail. As restrictive as possible.

Sam, it sounds like you have at least the IPv4 /30 subnet (adapt it to
match your subnet), so a SPF like this, would be what I would do for

"v=spf1 ip4: ip4: ip4:

Dan, as for yours, on "":

v=spf1 ***mx*** ***a*** ***ip4:*** ip4:
ip4: ip4: ip4:
ip4: ip4: ip4:
ip4: ip4: ******

***mx***: You are using Office 365 as inbound (MX) records, the bigger
ones are separate inbound/outbound servers, so take away this useless one.
never send any emails on your domain's behalf, so take away this useless
***ip4:***: See next, but chances are you should leave
this one.
already authorized IP address, meaning you are authorizing
"ip4:" twice, so take away this useless one.
***~all***: I would also here lean towards e.g. -all (hardfail).

I have been running "-all" (hardfail) since forever, literally since SPF
was created, and motivated everyone around me to do the same, and so far
without any issues.

As for the classic forwarding issue, you can ask yourself - if the
bigger ones like PayPal, Bank of America, and so on, are NOT going to
set less restrictive policies due to for example bad forwarders, ... why
should you?

It's an issue of the postmaster at the forwarding service, and the final
destination, and for those two to figure out how to mitigate / override,
if necessary, - and not something you should potentially be reducing the
"security levels" from your end, to fix their (potentially crappy)

That's just a few things you could look at fixing, which would
definitely be improving your *chances* of good deliverability, although
they still won't guarantee any deliverability at all.

Just my two cents.

Good news on our front, Microsoft did respond to cCircleNet's request and has cleared the issue.
Thanks for all of the feedback.

Sam Moats