Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

wpsitecare.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#51

Post by slasaus »

medmunds wrote: post #28
slasaus wrote: post #3

I think it's pretty weak they're advertising the use of "~all" in their spf records. Either use "-all" or just don't use SPF I would say. If you can't make a decisive statement about your own domain then it won't be actionable for receivers that evaluate your records.

If you use DMARC with a reject or quarantine policy, SPF hardfail ("-all") can prevent recipients from successfully forwarding mail you've sent them. Some best practices for DKIM, SPF, and DMARC (as of mid-2015) in [1], including this: > ...when an organization publishes p=reject [in DMARC], they should simultaneously change their SPF hard fail to SPF soft fail. ... A message that passes SPF and is forwarded will fai…

Interesting note about DMARC, but still, if you're concerned about breaking forwarding for your domain, then why bother using spf at all? I still don't see the benefit of setting up ~all rules.

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#52

Post by justinc8687 »

medmunds wrote: post #50
justinc8687 wrote: post #39

Earlier quoted context omitted.

I should note, I current set the FROM as "John Smith " and set Reply-To to their actual email. That said, I've seen a number of clients ignore the Reply To and send email to the donotreply.

You're doing it right. The important part to avoid DMARC filtering is that the actual email address in the From field match your actual sending domain. The display name doesn't matter (for DMARC filtering). However, there's another problem: Many email clients hide the email address part by default, and only show the display name. So the recipients may not see "donotreply" without some extra clicking. Worse, if that a…

Is there any way to deal with clients ignoring the Reply-To header or is that just an issue we have to deal with?

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#53

Post by [deleted] »

walrus01 wrote: post #31
cm3 wrote: post #24

Say I want a personal domain and have the MX not be Google or Fastmail, how complete is the implementation of these standards on major email providers' SMTP setups? Would I need to do thorough research or is it reasonable to expect it to just work in a, say, European SMTP hoster's configuration?

Any major ISP with clue is at least checking SPF, DMARC and DKIM scores on its incoming edge smtpd that talks to the world. How they use the scoring and results for spam filtering varies widely.

[deleted]

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#54

Post by aroch »

walrus01 wrote: post #34
aroch wrote: post #32

Earlier quoted context omitted.

Most people aren't in your or my position, where we might know (sometimes personally) the management at an ISP. Most people aren't in a position to build their own server. Heck, the vast majority of people who want to host any thing aren't in that position. And who wants to spend $200+/m to on their personal email? The number of colo providers who refuse to allow customers like VPS hosting companies (who buy rooms no…

I agree that the vast majority of people who use email in general, or even the vast majority of people who own a domain name and want to have their own email server are not in our position... The venn diagram of people who are capable of operating a secure Linux or *BSD based email server implementing, for example, SPF, DKIM and DMARC with postfix+opendkim+spamassassin+dovecot overlaps a great deal with the sort of p…

I'd disagree, there are several packages that make it relatively beginner friendly (Mailinabox, sovereign) -- everyone has to learn some how. There are also lots of good tutorials, and one of the great pleasures of setting up a mailserver is once you've done it you can reuse the configs. It is a great learning experience for relative novices and "greybeards" alike.

You've just cut the number of people who can do it your way down to Your last sentences dismisses everyone who doesn't do things to your impossible standards as a waste.

You're basically saying no one should run a mailserver, or learn how, or be given the opportunity to learn how. Which is sad.

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#55

Post by snassar »

aroch wrote: post #54
walrus01 wrote: post #34

Earlier quoted context omitted.

I agree that the vast majority of people who use email in general, or even the vast majority of people who own a domain name and want to have their own email server are not in our position... The venn diagram of people who are capable of operating a secure Linux or *BSD based email server implementing, for example, SPF, DKIM and DMARC with postfix+opendkim+spamassassin+dovecot overlaps a great deal with the sort of p…

I'd disagree, there are several packages that make it relatively beginner friendly (Mailinabox, sovereign) -- everyone has to learn some how. There are also lots of good tutorials, and one of the great pleasures of setting up a mailserver is once you've done it you can reuse the configs. It is a great learning experience for relative novices and "greybeards" alike. You've just cut the number of people who can do it y…

More people should learn how to run a mailserver, if only to better make decisions about when to outsource and when to keep inhouse.

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#56

Post by medmunds »

justinc8687 wrote: post #52
medmunds wrote: post #50

Earlier quoted context omitted.

You're doing it right. The important part to avoid DMARC filtering is that the actual email address in the From field match your actual sending domain. The display name doesn't matter (for DMARC filtering). However, there's another problem: Many email clients hide the email address part by default, and only show the display name. So the recipients may not see "donotreply" without some extra clicking. Worse, if that a…

Is there any way to deal with clients ignoring the Reply-To header or is that just an issue we have to deal with?

Most clients seem to respect the Reply-To header, but they're not required to [1], and some popular MS ones in particular seem to ignore it, at least in some cases [2, 3].

There are a bunch of arguments for avoiding "noreply" addresses in the first place [4, 5]. We started using our customer service email as the from/reply-to for password resets and other service emails, with good results.

But that's not a good option for messages you're sending on behalf of particular users... the replies are probably intended specifically for those users. I'm running into something similar with emailed invitations from my site, and have been thinking about ways to get the replies back to the user doing the inviting.

You could try something like:

    From: "John Smith via ExampleCo"
where "encoded-user-id" is a signed and timestamped identifier that lets you identify your "John Smith" user, so you can forward the reply to them (or insert it in their newsfeed in your product, or whatever makes sense). You'd have to be very careful to validate incoming replies, to avoid creating an open mail relay or a vector for spammers to reach your users. (Services that implement anonymous/private replies, like Craigslist, use an approach like this.)

Does anyone know of any well-tested packages that safely provide this sort of reply forwarding? Or transactional ESPs that offer it directly?

[1]: http://stackoverflow.com/questions/32696850/is-the-reply-to-...

[2]: https://medium.com/@BraunDoug/windows-10-mail-client-broken-...

[3]: http://www.geekzone.co.nz/forums.asp?forumid=86&topicid=1949...

[4]: https://www.campaignmonitor.com/blog/email-marketing/2011/08...

[5]: https://www.mailjet.com/blog/the-noreply-dilemma-going-from-...

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#57

Post by medmunds »

slasaus wrote: post #51
medmunds wrote: post #28

Earlier quoted context omitted.

If you use DMARC with a reject or quarantine policy, SPF hardfail ("-all") can prevent recipients from successfully forwarding mail you've sent them. Some best practices for DKIM, SPF, and DMARC (as of mid-2015) in [1], including this: > ...when an organization publishes p=reject [in DMARC], they should simultaneously change their SPF hard fail to SPF soft fail. ... A message that passes SPF and is forwarded will fai…

Interesting note about DMARC, but still, if you're concerned about breaking forwarding for your domain, then why bother using spf at all? I still don't see the benefit of setting up ~all rules.

I believe that DMARC requires SPF. Since I want DMARC, I need to provide a compatible SPF, which means ~all.

(And I do want to implement DMARC. Not so much to improve deliverability of my own email, but rather to prevent delivery of malicious email pretending to be from my domain.)

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#58

Post by medmunds »

Erwin wrote: post #48
dmuth wrote: post #20

Just to throw this out, I'm the guy responsible for one of the "top 10" DMARC reporting engines on the Internet in terms of volume. If anyone would like to chat about DMARC in the real world or about the DMARC reports (that they are very likely receiving from my employer's domain name), feel free to reach out to me. My email is my username at my username dot org.

Google's Postmaster tools always tell me 100% DKIM, 100% SPF but a crazy varying amount of DMARC success rate. Postmark's weekly report gives me 99.9% DMARC compliance. Do you have an explanation or theory? Our envelope-from often differs from header-From but none of those domains have a strict DMARC alignment policy.

I believe you can explain some common cases in Postmark's weekly digest like this (but would really appreciate confirmation from an actual specialist in the field):

1. "Trusted sources" (DMARC fully/partially aligned), DKIM pass, but SPF fail: a recipient has forwarded your fully-aligned email.

2. "Untrusted sources" (DMARC not aligned), DKIM fail, SPF fail: genuine spam, or email forwarding that also rewrites headers in way that breaks DKIM (like the recent Hotmail/Outlook.com forwarding problem).

3. "Untrusted sources", DKIM pass, SPF pass: properly signed and SPF'd, but your envelope-from domain doesn't match the header-From domain. If your DMARC policy is reject or quarantine, these messages won't get delivered.

One way to get case 3 is with a vendor sending on your behalf, where you've included their SPF in your own record (so SPF pass), but they sign DKIM and set envelope-from using their domain. The DKIM is valid for your vendor, so passes, but doesn't match the From, so DMARC is not aligned and fails.

For example, UserVoice has this problem if you're using a custom From address in your domain. And Gmail shows this type of message as "From via ".

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#59

Post by justinc8687 »

medmunds wrote: post #56
justinc8687 wrote: post #52

Earlier quoted context omitted.

Is there any way to deal with clients ignoring the Reply-To header or is that just an issue we have to deal with?

Most clients seem to respect the Reply-To header, but they're not required to [1], and some popular MS ones in particular seem to ignore it, at least in some cases [2, 3]. There are a bunch of arguments for avoiding "noreply" addresses in the first place [4, 5]. We started using our customer service email as the from/reply-to for password resets and other service emails, with good results. But that's not a good optio…

Thanks for the help! I'm glad to see I'm not the only one with these issues.

Re: SPF, DMARC, and DKIM: How to Keep Your Email Out of the Spam Folder

#60

Post by talideon »

cebka wrote: post #41
talideon wrote: post #18

Earlier quoted context omitted.

For DKIM, rspamd/rmilter are a great alternative to OpenDKIM if you want to build the DKIM check into your regular spam checks. One minor downside of rmilter is that it will only sign the headers of mail sent by by authenticated users. This isn't a huge deal, but can be a bit of an irritation.

Rmilter now can sign mail that come from certain networks as well.

That's good to know. I'll have to check that out. The packaged version the FreeBSD port didn't have that last time I looked, but that could just have been me missing something.

Edit: just noticed the 'sign_networks' and 'our_networks' settings. Thanks for that, and thanks for rspamd and rmilter! They're great software!

Post reply on HN