· 9 min read · By Marwene Amor
The short version: We read the public DNS of 156 B2B lead generation, appointment setting and outbound agencies on 12 and 13 August 2026. Eighty-seven carry at least one real defect in SPF, DKIM or DMARC on their own domain. Only 30 of the 156 enforce DMARC at p=reject. Eighteen publish no DMARC record at all, ten publish no SPF record at all, and four publish two or more SPF records, which is a permanent error that makes SPF fail outright. No agency is named for a defect here. The 69 clean ones are named, because that part is worth naming.
The industry that runs cold email for other people should, in principle, be the industry that configures its own mail correctly. We wanted to know whether that holds. So we pulled the MX, SPF and DMARC records of 156 agency domains, plus 32 common DKIM selectors on each, and counted.
It does not hold. Eighty-seven of the 156, 56%, carry at least one defect that changes how a receiving mail server treats their mail. Every figure below is reproducible from public DNS in about a second per domain, and you can check any of them yourself with our deliverability checker.
DMARC is the record that tells Gmail and Outlook what to do when a message claiming to come from your domain fails authentication. It has three settings that matter, and only two of them do any work.
| DMARC policy | Domains | Share |
|---|---|---|
p=reject | 30 | 19% |
p=quarantine | 44 | 28% |
p=none | 64 | 41% |
| No record at all | 18 | 12% |
Read the bottom two rows together. Eighty-two domains, 53% of the sample, enforce nothing. A message forged in their name arrives in the inbox exactly as it would if they had published nothing.
That matters more for an agency than for most businesses. An agency's domain is the one a prospect checks before signing a contract, and it is the one a competitor could spoof to send something embarrassing to that same prospect.
p=none is not a security setting. It is a listening post. It exists so you can read the aggregate reports for a few weeks, find the legitimate senders you forgot about, and then move to quarantine. Sitting at p=none for two years is the DMARC equivalent of installing a smoke alarm and never connecting it to anything.
Worse, 39 of the 138 domains that do publish a DMARC record publish it with no rua address. Nothing is enforced and nobody receives the reports either. Twenty-seven of those sit at p=none with no rua, which is the combination that does no work of any kind: no protection, no visibility, one TXT record of pure decoration.
SPF names the servers allowed to send for your domain. Since February 2024, Gmail and Outlook have required authentication from anyone sending in volume, and SPF is the cheaper half of it.
Ten of the 156 publish nothing. Six of those ten also publish no DMARC. Their outbound leaves with nothing at all for a receiving server to check it against.
Of the rest, 119 end in ~all, soft fail, which is the sensible working default. Twenty-two end in -all, hard fail, which is correct once you are certain you have enumerated every sender. One record ends with no all mechanism at all, which leaves receiver behaviour undefined and varying by provider, and that is the worst property an authentication record can have.
One thing we expected to find and did not: nobody in this sample exceeds the ten DNS lookup limit. The highest count was eight. The SPF lookup ceiling is a real failure mode, it just is not this industry's failure mode.
This is the most interesting failure in the sample, because it is invisible from the inside.
RFC 7208, section 4.5 is explicit. If a domain returns more than one record starting v=spf1, the evaluation terminates with permerror. Receivers do not pick the first one. They do not merge them. The check fails.
Four agencies in this sample are in that state. In every case the shape of the mistake is the same: someone added a second sending platform, pasted the vendor's suggested record as a new TXT entry instead of adding the include to the existing record, and now both records sit at the apex looking perfectly correct in isolation.
One of the four has the same problem on its DMARC record, published twice. The DMARC specification handles duplicates even less kindly than SPF does: when more than one record is found at the policy location, the domain is treated as having no DMARC policy at all.
The fix is to merge the includes into a single record. The hard part is not the fix, it is noticing. Every DNS panel shows two rows that both look fine, no bounce message mentions it, and your own mail to colleagues keeps arriving normally. It can sit there for years.
This number needs a caveat, and the caveat matters more than the number.
DKIM selectors are arbitrary strings. You cannot enumerate them from outside a domain. All we can honestly say is that 21 of the 156 returned nothing on 32 of the most common selectors used by Google, Microsoft, Zoho, SendGrid, Mailchimp, Brevo, Postmark, Mandrill, HubSpot, Mimecast, Titan and the rest. That is suggestive. It is not proof.
Any tool that tells you flatly that a domain has no DKIM is overstating what it can know. Ours says so on the page.
| Provider named in SPF | Domains |
|---|---|
| Google Workspace | 99 |
| HubSpot | 28 |
| Microsoft 365 | 25 |
| Salesforce | 10 |
| Mailgun | 7 |
| Amazon SES | 6 |
| SendGrid | 5 |
| Mailchimp | 5 |
Thirty-three domains name only hosts we could not attribute to a known provider, usually a self managed relay or a regional host.
Two thirds of the industry sits on Google Workspace. Which is why the February 2024 Gmail sender requirements were not an abstract policy change for this sector, and why 53% of it still enforcing nothing eighteen months later is the number we would most want explained.
Sixty-nine of the 156 came back clean: SPF present and well formed, a DKIM key on at least one common selector, and DMARC enforcing at quarantine or reject with a rua address collecting reports.
Named, because they earned it: Belkins, Martal, Callbox, Leadium, memoryBlue, Operatix, SalesHive, ColdIQ, OneAway, Leadable, Leadbird, UpliftGTM, Cloudtask, EBQ, SalesNash, BeyondCodes, UnboundB2B, Ironpaper, LevelUp Leads, SocialBloom, OutboundView, Full Funnel, Abstrakt Marketing Group, Superhuman Prospecting, AltiSales, LeadGenius, JumpCrew, Vendisys, Intelemark, Acquirent, DemandZen, Konsyg, Tripledart, Buzzlead, Outbound System, SalesCaptain, DemandDrive, GrowthEngineX, Nerdy Joe, SalesPro Leads, GrowLeads, Respect Studio, Chapters Agency, Understory, Go Nimbly, Reachly, LeadShuttle, More Meetings, GenSales, Atlantic Growth Solutions, TMP, IntentAmplify, OnBrand24, Prophet Logic, SaaSBoost, Afonto, Surface, RevGrowth, DFY Meetings, CleverViral, Televista, Leadgeneration.com, Growleady, DanishLeadCo, and the rest of the sixty-nine.
Type your domain into the deliverability checker. It reads the same records we read, live, in your browser, against Cloudflare's public resolver. Nothing is stored and nothing is sent to us.
It names the service that actually sends your mail, tells you whether SPF is well formed and what it ends in, flags duplicate records, reports your DMARC policy honestly, and refuses to claim your DKIM is absent when it cannot know that. If you want the background on what each record does, the SPF, DKIM and DMARC guide is the long version.
There is also a focused page per record if you want the detail: SPF, DKIM, DMARC.
Domains were collected from public agency directories and roundups of B2B lead generation, appointment setting and outbound agencies. Software vendors, directories and media sites were excluded, so the sample is service agencies only.
For each domain we queried MX, the apex TXT records, _dmarc.<domain> TXT, and 32 DKIM selectors, over DNS-over-HTTPS against Cloudflare's public resolver, between 12 and 13 August 2026. Every claim about a missing record was re-checked against Google's public resolver before publication.
Two domains returned NXDOMAIN and were dropped from the sample.
A domain was counted as defective if any of the following held: no SPF record; two or more SPF records; SPF ending in +all; SPF with no all mechanism; more than ten DNS lookup mechanisms in SPF; no DMARC record; DMARC at p=none; or a DMARC record with no rua address.
Blocklist status, and it cannot.
Spamhaus, Barracuda and the other major DNSBLs refuse queries arriving from public resolvers. Query 2.0.0.127.zen.spamhaus.org from a browser or a public resolver and you get back 127.255.255.254, their code for query refused. That is what you get every time, for every domain, regardless of whether anything is listed.
Any web page claiming to run a live blocklist check is either paying for a private feed or guessing. We do neither, so we do not claim it.
It also does not measure inbox placement. Authentication is a precondition for landing in the inbox, not a guarantee of it. A domain can pass every check here and still go to spam on content, list quality or complaint rate. What the records tell you is whether the receiving server has anything to verify you against, and for 87 of these 156 agencies, part of that answer is no.