A90/100

adobe.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.

138 DNS queries · 1110 ms

Fix these first

1
Selector 'selector2' uses a 1024-bit RSA key
Rotate to 2048-bit at your next key rotation.
2
Selector 'k1' uses a 1024-bit RSA key
Rotate to 2048-bit at your next key rotation.
3
Selector 'mandrill' uses a 1024-bit RSA key
Rotate to 2048-bit at your next key rotation.
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.

Microsoft 365MX adobe-com.mail.protection.outlook.com · MX adobe.mail.protection.outlook.comkey published · selector2

Identity ·DMARC

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Policy: reject
Coverage: 100%
Alignment: dkim=r spf=r

Identity ·DKIM

111 selectors probed

selector2Microsoft 365RSA 1024

googleGoogle WorkspaceRSA 2048

k1Mailchimp / MailgunRSA 1024

mandrillMailchimp TransactionalRSA 1024

mte1Mailchimp TransactionalRSA 2048

s1SendGridRSA 2048

s2SendGridRSA 1024

zendesk1ZendeskRSA 2048

zendesk2ZendeskRSA 2048

qualtricsQualtricsRSA 2048

m1MarketoRSA 1024

defaultDefault (OpenDKIM / cPanel / Plesk)RSA 2048

Identity ·SPF

Worst-case evaluation across every include.

v=spf1 exists:%{i}._i.%{d}._d.espf.agari.com include:%{d}.55.spf-protect.agari.com include:_spf.intacct.com IP4:172.193.27.96 -all

DNS lookup budget3 / 10

include:_spf.intacct.com

Findings (10)

MediumSelector 'selector2' 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 'k1' 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

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 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.adobe.com and a policy file at https://mta-sts.adobe.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.adobe.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.

What to do

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

RFC 8659

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.

What to do

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 16 passing checks

PassAggregate reporting is configured›

Aggregate reports are requested at: [email protected].

PassExternal report destination rua.agari.com is correctly authorised›

Authorised by adobe.com._report._dmarc.rua.agari.com

PassExternal report destination ruf.agari.com is correctly authorised›

Authorised by adobe.com._report._dmarc.ruf.agari.com

PassDMARC policy is p=reject›

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

PassSPF lookup count is healthy (3/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.

PassMicrosoft 365's DKIM key is published at selector2._domainkey›

Detected via MX adobe-com.mail.protection.outlook.com, MX adobe.mail.protection.outlook.com. A valid public key for this service is published at selector2._domainkey.adobe.com.

Pass13 DKIM key(s) published›

Found at: default, google, k1, m1, mandrill, mte1, qualtrics, s1, s2, selector2, zendesk1, zendesk2.

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