docusign.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.
132 DNS queries · 2288 ms
- 1Selector 'mandrill' uses a 1024-bit RSA keyRotate to 2048-bit at your next key rotation.
- 2Selector 's2' uses a 1024-bit RSA keyRotate to 2048-bit at your next key rotation.
- 3Selector 'smtpapi' uses a 1024-bit RSA keyRotate to 2048-bit at your next key rotation.
- 4Selector 'mailo' uses a 1024-bit RSA keyRotate 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.
Identity ·DMARC
- Policy
- reject
- Coverage
- 100%
- Alignment
- dkim=r spf=r
Identity ·DKIM
111 selectors probed
googleGoogle WorkspaceRSA 2048mandrillMailchimp TransactionalRSA 1024s1SendGridRSA 2048s2SendGridRSA 1024smtpapiSendGridRSA 1024mailoMailgunRSA 1024m1MarketoRSA 1024Identity ·SPF
Worst-case evaluation across every include.
- include:_spf.google.com
Findings (9)
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
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.
Rotate to 2048-bit at your next key rotation.
RFC 8301
MediumSelector 'smtpapi' 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
MediumSelector 'mailo' 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
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.
Rotate to 2048-bit at your next key rotation.
RFC 8301
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.docusign.com and a policy file at https://mta-sts.docusign.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.docusign.com.
RFC 8460
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.
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.
Publish a TLSA record at _25._tcp.<each MX host> matching your MX certificate.
RFC 7672
Show 12 passing checks
PassAggregate reporting is configured›
Aggregate reports are requested at: [email protected].
PassExternal report destination emaildefense.proofpoint.com is correctly authorised›
Authorised by docusign.com._report._dmarc.emaildefense.proofpoint.com
PassExternal report destination emaildefense.proofpoint.com is correctly authorised›
Authorised by docusign.com._report._dmarc.emaildefense.proofpoint.com
PassDMARC policy is p=reject›
Mail failing authentication is rejected outright. This is the correct end state.
PassSPF lookup count is healthy (2/10)›
Worst-case evaluation stays within the limit with headroom to spare.
PassSPF ends in '-all' (hard fail)›
Unauthorised hosts are explicitly rejected. This is the correct end state.
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.docusign.com.
Pass7 DKIM key(s) published›
Found at: google, m1, mailo, mandrill, s1, s2, smtpapi.
PassSelector 'google' uses a 2048-bit RSA key›
Key length meets current guidance.
PassSelector 's1' uses a 2048-bit RSA key›
Key length meets current guidance.
PassBIMI is published with a certificate reference›
The record at default._bimi.docusign.com names a logo and a Verified Mark Certificate (a=), and DMARC is enforcing, which BIMI requires. We read the record only; the logo and certificate themselves were not fetched or checked.
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.
This is the configuration. It is not the whole picture.
A DNS scan cannot tell you whether docusign.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.