Discussions

DKIM & Shared IP Range

Plafcan
Plafcan Posts: 10 Red Ribbon
edited Apr 29, 2022 6:20AM in Eloqua

Are any of you using the shared IP range and have DKIM authentication?  Our DMARC vendor (250ok) seems to think this should be possible, but Eloqua keeps telling us they won't allow it.

Post edited by OIT Integration User on

Answers

  • Dave Zeltser
    Dave Zeltser Posts: 34 Bronze Medal
    edited Jul 14, 2020 12:52PM

    I think for this you really should have a dedicated IP and branding package, then you will have dedicated IPs to do and share with however you wish. Of course Eloqua charges for this, but in my opinion it is well worth it.

    Dave

  • Plafcan
    Plafcan Posts: 10 Red Ribbon
    edited Jul 14, 2020 12:58PM

    Yes, you can add DKIM authentication when using dedicated IPs.  Our problem is we don't have enough volume to keep an IP warm.  We're using the shared range under Eloqua's recommendation because of that.  But when mitigating deliverability issues we're told we need DKIM.  It feels like a lose/lose situation for us with some of our clients.

  • pintudason
    pintudason Posts: 1 Green Ribbon

    On a shared IP, we'd like to have the DMARC and DKIM settings in place. This is due to three major factors:

    1) It's difficult to move with such a vast contact database. Warming up the IP takes at least 5-6 weeks, however it could take longer if you want to establish an excellent / solid reputation (sender score).

    2) In order to keep the IP warm, the instance must transmit a particular quantity of consistent e-mail volume. On all of our instances, we do not have a continuous e-mail volume. Second, we have to e-mail all contact records in less than one hour once a year (high volume sender).

    3): When we purchase an Eloqua licence, we expect Oracle to monitor and manage the IP-reputation. address's That is a method of risk management for us.

  • Tracy Traeger-Oracle
    Tracy Traeger-Oracle Senior Principal Product Manager Posts: 26 Employee

    Couple of comments here.

    First, Eloqua does not support DKIM on the shared range. Your organization will need a dedicated IP in order to accomplish this.

    As a heads-up, over the next 1-2 years, Eloqua will begin decommissioning the shared range, as this is no longer a best practice approach for optimal deliverability. Don't worry - we'll be publishing more information about this over time. But generally speaking, having your own dedicated IP, no matter your volume, is the ideal approach based on how the world of deliverability has evolved.

    The shared range is an outdated practice that relies on grouping smaller, less reputable senders together so they could establish a reputation with ISPs. Modern ISP and mail filtering technologies are much more sophisticated and can assign reputation on many more factors than just the IP address (or pool of IPs).

    Furthermore, I want to address the final statement that you expect Oracle to monitor and manage your reputation - this is a crucial flaw in approaching deliverability on a shared range. Even though Oracle owns the IPs and can do some modest mitigation, the reality is, only you can truly control and own your sender reputation. As most customers leave the shared range (we no longer allow any new customers on the range and are currently starting to reach out to some of the larger senders who impact the range) it will become less and less ideal to remain.

    I will also add that Oracle is not able to truly take on your risk management. Your reputation is stitched into everything you do as a sender - your timing, segmentation, content, opt in strategy, etc. You have the keys to manage this, and the optimal way to do that going forward will be to have your own dedicated IP.

  • Plafcan
    Plafcan Posts: 10 Red Ribbon

    We've already switched to dedicated IPs, this post is 2 yrs old.

  • Tracy Traeger-Oracle
    Tracy Traeger-Oracle Senior Principal Product Manager Posts: 26 Employee

    There was a very recent comment above which I was addressing. Apologies for any confusion.