Vendor consolidation report

Most teams accumulate mail vendors the way they accumulate JavaScript dependencies: a transactional sender for the help desk, another for invoicing, a marketing platform for newsletters, a CRM that also sends, a second CRM after a re-platform, and a workspace migration that left old include: entries in SPF behind. Each one is still authorized. Each one is a separate compromise path.

We read your public DNS - SPF includes, DKIM well-known selectors, MX records, DMARC report receivers, and NS records - identify each third party we recognize, and rate the blast radius if that vendor is breached tomorrow. The output is a single page an MSP can hand to a customer or an IT team can drop into a vendor review.

Detection is signal-based: we don't need access to your billing, we don't need agents on your mail servers, and we don't need read-credentials. Everything we surface is already public to anyone who can resolve your domain - so an attacker can see the same picture. The difference is they're using it to plan a phishing run.

The four blast-radius tiers, worst to least bad:

• Route: Your DNS provider. Compromise = total redirection of mail + web. Whoever owns your nameservers can change anything.
• Send: SPF-authorized senders and DKIM signers. Compromise = phishing as your domain to anyone while passing SPF (and sometimes DKIM).
• Read: MX provider and mail gateways. Compromise = reading inbound mail, including password-reset codes.
• Observe: DMARC aggregate-report receivers. They see your sending volumes, IP space, and failure samples. No message content, but enough to fingerprint behavior.

What we flag automatically: two or more transactional senders, two or more marketing platforms, multiple workspace mail providers (usually a migration you forgot to finish), 5+ vendors with send rights, external DMARC report receivers, and SPF records over the 450-byte safe-single-TXT limit.