Should we avoid 'legitimate' spoofing of “From” address or just ignore DMARC failure

Question

I am on a team building a SAAS application. Part of the application will send out scheduled reminders to our customer's clients. The project description is asking for the ability for our app to send out those reminder emails using an email address of the customer's choice, preferably their own domain, essentially spoofing the email "From" address.

Our customers would be businesses using our service to send out reminders "on their behalf" to their companies clients. The expectation is that they would want their clients to think they were sending out the reminders themselves, and not "farming out" the responsibility to a third party. So they would likely want our service to be as invisible as possible. This is in fact how reply.io, grade.us and several others work. They ask you to fill out details and include what email address you want the email to appear as coming from.

I immediately balked at this idea having been in charge of a mailing list software and dealt with the fallout back in 2014 with Yahoo and their DMARC policy snafu.

But it was pointed out to me that many other services, like reply.io for instance, do this with their customers. So I tested the email reminders they send out and found that they pass DKIM but Softfail on SPF and Fail on DMARC. However the emails they send still seem to be getting through ok, having tested sending to Gmail, AOl, & Yahoo. Those services do mention that you should not use a "free email address like Gmail, Yahoo, etc" as the "From" email because that will cause emails to be rejected.

They of course all have the typical message...

...google.com does not designate 2607:f8b0:400e:c00::233 as permitted sender

But they also have for the SPF

...the domain somedomain.com reports 74.125.83.42 should not be sending mail 
using it's domain name, but is not forbidden from doing so

So having dealt recently with a reconfiguration problem on a server where the SMTP reverse DNS lookup was failing along with both DMARC and SPF and that was causing emails to be immediately rejected from AOL and Yahoo, I am not totally clear on how these services can reliably get mail through.

Is failing SPF and DMARC not really that bad? I feel like choosing to straight up spoof email in this way is going to have other consequences down the road.

Some services, such as reviewtrackers.com, are using sendgrid which works hard on reliability, seem to avoid this practice. Emails from them come through like MY Name <[email protected]> via sendgrid.info and the email shows as being mailed by email.reviewtrackers.com and being signed by sendgrid.info

This latter method would seem to me to be more transparent and reliable, but a director in our project thinks that it might cause the email to appear not as personal or ignored because some may notice it is from a third party.

Mainly I am really wanting to know if spoofing emails and just ignoring the fact that DMARC is going to fail is really considered a legitimate practice, and how it might come back to haunt us.

Answer 1

Plain and simple: Using my domain address as the sender for mail you send me will get you rejected. This is commonly done by spammers, and rarely done by legitimate sender, especially in a corporate sending. As reflect in DMARC, SPF, our mail server configuration and published Email Policy, only our servers are permitted to send email claiming to originate from our domain. If you don't want to be treated like a spammer, don't act like one.

GMail, Yahoo, and AOL have a large number of users that send mail directly from their laptops, or other devices using their freemail account as the sender. Their policies are somewhat lenient in this respect. Do NOT rely on freemail services to determine whether mail will get rejected.

I have seen reports that sending email into these services is getting increasingly difficult for senders who do not follow established standards and conventions.

DMARC includes delivery policies which are entirely advisory and includes the action none to be taken with failing message. It is the receiving domain's choice on what to do with messages that fail validation. They may not enforce the requested policy.

SPF failures for legitimate senders are unfortunately far to common. Many MX servers will accept email that fails SPF, although the mail may be filed or flagged as SPAM. On our servers SPF failures will introduce a significant delay until you are able to successfully send the message.

Many sending email servers are listed on public whitelists, which may allow the to bypass some of the checks above. Which whitelists, if any, are used is the receiving administrators choice. The administrator will also choose which if any standards and conventions can be ignored by whitelisted servers.

I would recommend using a noreply address such as "[email protected]" as the envelope sender. The address in the from header should be something like:

"Your Reminder Service" <[email protected]> 

The "[email protected]" address should validate as a recipient. It is common to bit bucket incoming mail to noreply. It is good practice to parse incoming bounce messages to identify which addresses are bouncing. You should stop sending to addresses which are permanently rejected, as well as those that have not accepted mail for a significant period. (There may be legal requirements to do so.)