Email Authentication Setup

In this topic, you'll learn about:

Email Sending Domain and Sub-domain Selection

The branded domain is recommended to be a sub-domain, but it can be your corporate domain as well if configured correctly. The sub-domain(s) should be unique to Eloqua and will be leveraged for sending and bounceback handling and reporting in Eloqua. Here are tips for choosing a domain/sub-domain:

  • Branded sub-domains are an opportunity to strengthen your brand recognition with your recipients. It is important to select a branded sub-domain that helps increase your brand identity, and it should be easily identifiable with your brand. Examples that you could consider (but replace "example.com" with your specific domain):
    • response.example.com
    • learn.example.com
    • go.example.com
    • e.example.com
    • Info.example.com
  • Avoid using “email”, “sales”, or “marketing” as the sub-domain or bounceback domain, because that may subject your communications to more scanning by the receiving ISPs.
  • If you have more than one brand set up for your account, you must have a unique branded domain/sub-domain for each one. It is best if the sub-domain is not in use and has not been used previously. Multiple brands is an add-on to your Eloqua contract. Contact your account manager for more information.

Note: You should not use the same email sub-domain as your Eloqua microsite(s).

Email Bounceback Address

Each email address will be used to capture bounceback responses to your Eloqua system and uses the email sub-domain created for branding. Valid bounceback responses to this email address will be captured, processed and available through the bounceback reporting tool in Eloqua (some Out-of-Office replies will be captured by this address and will be available in the Bounceback History report).

Best practice for email sending is using the same domain for the sender From address and bounceback domain.

For example, if your sending sub-domain is go.example.com, then your bounceback domain could be return@go.example.com or bounce@go.example.com.

Email Defaults: From and Reply-to Address

While both the From and Reply-To Email Addresses can be set at the individual email level in Eloqua, we configure the default settings to ensure that all of your emails are sent with this information specific to your company.

The Default From Email Address appears in the From line in the recipient’s Inbox. It is recommended that this email address has the same sub-domain as the bounceback address for optimal inbox placement. Lack of consistency with domains could cause ISPs to identify your email as spam.

The Default Reply-To Email Address is used when a recipient replies to an Eloqua email. This email address must be a valid email address where responses can be accepted and monitored.

Note: The From and Reply-to emails can be changed per email but should align with the bounceback domain. The bounceback domain can also be changed if multiple domains have been configured.

Sender Policy Framework (SPF)

SPF is an open standard for preventing sender address forgery. Senders publish a record in the Domain Name System (DNS). The SPF record consists of a list of IP addresses that are authorized to send email for that domain. ISPs can then verify a sender by cross checking the domain in the from address against the registered DNS record. By declaring authorized IP addresses, companies can help prevent email address forgery.

As part of the DNS setup when deploying Oracle Eloqua for your organization, your IT department created SPF records for your organization's sub-domains and Oracle Eloqua IP addresses.

See this knowledge base article for more information on how to implement SPF.

DKIM

DKIM (Domain Keys Identified Mail) is a cryptographic signature-based type of email authentication. DKIM requires email senders' computers to generate "public/private key pairs" and then publish the public keys into their Domain Name System (DNS) records. The matching private keys are stored in a sender's outbound email servers, and when those servers send out email, the private keys generate message-specific "signatures" that are added into additional, embedded email headers.

ISPs that authenticate using DKIM look up the public key in DNS and then can verify that the signature was generated by the matching private key. This ensures that an authorized sender actually sent the message, and that the message headers and content were not altered in any way during their trip from the original sender to the recipient.

To use your corporate domain with Eloqua signature rules which sends emails on behalf of our sales team, your IT team will need to add the public key to the corporate domain.

Feedback Loop

Following DKIM setup, you should contact support to initiate the feedback loop setups. Then the Oracle team will enable the Yahoo Feedback Loop, Microsoft SNDS, and JMRP for your emails. This will allow you to see complaint data from these managed domains in the SPAM Unsubscribe List report in Eloqua, and will also ensure that those email addresses are automatically unsubscribed in your Eloqua database. Without DKIM signing, your emails are not eligible for setup on for these feedback loops.

  • As part of the initial setup, you/your IT team will receive a confirmation email as part of this process. This email will include a link that you need to click as part of the setup process.

Note: The customer must submit an SR to deliverability team for completion of setup with the feedback loop ISPs.

Note: Eloqua enables feedback loops for other ISPs on your behalf.

Transport Layer Security (TLS)

TLS refers to encryption of web traffic between Oracle’s server and the recipient’s server. TLS enhances the privacy between sender and recipient.

Normal email traffic is not encrypted. This leaves the risk that snoopers could easily intercept messages in transit. TLS ensures all communication is scrambled in such a way that messages cannot be snooped easily.

Oracle Eloqua implements best-effort TLS for all customers so that email traffic is encrypted whenever the remote server supports encryption.

DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a policy based email authentication. DMARC advertises to ISP’s which support the protocol how to treat email’s which may fail either SPF / DKIM and who might trying to phish or spoof email’s using your brand. ISP’s lookup the DMARC record in DNS and action the policy specified, for example you may specify to quarantine emails which fail DMARC alignment, and to also send failure reports to a given email address. DMARC must live in the FROM domain’s DNS.

Note: Eloqua recommends that all senders use DMARC as it is an industry best practice in regards to authenticating messages. With that said, it is important to note that all Eloqua customers are responsible for the implementation, configuration, and monitoring of their DMARC records & reporting. Eloqua does not provide specific DMARC records for customers, as this process is to be completed outside of sender’s standard configuration. Contact support for any additional questions regarding DMARC via a My Oracle Support Service Request (SR).

Learn more

Email Authentication

IP Warming