Skip to content
Signet
Start free

salesforce.com

Receivers are told to reject mail that fails authentication for this domain.

Enforced

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.

134 DNS queries · 1942 ms

Fix these first
  1. 1
    Could not verify DKIM signing for Salesforce Marketing Cloud
    Confirm DKIM is switched on in Salesforce Marketing Cloud, then add your selector here so every future scan can verify it directly.
  2. 2
    Selector 'google' uses a 1024-bit RSA key
    Rotate to 2048-bit at your next key rotation.
  3. 3
    Selector 'mandrill' uses a 1024-bit RSA key
    Rotate to 2048-bit at your next key rotation.
  4. 4
    Selector 's2' uses a 1024-bit RSA key
    Rotate to 2048-bit at your next key rotation.

Identity ·Sending services detected

Read from your SPF includes and MX hosts, then checked for a published DKIM key.

Google WorkspaceSPF include:_spf.google.comkey published · google
ProofpointMX mxa-00177002.gslb.pphosted.com · MX mxb-00177002.gslb.pphosted.com
Salesforce Marketing CloudSPF include:_spf.salesforce.comno DKIM key at its selectors

Identity ·DMARC

v=DMARC1;p=reject;fo=1:d:s;pct=100;rua=mailto:[email protected],mailto:[email protected];ruf=mailto:[email protected]
Policy
reject
Coverage
100%
Alignment
dkim=r spf=r

Identity ·DKIM

111 selectors probed

googleGoogle WorkspaceRSA 1024
mandrillMailchimp TransactionalRSA 1024
s1SendGridRSA 2048
s2SendGridRSA 1024
m1MarketoRSA 1024

Identity ·SPF

Worst-case evaluation across every include.

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all
DNS lookup budget4 / 10
  • include:_spf.google.com
  • include:_spf.salesforce.com

Findings (12)

MediumCould not verify DKIM signing for Salesforce Marketing Cloud›

Salesforce Marketing Cloud was detected via SPF include:_spf.salesforce.com, so it is authorised to send mail as salesforce.com. We checked the selectors it uses by default (sfmc1, sfmc2, exacttarget) and found no key. Salesforce Marketing Cloud lets you choose your own selector name, so this may simply mean yours is custom. If signing genuinely is not enabled, mail through this service will fail DMARC once forwarded.

What to do

Confirm DKIM is switched on in Salesforce Marketing Cloud, then add your selector here so every future scan can verify it directly.

RFC 6376

MediumSelector 'google' 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.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

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.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

MediumSelector 's2' 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.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

MediumSelector 'm1' 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.

What to do

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.

What to do

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.

What to do

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.

What to do

Publish a TXT record at _mta-sts.salesforce.com and a policy file at https://mta-sts.salesforce.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.

What to do

Publish 'v=TLSRPTv1; rua=mailto:<address>' at _smtp._tls.salesforce.com.

RFC 8460

LowBIMI has no Verified Mark Certificate›

Gmail requires a VMC (the a= tag) before it will display a BIMI logo. Without one, only a handful of receivers will show it.

What to do

Obtain a VMC from an authorised issuer and add it as the a= tag.

LowNo CAA record›

Any certificate authority in the world may issue a certificate for this domain. A mis-issued certificate can be used to intercept mail on the wire and to impersonate your domain over HTTPS.

What to do

Publish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"

RFC 8659

InfoEligible for DANE›

Your zone is signed, which is the hard prerequisite for DANE. Publishing TLSA records for your MX hosts would let sending servers pin your certificates without relying on the public CA system.

What to do

Publish a TLSA record at _25._tcp.<each MX host> matching your MX certificate.

RFC 7672

Show 10 passing checks
PassAggregate reporting is configured›

Aggregate reports are requested at: [email protected], [email protected].

PassExternal report destination vali.email is correctly authorised›

Authorised by salesforce.com._report._dmarc.vali.email

PassExternal report destination inbox.ondmarc.com is correctly authorised›

Authorised by salesforce.com._report._dmarc.inbox.ondmarc.com

PassExternal report destination inbox.ondmarc.com is correctly authorised›

Authorised by salesforce.com._report._dmarc.inbox.ondmarc.com

PassDMARC policy is p=reject›

Mail failing authentication is rejected outright. This is the correct end state.

PassSPF lookup count is healthy (4/10)›

Worst-case evaluation stays within the limit with headroom to spare.

PassGoogle Workspace's DKIM key is published at google._domainkey›

Detected via SPF include:_spf.google.com. A valid public key for this service is published at google._domainkey.salesforce.com.

Pass5 DKIM key(s) published›

Found at: google, m1, mandrill, s1, s2.

PassSelector 's1' uses a 2048-bit RSA key›

Key length meets current guidance.

PassZone is signed and validates›

A validating resolver reported this zone's answers as authenticated. Resolvers that validate DNSSEC reject a tampered answer for your SPF, DKIM and DMARC records rather than pass it on. This also makes DANE available to you.

Transport and zone

Where your mail lands, and whether the DNS carrying your records can be trusted.

MXmxa-00177002.gslb.pphosted.com, mxb-00177002.gslb.pphosted.com
Reverse DNSforward-confirmed on every host
MTA-STSnot published
TLS-RPTnot published
BIMIpublished
DNSSECsigned · chain validates
CAAno record · any CA may issue
DANEno TLSA records

This is the configuration. It is not the whole picture.

A DNS scan cannot tell you whether salesforce.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.

Watch this domain, freeCheck another domain
salesforce.com scores A for SPF, DKIM and DMARC · Signet