Implemented all of these on a bunch of my domains a few weeks ago. Two cautions related to whether your email can be forwarded by your recipients:

1. SPF -all can break forwarding with DMARC p=reject. If your recipients tend to forward your email, you probably want to stick with SPF ~all (or DMARC p=none) until standards settle (and get widely implemented) around rewriting headers during forwarding. [1]

2. Hotmail and Outlook.com recently introduced a change that breaks forwarding from any DMARC p=reject or p=quarantine sender, through a hotmail.com or outlook.com address, to any recipient MTA that enforces DMARC. There's not really anything you can do about this (as a sender) other than not use DMARC, so hopefully that gets fixed soon. [2]

[1]: https://blogs.msdn.microsoft.com/tzink/2015/07/12/what-is-th...

[2]: https://blogs.msdn.microsoft.com/tzink/2016/05/19/why-does-m...

PostMark also has a helpful (and free) service that parses and summarizes the DMARC reports: https://dmarc.postmarkapp.com/. (And you don't have to be using PostMark to use this service.)

https://dmarcian.com/ is a really nice service. Their support was also very helpful while trying to figure out the same things you did.

Since there is a 10 query limit on SPF, if you delegate your SPF to third-parties like Google then your SPF might blow up unexpectedly if they increase the number of records on their side. Dmarcian monitors that for example.

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!

I run a small Saas company that does mail forwarding as you mentioned above ("send mail as the logged-in user"). If not putting the user's email as FROM, how do you recommend handling it?

I should note, I current set the FROM as "John Smith <[email protected]>" 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 address gets auto-added to their address book, they may accidentally send to it later: the client autocompletes "John Smith", and the user doesn't realize it's actually your donotreply email.

One way to cut down on this is to include your company in the display name. I usually use:

    From: "John Smith via ExampleCo" <[email protected]>

but have also had good results (delivery and open rates) with:

    From: "ExampleCo for John Smith" <[email protected]>

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" <[email protected]>

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

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

On the receiving side: Ensure that your world-facing port 25 smtpd is properly pipelining all incoming emails through openDKIM so that their headers are tagged with openDKIM validation or lack thereof. This can work in conjunction with spamassassin.

Thanks for the tips