Feedback loop coverage is uneven. Yahoo sends a full ARF report with the recipient. Microsoft is header-only. Gmail gives you an aggregate rate, no addresses. Apple sends nothing. What each one tells you shapes how you act on a complaint: generatorlabs.com/blog/feedbac...

TLS 1.0 and 1.1 should be turned off everywhere by now. Both were formally deprecated back in 2021. If a client still needs them, that client is the security problem you are actually solving, and weak transport just hides it.

What's your DKIM key rotation cadence? Most domains publish one selector and never touch it again. If you can't name the last time you rotated, that is the answer. See what your domain is publishing: mrdns.com/dkim-check

256 vs 3072. A 256-bit ECDSA key matches the strength of a 3072-bit RSA key, at roughly half the certificate size and far faster signing on the server. Default to ECDSA P-256 for anything new: generatorlabs.com/blog/rsa-vs-...

X509v3 Extended Key Usage: TLS Web Server Authentication Miss this line and a valid, unexpired cert still gets refused as a server cert. Some internal CAs mint client-auth-only certs by default. The handshake fails and the expiry date looks perfectly fine.

Certificate authorities no longer trust a single view of your DNS. Let's Encrypt validates your domain from several network vantage points at once and requires them to agree before issuing.

Your leaf cert is valid for months. The intermediate above it can expire first.

Manual certificate renewal is a reminder you will eventually miss, and lifetimes are shrinking every year. Automating issuance is the only safe path, but the automation itself needs monitoring, or it fails silently: generatorlabs.com/blog/acme-au...

You watch the cert's expiry date. When does the domain name itself expire? A lapsed registration takes down every service on the domain at once, and it renews on a registrar's calendar nobody thinks to check: mrdns.com/whois

550 5.7.1 Service unavailable; client host blocked using Spamhaus The receiver refused the message at the door. Your sender sees it in the bounce; the people you were trying to reach never learn the mail existed. A listing you don't monitor is mail you're quietly losing.

Good news on the RSA vs ECDSA question: you don't have to choose. Point nginx at both certs and each visitor gets the one their browser likes. New clients get the fast ECDSA cert, older ones still get RSA, nobody's left out: generatorlabs.com/blog/rsa-vs-...

1024. That's the DKIM key length a lot of senders are still signing with. It validates, but the Gmail and Yahoo bulk-sender rules call for 2048-bit RSA. A weak signing key is one more reason a receiver downgrades your mail.

ARC-Authentication-Results: i=1; spf=pass dkim=pass A forwarder or mailing list rewrites the path and breaks SPF and DKIM. ARC records that the original checks passed, so the final receiver can still honor DMARC on mail that was relayed.

Accept a message, then bounce it because the mailbox does not exist, and that bounce goes to whoever the spammer forged in the From line. Do it at volume and you land on a backscatter blocklist for spam you never sent.

OCSP stapling proves your cert isn't revoked in the handshake. Enable it.

Is your logo showing up next to your mail in Gmail yet? BIMI only renders once DMARC sits at quarantine or reject and both the record and the VMC validate. See what you have published: mrdns.com/bimi-check

~all on your SPF record is a hedge that means nothing in practice. Every receiver reads softfail its own way, so a spoof still gets a coin flip at the door. Once you actually know every source that sends as you, publish -all and mean it.

Kilobytes, where an ECDSA signature was tens of bytes. Post-quantum certificates run that much larger, and a chain that once fit in a single packet now spans several. Handshake latency and old middleboxes both feel it: generatorlabs.com/blog/post-qu...

Default to a multi-SAN cert, not a wildcard. A wildcard key compromise hands over your entire namespace; a named cert limits the blast radius to the hostnames you listed. Reach for the wildcard only when you're minting subdomains dynamically: generatorlabs.com/blog/wildcar...

451 4.7.1 Greylisted, please try again later The receiver is stalling a first-time sender to see whether you retry like a real mail server. Legit queues come back in minutes. Most spam engines never do, so the delay is doing its job.

List-Unsubscribe-Post: List-Unsubscribe=One-Click Bulk senders to Gmail and Yahoo have had to honor this header since early 2024. Skip it and your mail gets throttled quietly, well before a single spam complaint is ever filed.

Certificate Transparency makes a poor inventory. It records what public CAs issued, so everything from your internal CA is invisible to it, and those are the certificates sitting in front of your databases.

sslv3 alert certificate revoked Revocation does not wait for the expiry date. The CA publishes the serial in its CRL, and any client that bothers to check stops trusting the certificate that afternoon.

Claude's own status page went down this morning over a certificate that didn't match its hostname. The one page that has to stay up when everything else fails, and a cert took it out. Nobody's too big for this: generatorlabs.com/blog/status-...

Nobody announces a certificate swap. A changed fingerprint is the only notice.

1024-bit RSA. SHA-1 signatures. Both still turn up on internal endpoints in 2026, usually on an appliance with a web UI nobody has opened since it was racked.

When did you last look at the certificate on port 993? Everyone checks the website. Same domain, different endpoint, different expiry date, and the port field is right there: mrdns.com/ssl-check

25.113.0.203.in-addr.arpa. IN PTR mail.example.com. Move to a dedicated IP and forward and reverse DNS have to agree, with SPF naming the new address. On a shared pool the platform handled all of that for you. generatorlabs.com/blog/shared-...

Subject: CN=mail.example.com X509v3 Subject Alternative Name: <none> Browsers ignore CN completely now. Mail clients still accept it, which is how a certificate like this keeps working in Thunderbird and fails in every browser you point at it.

Your sending IP can be spotless while a domain in your links is listed. URIBLs read the message body, and filters act on what they find there.