Architecture,

Sender Policy Framework and Fusion SaaS

November 5, 2020 | 8 minute read

Bill Jacobs

Text Size 100%:

－＋

Make Sure Email Sourced from Oracle SaaS Applications Gets to Recipient Inboxes

Note: In order not to overload references to the customer persona, which could possibly confuse readers, in the discussion below I use the word “subscriber” to refer to an organization that has subscribed to Oracle Fusion SaaS (aka Oracle’s cloud customer), while I use the word “customer” to refer to subscribers’ customers, who in fact are the entities being managed within the SaaS applications. HTH.

The SaaS takeover has arrived! For all but a few stragglers, enterprise IT managers, directors, and CIO's are replacing their organizations’ on-premise applications with software-as-a-service (SaaS) subscriptions. The incentive: they can reduce or maybe even eliminate the infrastructure costs associated with running on-premise applications. Why? The “Service” piece of SaaS not only covers designing, developing, and enhancing cloud applications; it also covers hardware purchasing, hardware maintenance, application provisioning, application updates, patches, not to mention monitoring, auditing, and resizing. With SaaS providers doing this much providing on so many fronts, and taking care of all the related hardware and software as well, it adds up to huge potential savings for enterprise IT departments.

Wait -- it gets even better for SaaS subscribers. Because Oracle manages the entire cloud infrastructure, Oracle is also responsible for much of the related hardware and software that SaaS applications depend on to meet subscribers' needs. Email is a perfect example: applications use the cloud email relay infrastructure that is bundled with SaaS subscriptions. Subscribers do not need to be involved in how email gets sent from, or is received by, Fusion SaaS applications. From their perspective it just happens, and that is all they need to know.

Subscribers cannot be entirely hands-off with email setup however, especially if they want to personalize email content. How important this business requirement is varies by Fusion pillar. Email interfaces are rather limited in an ERP application, for example, where email is used to route notifications, workflows, and approvals to end users. While having these email interfaces available in Fusion ERP certainly increases user productivity and efficiency, they are not essential for ERP’s main business requirements. On the contrary, the role of email is crucial in the Fusion SaaS B2B Service application, another pillar, where email is typically one of the main channels used for communications back and forth between support engineers and customers who need help.

In addition to configuring email options and behaviors from within Fusion SaaS applications, depending on how outbound email is personalized, subscribers may also need to perform additional setup outside the applications, augmenting their enterprise Domain Name System (DNS) records to align with how outbound email gets sent from Oracle Cloud SaaS applications. This blog post offers more details around email configuration outside of the application, especially when modifying DNS is necessary. There will be a follow-up to this post, where the focus will be on application-specific email configuration areas that have been a bit confusing and/or problematic for Oracle SaaS subscribers.

SPF: Sender Policy Framework

There are several use cases where Oracle SaaS subscribers may want to modify the headers and envelopes, especially the “From” addresses, in emails that get sent from Fusion SaaS applications. Specifically, they usually want to change the sending address in these emails to one that reflects their organization’s identity, instead of sticking with the default Oracle-sourced “From” address that exposes the use of Oracle’s cloud infrastructure to their customers and contacts. The business incentive driving this business need is totally reasonable and valid: sending emails to enterprise customers with a company-specific “From” address adds additional positive branding to the emails, while sending emails with the default Oracle-sourced “From” address has the potential to confuse end recipients or even cause them to question the legitimacy of the emails. For Fusion SaaS B2B Service pillar subscribers, the ability to customize outgoing email is critical, as the application leverages email extensively to manage the service request process with their customers from beginning to end. (Customizing outbound email could also be just as desirable in Oracle marketing-related SaaS applications (non-Fusion), where targeted email campaigns are used to convert leads to sales opportunities.)

But there is a problem with this business requirement that needs additional attention. Ignoring the totally legitimate motivation for this configuration change for a moment, from a purely technical perspective, what is the difference between Oracle Fusion SaaS applications sending emails from an acme.com domain versus someone doing the same thing, whose intent is to hide their real identity by sending emails with a forged “From” address? Commonly used in phishing attacks and email spam, this spoofing technique likely has been around since shortly after email gained a foothold on the Internet, and it has victimized millions of email users. Although there is no pure technical difference between one domain sending email with a non-owned domain “From” address and what has come to be known as email spoofing, there is a huge difference in context and intent. The former is a justified business requirement while the latter is criminally motivated.

Maliciously-motivated email spoofing on the Internet has become a huge problem over the years. In 2014, the Internet Engineering Task Force (IETF) formulated a proposed standard, RFC 7208, to mitigate the situation. This proposal, commonly known as the Sender Policy Framework (SPF), is a solution that allows for an automated way of checking email and determining what is legitimate and what may be malicious when the sending address domain differs from the server’s sending domain.

SPF makes it possible, without human intervention/interpretation, to differentiate between the justified use of emails sent from an alternate domain versus using spoofing for malicious purposes. SPF leverages the Domain Name System (DNS) infrastructure to register external servers that are authorized to send email on behalf of an owned domain. With this registration system in place, the email relay servers anywhere on the Internet can check emails sent with a non-owned sender address and check DNS to see if the source servers are on the SPF list and therefore valid. If so, the emails are relayed. If not, emails can be tagged as suspect, email forwarding can be blocked, and the offending source servers become candidates for blacklisting if similar incidents repeat themselves. (Refer to the graphic below for clarification on the SPF process.)

If sending non-Oracle-domain emails from Fusion SaaS is a subscriber business requirement, the best practice is to begin with the SPF setup prerequisites, which includes making required modifications to DNS records. Starting with the Internet infrastructure configuration ensures that there is no possibility that subscriber-domain emails can trigger events that could culminate in a relay server getting blacklisted, or worse, negatively affecting the reputation of the subscriber’s domain.

The assumption is that at least basic SPF setup is already in place for the enterprise domain, as the proposed standard has been in existence for years, so it has had time to get socialized in IT departments. But more importantly, without a certain measure of SPF protection in place, enterprises are keeping their doors wide open to anyone who wants to forge non-owned domain email addresses and use that capability for any purpose, legitimate or not. Thus it seems highly unlikely that organizations utilizing Internet email have not already configured SPF to protect their email reputations.

Adding this record to the enterprises DNS (as a TXT record) will add Oracle’s relay server IP addresses to the organization’s DNS SPF sub-section:

include:spf_c.oraclecloud.com

Note that this include reference is a pointer to another URI endpoint and not a hard-coded list of servers, so enterprise IT administrators will not have to maintain their DNS if Oracle SMTP relay server IP addresses ever get updated. The tradeoff with the indirect references, however, is that resolving the sub-references, making calls to DNS to resolve server names to IP addresses, may violate the maximum ten DNS lookups per SPF check that are allocated by the IETF standard. If that turns out to be an issue (which depends largely on the existing volume of other SPF includes), there is an option is to file a service request with Oracle support for an alternative method of supporting the necessary server includes for Oracle SaaS.

Note: Oracle Cloud SaaS subscribers who might want to use “From” addresses managed by a generic email provider (e.g. Yahoo, Gmail, Hotmail, and the like) will likely hit a dead end with SPF, as there is a near-zero probability that these email providers will ever entertain the need of adding Oracle Cloud email servers to their DNS SPF records.

Once the SPF configuration has been completed, it is possible (and recommended) to check the DNS setup for accuracy and proper operation. This web site, https://stopemailfraud.proofpoint.com/spf/, analyzes DNS for a given enterprise and provides a list of servers that have been given permission to send emails on the enterprise’s behalf.

After DNS SPF-related records have been modified and tested for proper and expected behavior, it is then safe to make the application-specific Fusion SaaS configuration changes necessary to implement the custom domain “From” address. These configuration tasks from inside the Fusion application will be the subject of a subsequent post.

Additional Means of Securing Email

SPF represents the first line of defense against malicious email spoofing. Related IETF work in the email security realm has also produced RFC 6376, DomainKeys Identified Mail (DKIM) Signatures, which became an Internet Standard in 2011. In addition, although it has not been promoted to a full standard yet, details for the Domain-based Message Authentication, Reporting and Conformance (DMARC) proposal have been collected in RFC 7489 (~2015).

Like SPF, DKIM is configured in the enterprise domain’s DNS. The first step is to have sending email servers add a digital signature, using a private key, to the headers of outbound email messages. This signature can then be validated by the receiving/Inbound SMTP server against a public cryptographic key that has been added as a TXT record to the sending domain’s DNS. Leveraging cryptography and the private/public key pairs, DKIM can authenticate the entire email instead of focusing exclusively on the sending address.

Neither SPF and DKIM have anything to say about what should happen to emails that fail verification. DMARC takes over here, adding a means of setting up policies for SPF and DKIM. Also, there are recommendations about how to set up reporting capabilities so that statistics for sending email domains can be aggregated from data supplied by receivers of email.

Non-Fusion Oracle SaaS applications – Eloqua, Responsys, Taleo, and B2C Service, for example -- support DKIM and DMARC today. Fusion Oracle SaaS applications do not yet support DKIM, but because DMARC can be set up to use SPF authentication exclusively without a dependency on DKIM, DMARC is a partial option for Fusion SaaS.

In addition to the IETF RFC’s and standards, it should be mentioned that the email routing structure in the Oracle SaaS cloud supports opportunistic TLS communications between SMTP gateways and subscriber mail endpoints. This configuration is the best possible compromise of security with guaranteed sending, as TLS encryption is used whenever it is possible to do so, but gateways will fall back to unencrypted transmission if necessary.

Summing Up

Oracle recognizes that SaaS subscribers often want to improve their brand recognition in the eyes of their customers by adding senders’ domain addresses to emails that reinforce organizational identity. Most email users on the Internet have probably experienced SPAM, spoofing, and/or phishing, which makes it imperative that legitimate emails sent by Oracle SaaS on behalf of a subscribing organization pass all checks that have been put in place to protect recipients from malicious attacks. Correctly setting up Sender Policy Framework in DNS, and optionally adding DMARC policies to SPF, will increase the likelihood that enterprises can leverage email to their advantage, ensuring that their customers have positive experiences with email sent from Fusion SaaS.