So we have quite a few .org, .@bobjonesattorney.com, @dowjones.com email addresses in our DB. Many of these corps do not like Marketo's send IPs. In fact ... our own internal spam setup was blocking Marketo-derived emails, which made testing a chore. Ha! Ha! We solved the issue internally by whitelisting Marketo's IP addresses.
Any advice for how to approach valued clients, sponsors, partners, etc. with business-oriented addresses? We're working on a call-based outreach campaign and would like to incentivize these undeliverables into taking action that'll get them back on the rolls.
Since asking them to whitelist Marketo's Send IPs is laughable, is there anything else our call folks can suggest?
IMO, it's not good to suggest clients do anything unless there is a tight partnership. What I recommend is that you look at what you can do in Marketo to help improve your deliverability (not to definitively resolve, but to help improve).
Here are 2 product docs that Marketo offers that I use often and find are quite useful for their platform:
Some mailservers are specifically averse to marketing email, and if they can identify Marketo-originated email it's in their charter to stop it. (We run into such problems with financial services clients, since there are regulatory ramifications to allowing certain financial instruments to be advertised internally.)
It can be hard to get around such blocks in an ethical fashion: if the mailserver rule is Is Marketo email = block you aren't supposed to obfuscate the fact you're using Marketo. Even with total buy-in from the intended recipient, you don't want to do an end run around Compliance. (Like how we shouldn't pretend we aren't using Munchkin to get around browser tracking protection.)
That said, we've engineered some pretty crazy techniques to get email to partners where no one at the partner can think of a reason the email should be blocked (treating the mail infrastructure more like SkyNet than like something deliberately configured). For example, we've gatewayed certain domains via the client's own mailserver so the IP isn't identified as Marketo's. It's not something you want to do with a huge number of recipients, though, since you can't keep up with the mail flow like Marketo can.
That's pretty awesome domain trickery, but not something we're going to get into any time soon. Suppose the benefit of sharing an IP with who knows whom is being forced to maintain a healthy level of rep-to-client interaction.
deducting from your own mail server behavior is comparing apples with pies, since your mail server acts much more protective when it receives emails that were supposed to be sent from itself, but obviously weren't.
That's one of the primary reasons why you need to whitelist the IPs.
There's no "supposed to"... the fact that a server is the MX (SMTP receiver) for a given domain doesn't affect which servers are allowed to send from that domain. In fact, the MX itself might not even be allowed to send from that domain (though that's rare)!
Also, unless you're paying Marketo extra for their branded sender service, your emails come from mktomail.com at the SMTP level, not from your domain. This is why your SPF record doesn't matter with a standard subscription.
DKIM can be used to authenticate header information that includes your domain, but that's unrelated to whether the local machine also receives mail for that domain.
Only a totally broken mailserver config would require whitelisting because the From: or Reply-To: includes a domain that for which the server is an MX and/or mailbox server. A properly configured mailserver will treat Marketo-originated mail that includes your domain in the same way it treats Marketo mail in general. And that's why it's bad to whitelist Marketo, since it gives you the mistaken impression that other similarly equipped companies are getting your mail. The first level of deliverability testing should be your own server.