Hacker News Reader

Comment by technion | Hacker News Reader

Email is in a funny space. Spf showed up. And although it meant some political fights when people expected to send email from anywhere, it was free to run in the dollar sense. Same with dkim.

Dmarc is increasingly required to get past spam filters. And doing dmarc properly requires a reporting service. Either you run servers or use a hosted service like the one that created this page. That's fine for some business, but putting a cost on dmarc reporting and then making dmarc a heavy signal in spam filters is a huge pain for some scenarios.

It's not highly expensive, but on non monetized side projects it can frustrating how how much the internet expects you to have dmarc on every domain now.

View on HN

> And doing dmarc properly requires a reporting service.

This is incorrect.

DMARC requires nothing but an email address to send reporting to. It costs nothing to implement and there are open source [0] solutions out there if you want to monitor the reporting being sent.

And to clarify - the reporting you're getting back from a DMARC is either an aggregate or a forensic report. There aren't many email providers that actually send forensic reporting anymore, the 99% of reports you'll get are aggregate in nature.

And finally, remember that if you don't have a policy of "REJECT" set on your domains, DMARC isn't doing you a whole lot of good.

[0] https://github.com/domainaware/parsedmarc

> This is incorrect. DMARC requires nothing but an email address to send reporting to.

This is also incorrect. Reporting (rua/ruf) are optional.

> if you don't have a policy of "REJECT" set on your domains, DMARC isn't doing you a whole lot of good.

With "quarantine" failing emails will go to spam, which is plenty good enough in most cases.

Being able to firmly reject all unauthenticated messages is still the target end state. The risk of a threat actor sending an email that looks completely legit, and simply asking the user to "check their spam folder", is very real.

> This is also incorrect. Reporting (rua/ruf) are optional.

I never stated RUA/RUF were required.

My intent was to state that the parent I was replying to implied "services" or "servers" were required to collect and/or process reporting. One can simply collect reporting and process offline or simply consume manually. I do this, personally, for a few low email volume domains I own. You can't get RUA/RUF any other way.

You stated that an email address is required. It's optional. So the requirements are effectively non-existent (although who doesn't have an email address).

> You can't get RUA/RUF any other way.

There are free services that provide analysis, such as https://dmarc.postmarkapp.com/, although arguably you still need an email address to sign up. But it is another, actually useful, way to receive the reports.

Yes, an email address is required to get RUA/RUF. I never stated this was or wasn't in line with the RFC.

> There are free services that provide analysis, such as https://dmarc.postmarkapp.com/, although arguably you still need an email address to sign up.

YES. That's what I said.

Once you get DMARC setup correctly you can easily run it without any sort of reporting service.

Using DMARC is more about having a process for properly adding new senders once everything is setup than it is a long term cost sink. You can keep a reporting service around to monitor your email delivery, but you don’t have to at all.

Do you have any personal experience regarding the DMARC requirement claim? AFAIK just having SPF and DKIM without dmarc rua or ruf is still enough to not get hit by Gmail and Office 365 (as in, they’re enough to have your email reputation reliably tied to your domain instead of the email providers having to base a spam decision on the sending IP’s spam reputation).

Unfortunately I've had many related experiences. Mail works at first or on a small scale, but eventually a customer with Google workspace mail tells you email goes to junk, and Google support sends you this article in response which describes a range of requirements including dmarc. Same story for office 365.

https://support.google.com/mail/answer/81126?hl=en

Just a note that SPF/DKIM and DMARC are not "get out of jail free card".

Google support is just brushing people off with the link and they are somewhat right, because a lot don't have anything set. There is also a bit of black magic with spam filters that Google support will never tell you about because it will be just like SEO, someone will use it to pass filters.

That said, there are multiple other reasons that your email can be qualified as spam by the spam filter. Like sending out email from one domain and having links to another domain in the body as an example. Not having "unsubscribe" links on mass mail. There are legitimate reasons to throw email to spam because some companies get their infra or "contact us" forms hacked.

In the end users can be annoying because they might not understand what "this is spam" button means for the sender - they just think your mail was annoying and they did not expect it and press that and you are qualified as a spam.

In my experience sadly few people really check its presence. Sure, there might be an aggressive spam filter in place that collects these mails. But this protection will almost always be removed once a customer or supplier couldn't contact you.

DKIM isn't hard to manage, SPF can be a pita. Although IP blocks are a very sensible network management tool (cloud provider and customers hate it), it is more difficult to administrate than setting up some domain keys. It will have to be managed whenever anything that is sending mail changes its public IP address, which very often happens if you host it in the "cloud".

Do you have a reporting service you like to use for yourself/clients?

I've never tried, but but wondered if it would it be enough to simply use a inbox@whatever inbox you have setup, most likely gmail on your domain (don't know what google calls that now workplace idk)?

In cases where it's super unlikely someone would try to send as the domain so it's just setting it up to check a box for deliverability.

You don't, but I've tried what you suggested and it fills with thousands of xml files attachments you have no hope of reading. You could just ignore them, but that gets down to what I mean by "doing it properly".

yikes. for me/clients it's just marketing so deliverability is more important than actually reading all of the reports. i guess some could potentially have an 'attack' where someone tries to spoof so I'm going to do some more research see if I can find a better solution.

Reply on news.ycombinator.com