DKIM Support

Would definitely like to see DKIM support on Syncro, outgoing emails are very sensitive if they can be spoofed, and SPF alone isn’t enough to prevent spoofing.

Are there plans for DKIM support in the future?

8 Likes

Also requesting this.

2 Likes

How there isn’t DKIM already is wild lol. +1 for this.

4 Likes

A client recently notified me that our reminders have gone to her spam folder. Moved DKIM monitoring to mailhardener and found the alignment issue…ACK! Switched on SMTP server usage under /settings/emails to resolve it for the clients. Still, it would be nice to have the ability to have alignment work as intended.

+1 for me too.

1 Like

DMARC alignment problems are a real issue for how Syncro is sending email. We just posted this feature request below:

As far as DKIM, all of our Syncro related email is passing DKIM without any trouble.

Reid,

If I add DKIM on my company’s 365 email and DNS records, will that affect the deliverability of Syncro’s outgoing emails that are coming from Sendgrid (Syncro’s email service) and impersonating my domain?

@BrianMorris

Having DKIM and SPF and dmarc setup for your own domain will make the emails that go directly through your SMTP servers look great.

It won’t, however, make the emails that impersonate you look better. And, if you have a restrictive DMARC record, it may cause them to stop getting delivered at all. Please see the following screenshots. We have SPF, DKIM, and a restrictive DMARC policy enabled for our domain.

Also, if you have DKIM setup for your domain → The emails that go out though Sendgrid that impersonate you will fail DKIM because they did not go out via the email server for which you have DKIM setup. The reason is the receiving email server tries to authenticate your emails via the DKIM signature you have for your domain’s email server (because of the impersonation), but the emails are being sent from a different email server than the one you have DKIM keys for in your dns records.

There is a way to set DKIM authentication up with Sendgrid, but it is aimed working with the hosting domain (Syncro’s infrastructure). When Syncro tries to impersonate your domain on outbound emails, it makes it impossible to DKIM authenticate via Syncro’s DKIM or via your own domain DKIM.

Here is what the overview of a Syncro notification looks like when we receive it:

Relevant Details:

ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@syncroemail.com header.s=s1 header.b=xe0Hjz75;
spf=pass (google.com: domain of bounces+6080070-0607-vaughn.reid=vchc.biz@email.syncroemail.com designates 168.245.102.208 as permitted sender) smtp.mailfrom="bounces+6080070-0607-vaughn.reid=vchc.biz@email.syncroemail.com";
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=syncromsp.com
Return-Path: bounces+6080070-0607-vaughn.reid=vchc.biz@email.syncroemail.com
Received: from o1.email.syncroemail.com (o1.email.syncroemail.com. [168.245.102.208])
by mx.google.com with ESMTPS id e14-20020ac845ce000000b0034306414e21si257078qto.502.2022.08.10.11.51.36
for vaughn.reid@vchc.biz
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Wed, 10 Aug 2022 11:51:37 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounces+6080070-0607-vaughn.reid=vchc.biz@email.syncroemail.com designates 168.245.102.208 as permitted sender) client-ip=168.245.102.208;
Authentication-Results: mx.google.com;
dkim=pass header.i=@syncroemail.com header.s=s1 header.b=xe0Hjz75;
spf=pass (google.com: domain of bounces+6080070-0607-vaughn.reid=vchc.biz@email.syncroemail.com designates 168.245.102.208 as permitted sender) smtp.mailfrom="bounces+6080070-0607-vaughn.reid=vchc.biz@email.syncroemail.com";
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=syncromsp.com

Here is what a ticket reply looks like that gets sent from Syncro via our SMTP server:

Relevant Details:

ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@vchc.biz header.s=google header.b=LZz3zz1i;
spf=pass (google.com: domain of helpdesk@vchc.biz designates 209.85.220.41 as permitted sender) smtp.mailfrom=helpdesk@vchc.biz;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=vchc.biz
Return-Path: helpdesk@vchc.biz
Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
by mx.google.com with SMTPS id n22-20020ac81e16000000b00340fa17765fsor13198272qtl.54.2022.08.10.05.43.39
for vaughn.reid@vchc.biz
(Google Transport Security);
Wed, 10 Aug 2022 05:43:39 -0700 (PDT)
Received-SPF: pass (google.com: domain of helpdesk@vchc.biz designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41;
Authentication-Results: mx.google.com;
dkim=pass header.i=@vchc.biz header.s=google header.b=LZz3zz1i;
spf=pass (google.com: domain of helpdesk@vchc.biz designates 209.85.220.41 as permitted sender) smtp.mailfrom=helpdesk@vchc.biz;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=vchc.biz

We have a restrictive DMARC policy tp make it much harder for someone to spoof our domain and be able to actually have the email delivered:
v=DMARC1; p=reject; adkim=r; aspf=r;

With that restrictive DMARC policy, we and none of our clients get any of the emails that come from our Syncro Instance through Sendgrid while impersonating us. (Once in a great while we will receive one, but 99% get rejected – as they should with our DMARC policy).

Wow, those images that you included, that is that Header Analyzer tool or something else?

This is great, thanks for passing along your expertise! So in summary, if I set DKIM, it shouldn’t impact the Syncro/Sendgrid outgoing email deliverability. BUT, if I add DMARC, I can control the deliverability of Syncro/Sendgrid outgoing emails depending on restrictiveness.

My next question is how the integration working with Syncro sending via SMTP via 365. Do I need to have a paid email account with an app password – I’d rather not do an app password, I’d want to do Modern Authentication. (You may not know that since you apparently use Gsuite.)

@BrianMorris

I edited my response to make it a bit clearer.

DMARC allows you to create a rule in your DNS about what a receiving email server should do for emails that appear to come from your domain when they pass or fail DKIM and SPF. There is a lot of nuance to this process that is built into the standard. There are both a straight-up pass and/or fail and also something called a policy alignment pass/fail. I suggest spending a couple of hours reading and then using some tools to help you visualize. There are a lot of nice free and paid tools out there to help with creating the dns records and also tracing things to see where something goes wrong. I use the tools at MX Toolbox a lot.

That is the top part of the “View Original” option in Google Mail.

@BrianMorris

I think the process is similar on both the MS365 and Google Workspace side of things. If you use 2FA, you will need to use App Passwords.

MS365’s default security rules force 2FA. You should keep 2FA enabled. In MS365 manually enable the option that allows for traditional/legacy Auth for the account and then set an App password after logging into the account and setting up 2FA.

If you don’t see the legacy/traditional Auth option for the account, you may need to go into the security policy settings in Azure AD and change this so the option exists. On the Google side, we can create OU’s and apply completely different security policies to each OU, and I’m assuming you can do the same thing on the MS365 side. This is handy if you have several “service” type accounts (printers, scanners, 3rd party websites, etc.) and need a different policy from the one the “real people” user accounts use.

The app password will expire the same as the account login password. So, you will either need to periodically change this or set up the account so the password never expires.

I have seen recent information that Microsoft is changing how some of this works on their end, so my overview above may not be super accurate. The last time we did this kind of setup for a client was about a month ago as most of our SMB clients live in and prefer Google Workspace.

This is exactly why I didn’t want to use my own SMTP – I don’t want to have any legacy authentication in 365 turned on or any ability to do App Passwords.