DKMI/DMARC setup

[RoadRunner]

Hi,
have someone with an SBS2011 (soon replaced with O365).
Currently the server uses spamhero to send/receive mail. and we have SPF records setup and all working fine.
Now they use some cloud CRM that sends emails as well. So far we had SPF records and all worked fine.
Lately a lot of their mail is going to junk or is not received at all from that system. The tech guys say we need to setup DKMI/DMARC.
I'm very confused as to where this has to be setup. With Mailchimp for example they provide the DKMI details. As the email gets send from their platform should not they provide the key details.
I have no clue as where we would need to setup this. One key goes in DNS but the private one would that go to the SBS or spamhero or the CRM provider ?

Matt

 

[YeOldeStonecat]

Well...I'm not an expert in those, I saw some reply in a post about these by someone here who seemed quite fluent in it.

But I'm going around setting up DKIM and DMarc for our clients on O365...so I've been following the guides for doing this for O365.

Assuming you already have SPF records setup correct, for outbound, I believe DMarc leans on the SPF..and performs actions based on what you tell it to do by default.
https://technet.microsoft.com/en-us/library/mt734386(v=exchg.150).aspx

As for DKIM...this guide wrote a pretty quick guide that explains it with a good example....
https://jaapwesselius.com/2017/03/01/dkim-in-office-365/

So what you do is similar to what we used to do with most of our clients before O365 came along and took most of 'em from on-prem Exchange. Instead of SpamHero, we have our dual SpamTitan filters (different locations, one being MX1 and another being MX2 in case MX1 is down), and we have 3x offsite *nix SMTP servers for outbound.

We've included all of those IPs in one of our additional domains SPF records. We created a short domain name for our use with various services we use. Let's pretend that domain I used is "catspad.org"

So for our all our clients SPF records, their SPF record is simply v=spf1 a include:catspad.org -all

And DMarc should lean on that.

 

[Markverhyden]

Due to spamming problems all of these domain email measures need be performed.

 

[trevm999]

Well...I'm not an expert in those, I saw some reply in a post about these by someone here who seemed quite fluent in it.

Can't even remember my name yet
jk, you might not be talking about me, but I do think I did make a decent post regarding SPF/DKIM/DMARC not too long ago

I have no clue as where we would need to setup this. One key goes in DNS but the private one would that go to the SBS or spamhero or the CRM provider ?

The private key for DKIM (DMARC can be thought of of a better evaluation system for SPF and DKIM) needs to go on the system that is the last one to do any modifications to an outgoing email. If a DKIM signature was made on an email, and then that email is modified later down the line, that DKIM signature is no longer valid.

So if this CRM system is using it's own emailing server that is blasting out marketing emails, either you need to add their public DKIM key for that email server to your DNS records, or be able to add/generate a private DKIM key for that email server to use to sign the emails being sent from your account on that server and add the corresponding public key to your DNS records.


Have you confirmed that the emails coming from the CRM are passing SPF? DKIM and DMARC are important, but usually SPF is good enough for spam filters. You can also have emails passing DMARC with them only passing SPF and not passing DMARC. It is quite possible the CRM isn't set up for DKIM.

 

[RoadRunner]

The CRM sends out the emails direct and so far we had the SPF records setup and that worked fine. So if the CRM sends it out they have to have the private key on their mail server and have to give me the public key to enter in DNS ?

I think they just want to blame us for it but I have to get back to them if we can set it up as of course they say it's our problem.

@YeOldeStonecat so you have an SPF record for some domain you picked and added all the IPs to that one and including this general domain for all your customers does the trick rather than changing SPF records for every single one ?

 

[YeOldeStonecat]

Can't even remember my name yet
jk, you might not be talking about me, but I do think I did make a decent post regarding SPF/DKIM/DMARC not too long ago
.

Indeed you are correct...I just did a quick search, Nov last year it was. I owe you a cup of coffee sir!

 

[YeOldeStonecat]

@YeOldeStonecat so you have an SPF record for some domain you picked and added all the IPs to that one and including this general domain for all your customers does the trick rather than changing SPF records for every single one ?

We still make an SPF record for each and every client of ours that we have...we just start with including our abbreviated domain if they have an on-prem Exchange server. Since we set on-prem Exchange to SMTP relay to our SMTP outbound servers. And multi-function devices...scanners that send email for example....since our SMTP servers are older compatible linux it's easier to setup MFPs to send to them. Our two Spam Titan spam filters also sometimes to SMTP relay...so those two IPs (our office, and one down in Miramar FL)...are included in our domains safe list. And we have the host names of the outbound servers of RackSpace/LiquidWeb...in case some clients have a hybrid with a few POP/IMAP accounts (not many..but just to cover it).

So it makes it easier to configure each clients DNS in that SPF record...just doing the "v=spf1 a include:catspad.org -all" covers all of those IPs in one easy swoop! Now...SOME clients may need to have email legitimately sent from other sources. Like if they do marketing campaigns through BlacKBaud online, or iModules. So "per client"..we add those to the SPF we have above...so it has our domain, and also those domains. Or the client may have a "contact/submit" form on their website that submits emails via some SMTP engine hosted where their website is, so you need to add that domain or range of IPs to the SPF record. And perhaps there's a unique setup at the client with a multi function machine that sends out directly, or...if you feel like wrestling with the clients MFP to have it send to their Office 365 tenant via one of the several ways you can sometimes get working...so you have to authorize the clients offices static WAN IP.

The danger is...you can't go too crazy...a lot of SPF analyzers will start warning you if the SPF record is too lengthy.

 

[TAPtech]

Went down this DKIM train for my own domain a few weeks ago. I'm almost positive you need to work with the sending email server, as mentioned before, to get the private keys. So you won't be able to setup DKIM on your domain for a server that is outside your control... without help from their tech guys.

I tried this with Repairshopr. Once I enabled DKIM on my domain, everything from RS started going to spam. I spent a lot of time trying to get it to work, but at the end of the day left DKIM enabled and just told RS to send from their default address. I can't imagine any client, ever, mentioning that a ticket or invoice didn't come directly from my domain. So whatevs, ya know?

 

[trevm999]

The CRM sends out the emails direct and so far we had the SPF records setup and that worked fine. So if the CRM sends it out they have to have the private key on their mail server and have to give me the public key to enter in DNS ?

Their system needs to be the one creating the DKIM signatures for the emails, so either you need to be generating the keys and giving them the private key, or they should be doing it and giving you the public key. Either way, this cannot be done without them.

 

[RCHavok797]

The SPF record can get messy really quickly. It is limited to 10 DNS lookups. Below is taken from MXToolbox.

Your SPF record required more than 10 DNS Lookups to be performed during the test. The number of "include" mechanisms and chained "redirect' modifiers should be kept to a minimum.

According to RFC 7208, 'SPF implementations MUST limit the number of mechanisms and modifiers that do DNS Lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier"'. The mechanisms of: "include", "mx", "a", "ptr", and "exists" count against the limit of 10 lookups. The "all, "ip4", and "ip6" mechanisms do not count against the limit of 10 since they do not require a DNS Lookup.

SPF implementations should be restrict the number of DNS Lookups to 10 per check in order to explicitly limit how much data will be accepted to:

• Prevent excessive bandwidth usage or memory usage
• Prevent DoS attacks

If you use the "include" in your SPF record, it will have referenced SPF records evaluated with your SPF record and as a direct result the DNS Lookup count is dependent upon third parties. If you are close to reaching your limit of 10 DNS Lookups and someone in your "include" adds additional DNS record to their own SPF record, you could easily go over your limit of 10.