Configuring SPF
Sender Policy Framework (SPF) is an internet standard for email to reduce spamming and other fraudulent emails by specifically identifying which Internet hosts are allowed to originate email for email addresses within a specific domain name. Since spamming and phishing attacks primarily use forged sender email addresses to lure the victims into opening dangerous emails (since they appear to be from trusted friends, colleagues, or businesses), SPF prevents this by allowing receiving email servers to reject emails that come from hosts that should not be originating emails with certain sender email addresses, therefore preserving the trustworthiness of those email addresses' domains.
SPF works by having the owner of the domain name specifically identify which public Internet hosts are allowed to originate email for addresses in that domain. For example, if the example.com domain owner only wanted the host mx.example.com to be able to publicly send emails from anyone with a user@example.com email address, they could specify that with SPF, so any other computer that attempted to send example.com emails would have their email discarded when the SPF-compliant receiving email server received the forged email.
SPF-compliant receiving email servers look up the sending email address's domain name, and see if an SPF record is specified. If so, the computer attempting to send the email is cross-checked against the list of authorized Internet addresses in the SPF record; if the sending computer is not authorized, the email can be rejected or classified as spam.
Note that SPF is not used within a corporate intranet; it is implemented at the firewall border between a company’s intranet and the global Internet. This is why company-originated emails go to the Internet through a specific border public email server (or redundant cloud of servers), and are similarly received by a single publicly-exposed entry point into the company.
Emails supposedly from domains that do not use SPF probably will not be trusted, as the domain owners appear too careless to prevent forgeries in their name.
Transportation and Global Trade Management can send automated emails to many users for many different reasons, and such emails have to have a sender email address. If the sender email address is not left to the standard installation setting for an Oracle Cloud deployment, such emails will appear as forged to the recipients' email server because the email server associated with the Transportation and Global Trade Management application server may not be on the SPF-authorized list for the Internet domain name of the sender email address.
Hence, for every sender email address configured into a Transportation and Global Trade Management deployment, not only do they have to be registered with the Oracle email service (through the registration web page in the Transportation and Global Trade Management web UI), but the Oracle public outbound email servers have to be listed as authorized email originators in the SPF records for the email addresses' domains.
This requires contacting the parties within your organization responsible for maintaining your organization’s domain name records, and asking them to add an SPF directive to your domain name's SPF record authorizing the Oracle public email servers to send email on behalf of the configured Transportation and Global Trade Management sender email addresses in that Internet domain.
Oracle has created publicly posted SPF sublists of the Oracle Cloud public outbound email servers that can be conveniently included by reference in your domain name's SPF record.
The SPF is dependent on the geographic region where your service deployed. Refer to the following table to determine the correct SPF record corresponding to your region.
| Sending Region | SPF Record |
|---|---|
| Americas | v=spf1 include:rp.oracleemaildelivery.com ~all |
| Asia/Pacific | v=spf1 include:ap.rp.oracleemaildelivery.com ~all |
| Europe | v=spf1 include:eu.rp.oracleemaildelivery.com ~all |
| All Commercial Regions | v=spf1 include:rp.oracleemaildelivery.com include:ap.rp.oracleemaildelivery.com include:eu.rp.oracleemaildelivery.com ~all |
| Government Regions |
|
Do not use only the directive above as your entire SPF record unless you are using the Oracle Cloud as your sole email service provider; otherwise, specifying only the Oracle Cloud SPF directive may block your other legitimate email servers. For example:
v=spf1 a:mx.example.com include:spf_c.oraclecloud.com -all
would specify for the example.com domain that their public email gateway (mx.example.com) and the Oracle Cloud email gateways are permitted to send emails for the example.com domain, and all other hosts should be rejected as probable spam forgers. Consult Internet RFC 7208 for technical details about specifying the contents of your SPF record.
If your domain has a large quantity it may be necessary or even desirable to create a new domain or subdomain that is specifically intended for Oracle Cloud email, i.e. "mail.example.com". You should use this domain for your Approved Sender, i.e. "no-reply@mail.example.com".
The status of each sender email address used by the system can be monitored to ensure it has an associated SPF record in the customer’s domain. A performance collector, MAIL COMMUNICATIONS, keeps track of every sender email, showing the status of each email address from the perspective of the domain.
You can review your SPF configuration with a public service like dmarcian.