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.
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.
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.
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".
What do you expect to achieve by blocking an already abandoned domain?
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.
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
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
Extremely well said.
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.
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.
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.
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.