Live data from Hacker News

DMARC has been public since 2012 but most company domains still don't enforce it

ciphercue.com

91–100 of 185 posts

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#91
post #85

Earlier quoted context omitted.

Yes and no. DKIM signs part of the envelope to help recipients detect alteration (by verifying authenticity), SPF locks down the permissible origins for the sender. SPF is in itself imperfect and can in some situations be exploited on open-access shared systems. If the two are used in concert they offer decent protection.

Using both has to be done very carefully, because a positive result from the weaker one (SPF) will override a negative result from the stronger one (DKIM). You should maximally use DKIM and minimally use SPF. Ideally, you should not use SPF at all, but there are some senders that still don't support DKIM.

Many email providers and third party security tools default settings automatically bounce or block SPF failures, no matter what DKIM says... so no, not using SPF completely is a bad idea.

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

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#92
post #24

Earlier quoted context omitted.

> What would be the benefit of setting up DMARC on top? 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.

[citation needed]

When properly configured, particularly at an enforcement policy of p=quarantine or p=reject, DMARC can positively impact inbox placement.

https://mxtoolbox.com/dmarc/details/email-deliverability

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#93
post #91
post #85

Earlier quoted context omitted.

Using both has to be done very carefully, because a positive result from the weaker one (SPF) will override a negative result from the stronger one (DKIM). You should maximally use DKIM and minimally use SPF. Ideally, you should not use SPF at all, but there are some senders that still don't support DKIM.

Many email providers and third party security tools default settings automatically bounce or block SPF failures, no matter what DKIM says... so no, not using SPF completely is a bad idea. 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 sen…

SPF failures overriding DKIM successes is a direct violation of RFC 7489 section 4.2 [1]. I have never observed such behavior in the wild, though my experience may be more limited than yours. There are two possible explanations anyway, one is that the DMARC record was missing or misconfigured, the other is that the DKIM check did not actually succeed even though you had reason to believe it should have (e.g., misaligned sender domain, invalid/stale/rotated key, etc.).

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

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#94

Earlier quoted context omitted.

I'm not familiar with Outlook's resending, but the use case is supported if the sender uses DKIM. If the email is forwarded without changing any details, it can keep the DKIM signature. That allows the forwarded email to still pass 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 fr…

I have a long-standing email address that forwards to an email system that I run. The operator of the forwarder switched to using Microsoft's mail infrastructure some years ago and the quality of service of the forward has degraded dramatically ever since. 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 an…

Outlook.com also seems to routinely ignore DMARC (it will bounce emails with a DMARC that's report only)

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#95
post #28

Sadly the article doesn't really touch on whether or not DMARC accomplishes anything truly useful. When I enabled DMARC for ingress email on one of my own mail servers, it ultimately ended up regularly blocking a handful emails from customers, yet virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks. The core problem is that the real need of email end users need is a way o…

The primary purpose of DMARC is to prevent impersonation not to prevent spam. I own a domain, I implement DMARC to make sure others know when email from my domain is legitimately from my domain.

Then you don't deal with email in the real world. DMARC prevents legitimate emails from people in the real world from being delivered because people make mistakes with their email systems. Passing DMARC is not a signal that the email isn't legitimate; it's merely a sign that someone correctly set up their mail server to modern standards. The email might be an impersonation, or not. There's no way to know.

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.

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#96
post #28

Sadly the article doesn't really touch on whether or not DMARC accomplishes anything truly useful. When I enabled DMARC for ingress email on one of my own mail servers, it ultimately ended up regularly blocking a handful emails from customers, yet virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks. The core problem is that the real need of email end users need is a way o…

My domain is very low traffic but, I just looked through my admin email account and opendmarc has rejected 18 attempts by spammers just this past week. More were rejected by my domain's DMARC policy.

It works at small scale when you self-select for technical competency. It does not work at larger scale when that self selection is no longer possible.

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.

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#97

Earlier quoted context omitted.

> virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks. 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.

Can we use DMARC to ask Gmail to close registrations? Google Calendar to allow far fewer people the ability to send invite notifications? Firebase to close registrations? Azure? Microsoft 365? AWS SES? 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.

Exactly this. Spammers have the technical competence to overcome any technical hurdle, so using evidence of technical competence achieves nothing.

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".

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#98
post #95

Earlier quoted context omitted.

The primary purpose of DMARC is to prevent impersonation not to prevent spam. I own a domain, I implement DMARC to make sure others know when email from my domain is legitimately from my domain.

Then you don't deal with email in the real world. DMARC prevents legitimate emails from people in the real world from being delivered because people make mistakes with their email systems. Passing DMARC is not a signal that the email isn't legitimate; it's merely a sign that someone correctly set up their mail server to modern standards. The email might be an impersonation, or not. There's no way to know. DMARC does…

Okay but that doesn’t detract from the intended purpose of DMARC.

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#99
post #28

Sadly the article doesn't really touch on whether or not DMARC accomplishes anything truly useful. When I enabled DMARC for ingress email on one of my own mail servers, it ultimately ended up regularly blocking a handful emails from customers, yet virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks. The core problem is that the real need of email end users need is a way o…

> virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks. 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.

What spammers are using the same domain for longer than couple of hours?

What do you expect to achieve by blocking an already abandoned domain?

Re: DMARC has been public since 2012 but most company domains still don't enforce it

#100

Earlier quoted context omitted.

I have a long-standing email address that forwards to an email system that I run. The operator of the forwarder switched to using Microsoft's mail infrastructure some years ago and the quality of service of the forward has degraded dramatically ever since. 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 an…

I never understood the point of the anti-virus adding a message to _outgoing_ emails. Basically "I swear there is no virus in this email I'm sending you, trust me bro".

"We take security seriously."
Post reply on HN