65 DNS queries in 174ms · SPF 9/10 lookups · DKIM 2 keys · DMARC p=reject · MTA-STS none · DNSSEC signed
Warning
SPF uses 9 of 10 DNS lookups
This is currently valid but has no headroom. Adding one more sending tool, or a vendor expanding their own include, pushes you over the limit and silently breaks SPF for every message.
What to do
Audit the list for senders you no longer use.
Before adding any new sending tool, re-run this check.
Warning
1 DKIM key is shorter than 2048 bits
s2 (1024-bit). 1024-bit RSA is still accepted everywhere but is no longer considered strong, and some receivers have begun downgrading it. Rotation is handled by your provider, not by editing DNS directly.
What to do
Ask the provider behind SendGrid / generic to reissue at 2048 bits.
Publish the new key on a fresh selector, then remove the old one once mail is signing with it.
Note
No MTA-STS policy
Mail sent to you can be downgraded to an unencrypted connection by an attacker on the network. MTA-STS closes that hole. Optional, but it is what separates a well-run mail domain from an average one.
Publish this TXT record at_mta-sts.paypal.com
v=STSv1; id=20260731000000
Before you publish: The record alone does nothing — you must also serve a policy file at https://mta-sts.paypal.com/.well-known/mta-sts.txt listing your MX hosts. Start with mode: testing, and only move to enforce once reports confirm nothing is failing.
Note
No TLS reporting
TLS-RPT asks other mail providers to tell you when encrypted delivery to your domain fails. It is the feedback loop that makes MTA-STS safe to enforce — without it you are switching on enforcement blind.
Publish this TXT record at_smtp._tls.paypal.com
v=TLSRPTv1; rua=mailto:tlsrpt@paypal.com
Before you publish: The mailbox must exist. Reports arrive daily as JSON attachments.
Good
DMARC is at p=reject
The strongest policy. Mail failing authentication is rejected outright.
Good
DNSSEC is enabled
paypal.com is signed, so its DNS answers — including every record above — cannot be forged in transit.