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.
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.
Does it verify the sender or the domain/service which the sender is using?
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.
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.
Extremely well said.
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.
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.
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.
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.
It would solve a lot of issues globally.
*.mydomain.io. TXT "v=spf1 -all"
@ IN MX 0 .
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
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.
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.
When its unimportant or important to the receiver only, you push responsibility to them: "I sent it. Must be your email that's glithced. Tried Gmail or Proton?"
When its important to you, you use your backup Gmail or Proton account.
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.
https://utcc.utoronto.ca/~cks/space/blog/spam/DMARCPractical...
See this thread in German: https://userforum.mailbox.org/topic/10676-mailbox-org-akzept...
The message you obviously refer to as just an educated guess by a forum user who seems to be experienced in email topics. It could be that the guess is correct. It could be hat the consumtants are too overloaded to configure things differently. Another user has that guess. We don't know as long as the provider does not answer.
Turns out making absolutely sure email isn't faked means jack shit if user isn't even looking at it, or the spoofed domains looks "close enough".
Currently the big pile of mail "security" extensions is basically useless pile of waste that just gives mail server admins some extra work.
LLMs are great for this sort of thing that used to be a massive pain in the rear.
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.
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.
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.
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.
I've had more than one argue with me that having more than 10 lookups in the SPF isn't the issue even though I am showing them the SPF failure and the RFC stating that you are not allowed more than 10. Like, good for you that Gmail doesn't care, we do, fix your shit.
When I learned about this during the post-mortem I was incensed, to say the least. Email mgmt is part of a professional’s job, for better or worse. Accountability for that doesn’t suddenly evaporate because of a scenario like this. I don’t practice zero inbox for fun. I do it for my sanity and effectiveness. Technology can’t magically solve every problem.
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/...
And I can Remove or Renew Access, or those links are showing.
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.
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.
Have your own gmail.com
Only half joking. If you can't figure out SPF/DKIM then you should find a new job.
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.
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.
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.
However, if you are using it to sign up for a service online, the domain often does not match the sender. You might sign up at the example.com website, but you get an email from noreply@auth-example.com as the email address.
that's literally how email works today, unless the federation can supersede my authority as an operator to choose who may send/receive with me, at which point it'd stop being a federation anyway.
myserver.com can talk to yourserver.com just fine and since neither of us have insane spam filters set up, it just works and no megacorpo is involved.
The protocol is okay, it just needs more smaller operators including smaller spam blocklists.
It's possible that gmail screwed up and gave Bob access to Alice's account. In this situation, though, Alice still sent it.
1: https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
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".
Evidence of technical competence wasn't what I was talking about. I meant that it creates a trail of evidence for police to actually pursue them, particularly in the case of phishing.
To setup DMARC, DKIM and SPF you need to control a domain. Somebody has to own that domain, unless you just hacked a DNS or somebody's already configured email server.
If you hacked it, there's a trail to contact the domain owner to notify them. If you bought it, there's a trail to find the domain owner.
You can obfuscate that with stolen cards and fake registration details, but now there's a central point where identity validation and security can concentrate itself.
A lot of positive side effects happen when the bar is raised from "any email server can send email claiming to be from anybody" to "email can only be sent claiming to be from a domain if the domain approves the sending email server."
At least when the spam concentrates from major senders like Google, etc those major senders have the means to analyze and take steps to prevent it.
I'm baffled by this blend of replies. What exactly do you believe charging for an email would do? I mean, other than fabricating a revenue stream. Do you seriously believe that spam would vanish as soon as anyone charged for it's delivery? Because advertisers already pay for reaching their target audiences, and do so well beyond email.
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.
Lots of servers online have a publicly exposed smtp port, where all kinds of script kiddies are just using a sendmail style email from another (not-owned) domain.
DKIM/DMARC tried to fix this (without success due to fakeable entries in the DNS records, spf=all is pretty much everywhere anyways nowadays). So my proposal for actual ownership of domain AND server infrastructure would be mutual TLS. Reverse IP lookups are broken almost always anyways, due to most hosting providers not offering real reverse DNS infrastructure that users can modify.
This way a compromised server can't send as another domain, and large-scale spamming relays that rotate ASNs would have indicators in the cert itself, which they run out of real quick due to limitations of how many IP/DNS subjects you can set in an SSL/TLS cert.
No faking and avoiding bad IP reputations by rotating ASNs anymore.
So wait, it seems like you're claiming that you're receiving spam from the same gmail/outlook address for months.
This is fascinating and I have a hard time believing it, might you be able to share some headers?
OTOH, if the spammers are forced to frequently switch accounts, they're clearly being impeded.
I'm not sure you realize your proposal's only contribution is to worsen spam. You are unwittingly creating an incentive for email providers to lift anti-abuse filters and to maximize the volume of spam delivered to you.
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).
So the end result will be more spam and fewer legit E-mails.
Hormozi could charge $1,000 to get into his read box.
We could refund people, add them to a whitelist - and return a 405? payment required by default and things change in interesting ways when the amount is variable.
Seems useless to me. SPF already specifies what to do with messages that fail SPF. SPF is necessary. DKIM is questionable. DMARC is useless.
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.
655 points 2 years ago
SPF: These are the servers I will send from. If it says it's from me, but comes from somewhere else, it's likely fake
DKIM: This is my signature, if it's not on the email, it probably didn't come from my server.
DMARC: If you get mail that doesn't match the above, here's what I want you to do with it.
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