oracle.com
Receivers are told to reject mail that fails authentication for this domain.
Receivers are told to reject mail that fails authentication for this domain. Keep watching aggregate reports so a new sending service does not silently start failing.
Score held up: DMARC is enforcing at p=reject, so nobody else can send as this domain. That is the hard part, and it is done. What is left below is about your own mail arriving, not about anyone spoofing you.
140 DNS queries · 1638 ms
- 1Selector 'mandrill' uses a 1024-bit RSA keyRotate to 2048-bit at your next key rotation.
- 2SPF uses exactly the full lookup budget (10/10)Reclaim headroom now by removing unused includes or replacing one with the ip4/ip6 ranges it resolves to.
- 3CAA has no reporting addressAdd a record such as: 0 iodef "mailto:[email protected]"
- 4No explicit subdomain policy (sp=)Consider adding 'sp=reject' if no subdomain sends mail.
Identity ·Sending services detected
Read from your SPF includes and MX hosts, then checked for a published DKIM key.
Identity ·DMARC
- Policy
- reject
- Coverage
- 100%
- Alignment
- dkim=r spf=r
Identity ·DKIM
111 selectors probed
mandrillMailchimp TransactionalRSA 1024s1SendGridRSA 2048s2SendGridRSA 2048dkimGenericRSA 2048Identity ·SPF
Worst-case evaluation across every include.
- include:spf_s.oracle.com
- include:spf_p.oracle.com
- include:spf_r.oracle.com
- include:spf_c.oraclecloud.com
- include:spf_s1.oraclecloud.com
- include:spf_s2.oraclecloud.com
- include:spf_x.oracle.com
- include:spf.mandrillapp.com
- include:spf_z.oracle.com
- include:stspg-customer.com
Findings (9)
MediumSPF uses exactly the full lookup budget (10/10)›
The record is legal but has zero headroom. If any provider in your include tree adds a single lookup on their side, your SPF silently starts returning permerror and stops authorising your mail.
Reclaim headroom now by removing unused includes or replacing one with the ip4/ip6 ranges it resolves to.
RFC 7208 s4.6.4
MediumSelector 'mandrill' uses a 1024-bit RSA key›
1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.
Rotate to 2048-bit at your next key rotation.
RFC 8301
LowNo explicit subdomain policy (sp=)›
Subdomains inherit p=, which is usually what you want. Setting 'sp=reject' explicitly protects unused subdomains even while the parent is still at p=none.
Consider adding 'sp=reject' if no subdomain sends mail.
LowSPF ends in '~all' (softfail)›
Softfail is the correct setting while you are still discovering senders, but it asks receivers to accept unauthorised mail and merely note it.
Once your aggregate reports show no unexplained legitimate sources, tighten to '-all'.
LowNo MTA-STS policy›
Without MTA-STS, mail to your domain can be downgraded to plaintext by an active network attacker, because SMTP's STARTTLS is opportunistic by default.
Publish a TXT record at _mta-sts.oracle.com and a policy file at https://mta-sts.oracle.com/.well-known/mta-sts.txt.
RFC 8461
LowNo TLS-RPT record›
Sending servers have no address to report TLS failures on mail to your domain, so transport problems stay invisible to you until someone complains.
Publish 'v=TLSRPTv1; rua=mailto:<address>' at _smtp._tls.oracle.com.
RFC 8460
LowCAA has no reporting address›
You have restricted which authorities may issue certificates, but nobody is told when one refuses a request. An iodef address turns an attempted mis-issuance into an alert instead of a silent event.
Add a record such as: 0 iodef "mailto:[email protected]"
RFC 8659
InfoEligible for BIMI›
Your DMARC policy is already enforcing, which is the hard prerequisite for BIMI. Publishing a logo is now largely a branding exercise.
Publish an SVG Tiny PS logo plus a VMC, then add a default._bimi record.
InfoZone is not signed with DNSSEC›
This is the common case and not a misconfiguration -- most working mail domains are unsigned. It is worth knowing because your authentication records are only as trustworthy as the DNS answers carrying them, and because DNSSEC is the prerequisite for DANE.
If your DNS provider supports one-click DNSSEC, enabling it is low risk. If it does not, this is not worth changing providers over.
RFC 4033
Show 10 passing checks
PassAggregate reporting is configured›
Aggregate reports are requested at: [email protected].
PassExternal report destination emaildefense.proofpoint.com is correctly authorised›
Authorised by oracle.com._report._dmarc.emaildefense.proofpoint.com
PassExternal report destination emaildefense.proofpoint.com is correctly authorised›
Authorised by oracle.com._report._dmarc.emaildefense.proofpoint.com
PassDMARC policy is p=reject›
Mail failing authentication is rejected outright. This is the correct end state.
PassMailchimp Transactional (Mandrill)'s DKIM key is published at mandrill._domainkey›
Detected via SPF include:spf.mandrillapp.com (nested). A valid public key for this service is published at mandrill._domainkey.oracle.com.
Pass4 DKIM key(s) published›
Found at: dkim, mandrill, s1, s2.
PassSelector 's1' uses a 2048-bit RSA key›
Key length meets current guidance.
PassSelector 's2' uses a 2048-bit RSA key›
Key length meets current guidance.
PassSelector 'dkim' uses a 2048-bit RSA key›
Key length meets current guidance.
PassCertificate issuance is restricted by CAA›
Only digicert.com, letsencrypt.org, pki.goog may issue certificates for this domain, so a certificate for your mail hosts or your MTA-STS policy endpoint from any other authority would be a mis-issuance.
RFC 8659
Transport and zone
Where your mail lands, and whether the DNS carrying your records can be trusted.
This is the configuration. It is not the whole picture.
A DNS scan cannot tell you whether oracle.com’s mail actually aligns, because alignment is decided per message at the receiver. Collect DMARC aggregate reports to see every source sending as this domain.