Who can phish as your domain? We measured 203 of them.

• Median brand: 3 third parties can send mail AS them.Each one passes SPF, most pass DKIM, and DMARC aligns. From the receiver's side it looks indistinguishable from the brand's own outbound.
• 1 in 3 brands has 5+ authorized senders. Each one is a separate compromise path.
• 1 in 5 brands has duplicate transactional senders. Almost always a vendor switch where the losing side is still paid through renewal.
• 1 in 17 brands shows a stuck workspace migration - both Google Workspace and Microsoft 365 still in the SPF / DKIM / MX. The losing side is free spoofing surface.
• 76% of brands hand DMARC telemetry to an external receiver. Not message content, but enough to fingerprint sending behavior. Verify the contract covers data handling.
• 1 in 17 brands has an SPF record over the 450-byte safe-single-TXT limit. Past that, strict resolvers reject it outright with PermError.
• We shipped a free tool that does this analysis for any domain you give it: wiredepth.com/vendor-consolidation.

We ran every brand in the seed list through the same analysis the free tool does for one domain: walk public DNS, identify each SPF include, each DKIM selector, the MX hosts, the DMARC report receivers, and the nameservers. Then classify each one and rate the blast radius.

Sample = the 203-brand seed that powers /spoofable. Selection bias: globally-recognisable brands across the categories most likely to be impersonated in phishing - tech, finance, retail, software, media, government, healthcare, travel, telecom, social, security, education, logistics.

The top 10 vendors by appearance across the 203 brands:

Microsoft 365 edges Google Workspace at the top of the stack, but Proofpoint ties Google for second - reflecting how many of these brands run an inline mail gateway in front of their actual workspace. Akamai DNS is the surprise: 30% of the most-impersonated brands run their authoritative nameservers there, which means if Akamai is breached one day, 30% of the global phishing-target list can be redirected at will.

A single SPF record on a small B2B SaaS in 2026 routinely looks like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com
        include:sendgrid.net include:mailgun.org
        include:_spf.klaviyo.com include:mail.hubspotemail.net
        include:servers.mcsv.net include:helpscoutemail.com
        include:_spf.intercom.io include:_spf.salesforce.com
        ~all

Ten upstream senders. Each one was added for a reason that made sense at the time. Each one was authorized by someone who is no longer on the team. Half of them probably haven't sent in months.

The classic patterns we see:

• Stuck workspace migration. Both Google Workspace and Microsoft 365 in the SPF, because the cutover finished a year ago but nobody pruned the loser. The loser is still fully authorized to send and to receive.
• Duplicate transactional senders. SendGrid for the product, Mailgun for the help desk. Almost always a vendor switch where the old contract is paid up through renewal.
• Marketing platform churn. Mailchimp from the old website, HubSpot from the new one, plus Klaviyo from the ecommerce experiment. Three platforms, one audience, three bills.
• Forgotten help desk / CRM. Zendesk in the SPF from when the support team used it. Intercom is the current tool. Zendesk hasn't sent a ticket in eighteen months. The authorization is still live.

None of these are catastrophic by themselves. Stacked together, the customer ends up carrying a 600-byte SPF record, 8-10 active third-party send authorizations, and a ten-figure question on the renewal review: can we actually turn any of this off?

Listing vendors isn't the hard part. The hard part is telling a non-technical stakeholder why it matters. We settled on four tiers because they map cleanly to the worst-case attacker capability if any one vendor is breached.

• Route - Your DNS provider. Whoever owns your nameservers can change anything. Compromise = total redirection of mail and web. Highest risk, lowest count (usually one).
• Send - SPF-authorized senders and DKIM signers. Compromise = phishing as your domain to anyone, passing SPF and (in most setups) DKIM. This is the bucket that bloats.
• Read - MX provider and inline mail gateways (Mimecast, Proofpoint, Barracuda ESS). Compromise = reading inbound mail, including password reset codes and 2FA backup codes.
• Observe - External DMARC report receivers. Compromise = visibility into delivery telemetry (volumes, sending IPs, failure samples). No message content, but enough to fingerprint behavior.

A board-level summary of vendor risk used to require a consultant. The four-tier framing lets a customer answer it in a minute: how many Send, how many Read, who owns Route.

The free tool runs five categorical checks on top of the vendor list:

• Duplicate transactional senders. Two or more senders in the "transactional" bucket. Almost always a switch where the old vendor is still paid.
• Duplicate marketing platforms. Two or more email-marketing tools authorized. Worth a renewal review.
• Multiple workspace mail providers (critical). Both Google Workspace and Microsoft 365 in the SPF / DKIM. Almost always a stuck migration. The unused workspace is free spoofing surface.
• High vendor count (warn). Five or more vendors with Send rights. Independent compromise paths add up.
• SPF overflow risk (warn). SPF record over 450 bytes. Past that, strict resolvers reject the record entirely with PermError. Removing an unused vendor shrinks the record AND reduces blast surface in one move.

External DMARC report receivers also get flagged at info severity. They're not a security issue per se, but the contract should explicitly cover what they do with your telemetry.

We're a free, read-only DNS scanner. Things we do not attempt:

• Detect DKIM-only senders with custom selectors. Vendors that mint a per-customer DKIM selector (think k1-xyz._domainkey) are invisible to a public probe. We name what we can find and tell you the picture is incomplete.
• Estimate per-vendor cost. We don't know what you're paying. We tell you the consolidation opportunities; the bill is yours to look up.
• Change anything. The tool is read-only. Removing a vendor is a manual edit in your DNS panel; the tool just tells you which one to remove first.

Most users find the result mildly humbling - even teams that consciously buy fewer SaaS tools end up with 5-6 third parties in the Send tier. The tool runs in under five seconds and the output is a single page suitable for a renewal review or a vendor-risk audit.

Run the vendor consolidation report →

No signup. We log the domain you ran (anonymous) for rate limiting and aggregate-stats purposes; we don't store per-call results.

• The State of DMARC, 2026 - a 100,000-domain crawl of email authentication adoption.
• SPF flattener - if your record is over the 10-lookup limit, this is the short-term fix while you consolidate vendors.
• Can my domain be spoofed? - yes / maybe / no verdict from the same data the consolidation report walks.
• Wiredepth CLI - re-run the vendor + SPF audit from a terminal or CI job and diff the vendor list between scans.
• Posture verification - tamper-evident, third-party-timestamped record of which vendors were authorised on a given day. Helpful when an audit asks "who had send rights on this date?".
• Evidence pack - the vendor list plus blast-radius rating per vendor, rendered as an auditor-ready PDF with citations.
• Vendor de-authorization guides - once you spot a vendor that should not be authorised any more, the per-vendor playbooks walk through the exact DNS edits.