Anyways, the new CF AI tool is relatively decent for this purpose, explains the fact that most warnings in CF are harmless, but the lack of standardized guidelines is annoying to say the least.
https://utcc.utoronto.ca/~cks/space/blog/spam/DMARCPractical...
The big companies do not have to care because nobody will block Google, Microsoft or Amazon. They are too big to fail.
Spoofing a From field is an insignificant problem in comparison.
If you decide to think about this, you will quickly realize that email is f*ked and needs to be forked. Perhaps we need a Community Email Initiative that blocks corporations and only allows Community members.
Trust is the one thing you can't buy on the Corporate Internet.
I am sure many people will be offended and down vote this comment because they cannot conceptualize an internet without Corporations.
The latter are likely to adopt much more slowly simply because of less perceived risk, lower payoff (no vendor reviews), and less dedicated technical expertise.
Just like personal sites were slow to adopt HTTPS. Mass HTTPS adoption happened once browser warnings and SEO incentives rendered sites mostly useless without it.
The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender. Signatures are purely a technical measure which provides no information on the trustworthiness of the sender. The end result is that email scoring still has to be content based, and the signature check technologies are pure noise with no useful signal for the purpose of determining if an email should actually show up in my inbox.
The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.
DNS SPF record: mydomain.io. TXT "v=spf1 -all"
DNS DMARC: _dmarc.mydomain.io. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
That ought to stop anyone trying to use your domains as source.
I even go to the trouble of registering in their Postmaster Tools and clogging up my DNS with their verification tokens all for the tools to tell me I don't send enough mail while they happily pass what little mail I send straight to spam.
Not enough outgoing email
You haven't sent enough email to personal Gmail (@gmail.com) accounts to determine deliverability status for your domain and messages.
Guess it doesn't help that as I look today the Postmaster Tools dashboard shows "Last updated Sun, Apr 26, at 9:30 AM."
Then on the other hand Google can flood me with spam filled Google Calendar Invites and Google Drive Share notifications, all fully DKIM signed because they are coming out of those services, all day long.
Microsoft have also recently changed their Smart Network Data Service (SNDS) so now only my cloud provider can access the console as they only allow verification to the owner of the whole ASN block you're under. I can't access detail about my domain anymore, and still my mail goes to junk. Unless you own a chunk of IPv4 ASN range you're out of luck. IPv6? Nope, not at Microsoft. "Please note that IPv6 is not currently supported." [1]
[1]: https://substrate.office.com/ip-domain-management-snds/SNDS/...
It's time for a new protocol with end to end encryption and sender verification built-in. That shouldn't be as hard as it sounds, because at the time when email was invented the internet was very different. Connections were intermittent, for example I would retrieve my email once a day with UUCP (and some other people would use batched-SMTP). Which means you could not rely on the sending and receiving server being able to communicate directly. In this day and age this is possible and that direct communication opens up a lot of better crypto like key generation algorithms which require both parties to be online at the same time.
The problem is, is you don't allow corpos you will break 95% of mainstream people's usecases. So I think this is a non-starter, unfortunately, though it is a lofty goal.
There is so much crossover between personal email and corporate email.
Depending on how hard you want to make it, you can slap all the parts together yourself or use something like Zimbra, Mailcow, iRedMail, mail-in-a-box.
The advantage over a fork, whatever specifically that means, is any service that needs E-mail as an identity verification, still works.
admin@example.com OK postmaster@example.com OK abuse@example.com OK webmaster@example.com OK hostmaster@example.com OK info@example.com OK example.com REJECT example.com
Which is only the core problem because dmarc fixed the other core problem of figuring out who the given sender is.
DMARC does not solve everything, but it does make other solutions more effective.
Extremely well said.
It would solve a lot of issues globally.
But if you send all emails for your domain from one email server, you could just disable rua reporting. The reports are mainly useful to see whether you have some misconfigired email server somewhere that causes (or will cause) dropped emails. That can easily happen if you send some email from your own server, some via sendgrid, some via some marketing tool, and start to lose track of them. But for a personal email server, that's not common.
@ IN MX 0 .
*.mydomain.io. TXT "v=spf1 -all"
Additionally, I would probably guess correctly that almost all spam comes from rotating ASNs these days. Aka from companies that do "growth marketing" or other bullshit that isn't a valid business but just... spamming people.
A lot of the domains that fall through the cracks for single-spam-campaigns have been taken over by botnet campaigns, so the actual owners of said domains probably don't know that their website is spamming everyone else.
But the major providers are the culprit, too, here. Gmail, hotmail, microsoft o365, mailgun ... they all don't even enforce SSL from server to server, and let through "sendmail" like spam because the spammers are paying customers to them.
Source: I am maintaining antispam [1] which I am using to combat spam, phishing, and malware campaigns targeting my customer networks.
This should create a means to go after the domain owners via registrar and trail of ownership, even so far as blocking email from the domain.
Forcing the spammers to pass DMARC creates a burden and an evidence trail that didn't exist before.
Have your own gmail.com
And I can Remove or Renew Access, or those links are showing.
Some changes I made at the direction of an agent: fix domainkeys CNAMEs for M365, rotate M365 dkim keys that haven't been rotated for over a decade, fix broken spf record formatting.
My biggest issue is that squarespace refuses to enable dkim signing for transactional emails that they send for us (order/shipping confirmation etc). The email sending service they use (socketlabs) supports it but they are not interested in enabling the feature, so I can't lock down our dmarc. I guess that means squarespace is not a good fit for our needs; it's just disappointing that we have to move to a different platform again for technical reasons that are solvable with a dashboard switch.
Some mail providers will junk your mail if you don't have a reject/quarantine DMARC policy because you're seen as enabling the spammers so everything out of your domain must be punished.
What do you expect to achieve by blocking an already abandoned domain?
It feels like the biggest spammers have swung back to just abusing SaaS and getting SPF / DKIM / DMARC for free from one of the big email providers.
Now if the sender used SPF + DMARC but not DKIM, this does not work, since the sender IP can't be verified with the forwarded email. In that case, the forwarder has to change the from address to prevent the email from failing DMARC and be rejected.
In practice, senders using SPF+DMARC but not DKIM should be quite rare, you see DKIM+DMARC much more often.
My scale is that I ran an ISP for ~500 users before the network was disassembled last month. At that scale, you will encounter people that make mistakes with their email setups. When the people who make mistakes are customers which DMARC prevents delivery of emails, it is an issue as those are exactly the people for which I want to see the emails from.
I get more spam with valid SPF and DKIM via Google's own mail servers than DMARC blocks.
It says something when even gmail doesn't use DMARC as a signal that an email is valid, as gmail regularly blocks legitimate mailing list emails with completely valid signatures and non-spam content from a reputationaly sound IP.
The problem DMARC was supposed to solve (impersonation to reduce spam) isn't solved by DMARC.
More often than not I end up talking to someone in the sender's IT who fancies themself an expert and is completely incredulous that there could possibly be a problem on their side ("But we don't have problems sending email to anybody but you...")
I should want to fight the good fight, but it's so demoralizing.
Edit:
Dealing with other IT people on problems like this taught me a ton of humility. It wasn't until I was in my early 30s before I'd reached a level of maturity to approach trouble reports like this being reported to me with an open mind. Before that I fancied myself and expert and, likely, was insufferable in many contexts.
Now I'm insufferable in fewer contexts.
DMARC does absolutely nothing to prevent the kind of impersonation that occurs in the real world. It doesn't block homoglyphs or or typo-squatting or all the other forms impersonation that matter. It has failed at preventing impersonation.
Just a few days ago I had a phishing email from an elderly woman I had previously done some work for. The message passed DMARC and everything else, and the domain it was sent from was valid. But it was not legitimate; it was an impersonation of her which became obvious once the content was read.
DMARC is noise, not signal. It has to be ignored in the real world as it provides virtually no value beyond blocking emails pretty randomly because someone made a mistake when rotating their DKIM keys or one of a million other mistakes that do happen.
In the following SMTP conversation:
MAIL FROM: foo@example.net
RCPT TO: victim@example.com
DATA
From: service@paypal.co.uk
To: victim@example.com
Subject: We are updating our Terms of Service
[...]
The recipient sees service@paypal.co.uk (the From address on the inner message), because most ESPs do them the great disservice of not indicating that the sender identities are not aligned.
Adding a DMARC record to a domain requires that e-mail whose inner messages claim to be from that domain must have sender alignment to the envelope sender.
The above message would pass SPF (if the spammer owns example.net and has created SPF records for themselves) but would fail DMARC (paypal.co.uk's DMARC record exists, so alignment is required, and yet example.net != paypal.co.uk, so they are not aligned). In this case their DMARC policy says to reject the message, so (if the recipient is checking DMARC) it would either be rejected outright or it would land in Spam/Quarantine rather than Inbox.
SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.
Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.
If it were possible to charge $0.25/email for delivery, I'd be more than happy . However, I'm sure large tech firms will need to say that is "too hard to implement at scale".
For example, gmail.com treats unauthenticated email as spam implicitly, regardless of DMARC policy.
The report that they send you is useful for you to make sure your emails that you expect to go through are going through.
I've often seen messages resent by Microsoft's mail infrastructure with gratuitously broken DKIM signatures, generally due to changes to whitespace that are not anticipated by DKIM's message canonicalization.
I've also seen messages sent by my bank directly to the email system I administer that had broken DKIM signatures apparently due to some sort of antivirus software they had downstream of the DKIM signer.
DMARC has existed since 2012. It is a free DNS record that tells receiving mail servers what to do with email that fails to authenticate as coming from your domain: report it, quarantine it, or reject it outright. It is primarily concerned with unauthorised use of a domain in the visible From address; it doesn't stop lookalike-domain registrations, display-name spoofing, or a phishing email sent from a compromised legitimate account. Fourteen years on, we checked the DNS records for 67,336 domains in CipherCue's tracked entity set between 2026-04-14 and 2026-07-28. This is a snapshot of CipherCue's dataset, not a statistically representative sample of every company worldwide; the method note below covers how the cohort is built. 30,362 of them (45.1%) still don't have a record.
The domains that do have a record are not much further along. Only 10,963 (29.7% of domains with a record) actually enforce anything: p=reject, mail that fails authentication gets dropped. 10,258 (27.7%) sit at p=quarantine, junk folder but not blocked. The largest single group, 15,709 domains (42.5%), is set to p=none. A p=none policy collects authentication data and aggregate reports but does not ask receiving mail systems to quarantine or reject messages that fail DMARC. In this analysis, enforcement means a published policy of p=quarantine or p=reject; domains using p=none are counted as non-enforcing.
42.5% of domains with a DMARC record are still at p=none, collecting reports but not requesting quarantine or rejection, as of our most recent observation window
p=none is meant to be a temporary monitoring phase before you move to enforcement, typically a few weeks. Fourteen years after the standard shipped, for the largest single group of domains in our data, it looks like the permanent state.
Put the two together and the picture is starker than either number alone: of all 67,336 domains we checked, 46,071 (68.4%) either have no DMARC record or have one that doesn't enforce a policy. Publishing a DMARC record is no longer the main adoption gap in this dataset; moving from monitoring to enforcement is.
68.4% of all domains checked have no DMARC record, or have one that does not enforce a policy (no record: 45.1%; record present but p=none: 23.3% of the total)
30,362
No record
45.1%
15,709
p=none
23.3%
10,258
p=quarantine
15.2%
10,963
p=reject
16.3%
Share of all 67,336 domains checked, not just those with a record
| State | Domains | Share of all checked | Share of domains with a record |
|---|---|---|---|
| No DMARC record | 30,362 | 45.1% | n/a |
| p=none (monitor only) | 15,709 | 23.3% | 42.5% |
| p=quarantine | 10,258 | 15.2% | 27.7% |
| p=reject (full enforcement) | 10,963 | 16.3% | 29.7% |
The usual explanation is inertia or ignorance. Our data points at a more specific, more mechanical cause: nobody can tell what's actually sending the mail.
Every domain with DMARC's reporting flag on gets daily aggregate reports (rua=) listing every source that sent mail claiming to be from that domain, whether it passed authentication or not. Moving to enforcement means going through that list and deciding, source by source, "yes, that's meant to be us" or "no, block it." We pulled the raw rua= addresses out of 36,974 DMARC records and counted where the reports actually go.
10,268 distinct rua= reporting domains found across 26,179 reporting-address entries; 8,113 of them (79%) appear in our data exactly once
Some of that concentrates in a few obvious places: Proofpoint's own reporting endpoint appears 1,605 times, Cloudflare's 1,273 times, dmarcian's various regional endpoints (ag.eu.dmarcian.com, ag.us.dmarcian.com, and eight more country-coded variants) add up to over 1,000 between them, and Brevo, Postmark, Barracuda, and a scatter of DMARC-as-a-service vendors (EasyDMARC, PowerDMARC, dmarcian, Red Sift, DMARC Analyzer, dmarcly, sdmarc.net, hornetdmarc.com) fill out most of the rest.
But the long tail is the finding. Once you get past roughly the top 60 domains, the addresses stop being recognisable vendors and start being one-off, often hashed, mailbox names: ivrejeuw@ag.c1.dmarcian.com, a.8hyzr404@sdmarc.net, 2fa9a7572f@rua.easydmarc.eu, a company self-hosting reports at its own domain (dmarc@axa.com, rua@lseg.com), or a mailbox that gives no clue at all (watchdog@watchdog.kevlarr.io). An administrator staring at a week of these reports is not looking at a vendor list. They are looking at a pile of IP addresses and sender strings with no obvious owner, and deciding whether to enforce means identifying every one of them first.
That is a research task, not a configuration change, and it is the kind of task that gets deprioritised indefinitely. We think it is the largest single reason the p=none number above is as high as it is.
We mapped the rua= reporting-address domains against a vendor dictionary covering the DMARC-monitoring and mail-infrastructure products we could confidently identify. This is a different, broader measurement than matching against a single fact type: it picks up 8,862 identified entities across 29 named destinations, versus 1,400 when only the pre-built vendor dictionary is used. It is still a floor, not a ceiling. It only counts domains we could confidently attribute; the 8,113 one-off destinations described above are excluded here because a single occurrence isn't enough to confidently name a vendor.
| Destination | Entities | Share of identified | What it is |
|---|---|---|---|
| Brevo | 1,297 | 14.6% | Transactional email platform (formerly Sendinblue); receives reports as a side effect of sending mail, not a DMARC product |
| Proofpoint | 1,094 | 12.3% | Secure email gateway; own reporting endpoint (emaildefense.proofpoint.com) |
| Valimail | 1,068 | 12.1% | DMARC monitoring / automation product |
| Cloudflare | 978 | 11.0% | DNS/CDN provider; reports arrive at their own domain via a hosted DMARC feature, not a dedicated DMARC product |
| DMARC Analyzer | 602 | 6.8% | DMARC monitoring product (Dutch-founded, part of Vade since 2020) |
| dmarcian | 584 | 6.6% | DMARC monitoring product, nine country-coded regional endpoints |
| DMARC Advisor | 407 | 4.6% | DMARC monitoring product |
| EasyDMARC | 377 | 4.3% | DMARC monitoring product |
| Postmark | 348 | 3.9% | Transactional email platform; reports arrive as a side effect of sending mail |
| MxToolbox | 321 | 3.6% | DNS diagnostics vendor offering a DMARC report reader |
| Barracuda | 267 | 3.0% | Email security / gateway vendor |
| Red Sift (OnDMARC) | 248 | 2.8% | DMARC monitoring product |
| PowerDMARC | 184 | 2.1% | DMARC monitoring product |
| Fortra (Agari) | 149 | 1.7% | Email security / DMARC monitoring product |
| Others (15 vendors) | 938 | 10.6% | dmarcly, GoDaddy, sDMARC, Red Sift (separate endpoint), CheckPoint, Mailgun, Mailhardener, Everest, HornetSecurity, Kevlarr, LetsDMARC, report-uri, GlockApps, Cisco, UK NCSC |
Reading this table needs a caveat the table itself can't carry: Brevo, Cloudflare, and Postmark are not "DMARC monitoring vendors" in the way Valimail, dmarcian, or Red Sift are. They receive aggregate reports because a domain owner pointed rua= at a mailbox on their platform, often because that platform is also the domain's outbound sending or DNS provider, not because the domain owner bought a dedicated monitoring product from them. Restricting the table to vendors whose core product is DMARC monitoring, Valimail, DMARC Analyzer, dmarcian, DMARC Advisor, EasyDMARC, Red Sift, PowerDMARC, and Fortra (Agari) together account for 3,619 of the 8,862 identified entities, 40.8%. Within that narrower base, Valimail is the largest single vendor at 29.5%, with DMARC Analyzer (16.6%) and dmarcian (16.1%) some way behind; no vendor holds a majority, but the market is not evenly split either.
Enforcement stage varies by country. Poland has the largest share of domains with no DMARC record at all in this cohort; the UK has the smallest share of domains with no record, but a correspondingly higher enforcement rate once a record exists.
| Country | Domains checked | No record | p=none | p=quarantine | p=reject |
|---|---|---|---|---|---|
| Poland | 7,039 | 64.6% | 16.3% | 11.3% | 7.7% |
| Netherlands | 5,598 | 51.1% | 21.1% | 14.2% | 13.6% |
| Germany | 12,152 | 45.7% | 26.3% | 12.9% | 15.0% |
| United States | 13,292 | 42.1% | 19.0% | 16.7% | 22.2% |
| Italy | 4,545 | 40.9% | 36.8% | 11.7% | 10.5% |
| United Kingdom | 1,493 | 37.0% | 19.2% | 18.3% | 25.5% |
| Spain | 2,697 | 36.9% | 29.5% | 18.1% | 15.5% |
| France | 5,125 | 43.0% | 29.1% | 12.8% | 15.1% |
The US and UK have the highest p=reject shares in this table (22.2% and 25.5%). Italy stands out for a different reason: it has one of the lower no-record rates (40.9%) but also the highest p=none share of any country here (36.8%), an observed difference consistent with more Italian domains in this cohort having started the DMARC process and stopped at the reporting-only stage, though the data here doesn't establish why. This is a snapshot of CipherCue's tracked cohort, not a national census; see the method note for how that cohort is built.
DMARC doesn't operate alone. SPF and DKIM are the two authentication mechanisms DMARC builds on top of; MTA-STS, DNSSEC, and BIMI are three adjacent DNS-based controls that address related but separate problems. We checked all five against the same 67,336-domain cohort.
| Control | What it does | Present | Share |
|---|---|---|---|
| SPF | Authorises which mail servers can send for a domain | 48,962 | 72.7% |
| DMARC | Sets policy for mail that fails authentication, plus reporting | 36,974 | 54.9% |
| BIMI | Displays a verified brand logo in supporting inboxes | 1,726 | 2.6% |
| MTA-STS | Forces TLS encryption in transit between mail servers | 957 | 1.4% |
| DNSSEC | Cryptographically signs DNS responses so they can't be forged | 0 | 0.0% |
SPF is the most widely adopted control here, which tracks with it being the oldest and simplest to configure (a single DNS TXT record with no reporting infrastructure required). Of the 48,962 domains with SPF, 25,657 (52.4%) use a hard fail (-all) and 21,103 (43.1%) use a soft fail (~all), the difference between "reject" and "flag but accept" for mail that fails the SPF check.
MTA-STS and BIMI both sit under 3%. DNSSEC shows zero validated domains in this cohort, which we're flagging as a measurement caveat rather than a finding: CipherCue's current DNSSEC check validates the full signing chain, and a stricter check will show fewer passes than a looser one that only checks for the presence of DNSKEY or RRSIG records. We would not present 0.0% as a claim that no domain in the cohort has DNSSEC configured at all; we can say confidently that none passed full chain validation in our check, and we're treating the true adoption rate as an open question until we've audited the check itself.
DMARC's core specification changed in 2026. RFC 7489, the original DMARC specification published in March 2015 as an informational, industry-authored document, has been obsoleted by three new IETF documents published in May 2026:
rua= reports this article is about)ruf=)The practical significance is less about new tags in your DNS record and more about standing. RFC 7489 was published on the Independent Submission stream as Informational, meaning it was never put through IETF working-group consensus. RFC 9989 is Standards Track (Proposed Standard), the first time DMARC has had formal IETF standard status. The tags you already use, v=, p=, sp=, rua=, ruf=, adkim=, aspf=, and fo=, keep their existing meaning; nothing you would need to change today.
The one substantive mechanism change is how a receiver finds the "organisational domain" for a subdomain that has no DMARC record of its own. RFC 7489 used the Public Suffix List, a community-maintained file of which domain suffixes count as registrable (for example, knowing that co.uk is a suffix, not a company). RFC 9989 replaces this with a DNS Tree Walk: the receiver checks for a DMARC record at the exact sending domain, then walks up the domain tree checking each parent, until it finds one or runs out of labels. This removes the dependency on an externally maintained list that isn't itself part of the DNS.
Two adjacent standards referenced in this article, for context on maturity: RFC 8461 (MTA-STS) has been a full IETF Internet Standard since September 2018. BIMI, by contrast, has never been adopted by an IETF working group; as of this article the latest version is an individual Internet-Draft (version 14, dated May 2026) that explicitly carries "no formal standing in the IETF standards process." That gap in standing is one plausible reason BIMI sits at 2.6% adoption in our data versus SPF's 72.7%: implementing a control with no finished specification and an added certification cost (BIMI requires a Verified Mark Certificate from a small number of authorities) is a harder sell than a DNS TXT record against a ratified standard.
Neither SOC 2 nor ISO 27001 universally requires DMARC as a specifically named control. An organisation may still implement DMARC as part of its risk-based controls for email authentication, impersonation, and domain abuse.
SOC 2 is built around the AICPA's Trust Services Criteria, not a fixed technical checklist. An auditor evaluates whether the controls a company has chosen satisfy the criteria (most commonly Security, sometimes also Availability, Confidentiality, Processing Integrity, or Privacy); the company picks its own controls, and DMARC is not one of the named examples in the criteria document.
ISO 27001:2022 works the same way. Annex A control 5.14, Information Transfer, requires "rules, procedures, or agreements" governing how information moves within an organisation and with third parties, which is broad enough to cover email authentication without naming it. The 2022 revision consolidated what used to be four separate controls in the 2013 version (old clauses 8.7.1 through 8.7.4) into this single control.
Cranswick, the UK food producer (cranswick.co.uk), is a real example from the dataset. Its DMARC record is p=none and lists three separate rua= addresses: dmarc_agg@vali.email, a self-registered mailbox at eu.cp-dmarc.com, and a hashed address at rua.easydmarc.eu. Three different destinations, at least two different DMARC-monitoring vendors, for one domain. This is a public DNS record; anyone can look it up with dig TXT _dmarc.cranswick.co.uk. It is not unusual in the dataset, which is the point: reconciling three separate report streams into "who is actually sending mail for us" is exactly the kind of work that has to happen before a domain owner can move off p=none.
Source and cohort: CipherCue's own DNS observations (direct queries for DMARC, SPF, MTA-STS, BIMI, and DNSSEC), not a third-party dataset. 67,336 domains, observed 2026-04-14 to 2026-07-28. This is a domain count, not a deduplicated-organisation count: a large company can own several domains at different enforcement stages, so the same company can appear more than once.
Vendor mapping ("Who runs DMARC monitoring") uses a manually maintained dictionary of 40 known rua= reporting-endpoint domains and identifies 8,862 entities; it's a floor, not a census, since a name only appears if the destination matched a known pattern.
DNSSEC shows 0.0% because CipherCue's check requires full signing-chain validation; read that as "none passed our validation," not "none have DNSSEC configured."
External references: RFC 7489, RFC 9989, RFC 9990, RFC 9991 (IETF Datatracker), RFC 8461 (IETF Datatracker), draft-brand-indicators-for-message-identification version 14 (IETF Datatracker). SOC 2 Trust Services Criteria (AICPA), ISO/IEC 27001:2022 Annex A control 5.14.
CipherCue's entity directory carries this same DNS compliance data (DMARC, SPF, MTA-STS, BIMI, DNSSEC) as a filterable score band per tracked domain, alongside country. If you want the domains in this article's low-scoring band for a specific country or sector, that's a filter on the entities index, not a custom pull.
Separately, if you're the one staring at your own rua= reports trying to work out who's actually sending mail on your behalf before you flip to enforcement: we built SenderLedger for exactly this problem. It takes the anonymous IPs and mailbox strings in your DMARC aggregate reports and groups them into named sender entities, vendor or system name, source IPs, first seen, last seen, volume, and an authorisation status. It's in early access; there's a waitlist at senderledger.com if you want in.
1: https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
edit: looks like I had an extension that was redirecting to old.reddit.com, and it was old reddit that required login. Though when I turned that extension off, I got a "blocked by reddit security" error. ugggh.
Using it minimally is correct, thou. Route outbound mail through as few controlled relays as possible so your SPF record only needs to list infrastructure you actually *own*, rather than growing it every time a new tool needs to send mail.
I have seen way too many clients almost hit the char limit in a TXT record
Some sort of payment scheme is really the best, most durable option. The problem of mailing-lists and personal correspondence could be solved by an exclusion mechanism where the recipient effectively whitelists senders, explicitly or implicitly (e.g. whitelist a replying-sender automatically if a recipient initiates a conversation).
I would certainly agree that DKIM is harder to get right. However, the TXT record data size limit is surmountable. You can either use EC algorithms, which have much shorter keys, or stick with e.g. RSA and its very long keys, but span them across multiple 255-byte record data chunks. That having been said, I still think DNS providers should do more to make configuring DKIM easier.
Ultimately, if you have SPF and DKIM set up such that both cover all senders, then you are just using SPF. It is the simpler and more forgiving mechanism, so its broad-scoped successes will always swallow DKIM in practice. The only reason I can think of to do this anyway is if you suspect your email provider will change IPs on you and they don't provide their own SPF record, but if that were the case, they are basically telling you not to use SPF in the first place.
EDIT: RFC 7489 was superseded by RFCs 9989-9901 rather recently. Nevertheless, the definition of success, now given in RFC 9989 section 5.3.5 [2], remains the same.
[1] = https://datatracker.ietf.org/doc/html/rfc7489#section-4.2
[2] = https://datatracker.ietf.org/doc/html/rfc9989#section-5.3.5
So the end result will be more spam and fewer legit E-mails.