SPF and Sender ID

considerations with
Oracle Service Cloud
sites
Answer ID 2489 | Last Review Date 04/18/2016

What are SPF and Sender ID and how do

they affect our Oracle Service Cloud site?
Environment:
Sender Policy Framework (SPF)
Resolution:
Sender Policy Framework (SPFv1) and Sender ID (also known as SPFv2) are two email
authentication technologies that use Domain Name System (DNS) to specify which servers
are allowed to send email on behalf of a particular domain name. The two technologies
share common heritage and are almost identical in how they work. The main difference is
how the receiver determines who (what domain) is the sender. SPFv1 uses the domain in
the envelope sender address (the MAIL FROM: portion of an SMTP transaction), while
Sender ID uses the Purported Responsible Address (PRA).
Note: As of the August 2014 release, Oracle RightNow CX is referred to as Oracle Service
Cloud.
For your Oracle Service Cloud mailboxes, you will need to publish an SPF record in one or
both of the following cases.
1. The domain specified in the Envelope From/Bounce Address field (on the
Mailboxes editor's outgoing email settings) is branded to your organization's
domain.

2. The domain specified in the Friendly From/Branded Address field (on the
Mailboxes editor's outgoing email settings) is branded to your organization's
domain.
For more information and complete procedures, see Email Management in the online
documentation for your release.
Note: Publication of the original Sender ID records are no longer used and many email
services no longer support it. This does not have any effect on previous releases because
the records that are published are not referenced when authenticating a domain.
Therefore, there is no impact on sites that still publish Sender ID. Sender ID verification is
now done by publishing SPF records for your PRA address.
SPF uses a TXT resource record associated with the domain name portion of an email
address to query the DNS. Your organization's email delivery policy is specified by defining
the IP hosts that are allowed to send on behalf of your domain name. It should also specify
how you will handle failures. Receiving email servers that are configured to check for SPF
records verify that the sending server is authorized according to the policy defined within
the SPF record for the sending domain name.
Important: If the domain in the Envelope From/Bounce Address field or the Friendly
From/Branded Address field (on the Mailboxes editor) is not the email address that was
provided when your account was set up, your IT department will need to publish the SPF
record in your DNS. Email messages that fail SPF validation are much more likely to be
regarded as SPAM and may be deleted or moved to junk folders. If you suspect this is
happening, contact your IT group to evaluate your SPF records. If you are using the email
address that was provided when your account was set up, all SPF record publication has
been done and no further action is required.
How does it work in practice?
The simplest way to be SPF-compliant is to include the following statement into your
existing SPF record: include:rnmk.com.
This Include statement covers all IPs used by Oracle Service Cloud mail servers.
The following example shows what you should publish in your SPF record. This example
applies to Service email as well as Outreach and Feedback email.
Important: Keep in mind that this example shows only the information that allows email to
be sent from Oracle Service Cloud mail servers. If you use mail servers outside of Oracle

Service Cloud, you must you publish an SPF record defining the IP hosts that are allowed
to send on behalf of your own mail server's domain name.
Example: As the director of customer service for Widgets R Us, you want to send email
from your hosted Oracle Service Cloud site to your customers, and you want to brand your
email so that your customers see "offers@widgetsrus.com" in the email's From address.
Action: Define SPF records in the widgetsrus.com DNS as follows:
widgetsrus.com IN TXT "v=spf1 include:rnmk.com ~all"
In this example, hosts identified in the rnmk.com SPF record are allowed to send on behalf
of widgetsrus.com. The final entry, "~all," defines the policy that will be used. In this case,
all email originating from hosts listed in the rnmk.com SPF record that use the domain in
the example will be accepted as legitimate sources of email for widgetsrus.com. If the
receiver identifies email coming from a host that is not listed in the SPF record, the receiver
should soft fail those emails.
Important: If you use a branded email address for your Outreach and Feedback mailings,
all replies (including responses and general replies if the Reply-To Address is also
branded), will be routed through the branded server's MX server. In addition,
if the Envelope From/Bounce Address field on the Mailboxes editor's outgoing email
settings is branded, then all bounces will be routed to the branded domain's MX server. If
high-volume emails are planned, this could cause a spike in incoming mail traffic on your
corporate servers. Additionally, all hosted mailboxes, any mailbox with "rnmk" or "custhelp"
in the pop server field, should retain the Oracle hosted email address in the Envelope
From/Bounce Address field. Only Reply To or Friendly From/Branded Address can contain
your branded domain on a hosted mailbox.
Note: Since the statement, include rnmk.com, references the rnmk.com SPF policy, this
causes the receiving mail server to validate the include statement by performing the
following DNS lookups.
1. rnmk.com TXT record (this reveals the allowed hosts and triggers the next 5
lookups)
2. A record
3. MX record
4. spf-a.rnmk.com
5. spf-b.rnmk.com

6. spf-c.rnmk.com
In this case, a total of 6 lookups are performed by the mail server. The SPF limit on DNS
lookups is 10. Therefore, if adding the include rnmk.com statement causes your SPF
record to exceed the 10 DNS lookup limit, submit an incident to our support site to have
your SPF record reviewed.
Full Specifications
For more information on SPF, see http://www.openspf.org/ and http://www.rfceditor.org/rfc/rfc4408.txt
For more information on Sender ID,
see http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx