Hosted Exchange outgoing email issues

[patseguin Global Moderator]

My company was using Rackspace for years up until the Ransomware attack and it was the best. All of our emails were delivered without issue.

Per Rackspace's recommendation, we switched and transitioned to Microsoft 365. Ever since, almost all of our outgoing emails are ending up in our customers' junk/spam folders. Anyone know why that would be and if it's something I can fix on my end? The emails still come from the exact same domain name, just a different host, Do a lot of servers detect Microsoft 365 emails as spam or something or is there some setting in my outgoing that is making them prone to be detected as spam? I can't really find any support at Microsoft. They just direct you to forums.

Fellow mods - if this is the wrong section, feel free to move.

Edit: I did a blacklist check for my domain and an IP address is listed which points to Bluehost, however my emails are supposed to be going through MS 365.

[Matthew S.]

Are you sure all the DNS entires are set up correctly?  DKIM is set to Microsoft's? SPF, etc?

[limok]

  On 09/03/2023 at 18:15, Matthew S. said:

Are you sure all the DNS entires are set up correctly?  DKIM is set to Microsoft's? SPF, etc?

Expand  

Agreed, SPF record is a must on your domain that email is being sent on. 

[Matthew S.]

I had a hell of a time a year or two ago, had to get Microsoft support involved, something was messed up with the spf/dkim they were providing me for my domain.

tbh sounds similar to my issue.

[+InsaneNutter MVC]

Follow the steps here to setup SPF, DKIM and DMARC: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-spf-configure?view=o365-worldwide

After you have done that you can now use https://www.mail-tester.com/ to confirm everything is working correctly, you should score 10/10 and have no real issues with email deliverability after that.

[patseguin Global Moderator]

  On 09/03/2023 at 21:01, limok said:

Agreed, SPF record is a must on your domain that email is being sent on. 

Expand  

I have the spf record set. The instructions said not to delete the bluehost entry if there was one which I had done, so I went back in and added the bluehost entry and appended the MS one like this: v=spf1 a mx ptr include:bluehost.com include:spf.protection.outlook.com -all

Does that look correct?

[patseguin Global Moderator]

  On 10/03/2023 at 10:20, InsaneNutter said:

Follow the steps here to setup SPF, DKIM and DMARC: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-spf-configure?view=o365-worldwide

After you have done that you can now use https://www.mail-tester.com/ to confirm everything is working correctly, you should score 10/10 and have no real issues with email deliverability after that.

Expand  

That looks like way more than their setup instructions told me to do. I'm not really even sure what I need to do now. I put in the spf record they told me. I just did that mail tester and got 2.8/10

 

[+InsaneNutter MVC]

The Exchange 365 setup instructions don't actually have you setup DKIM and DMARC, however it really helps if you do.

I presume your website hosted with Bluehost will also be sending email, if i believe that would be correct. I have done this a couple of times however not for a long while now, so i'd double check here: https://www.dmarcanalyzer.com/spf/checker/ to be 100%

This guide has a few more screenshots showcasing the DKIM setup: https://lazyadmin.nl/office-365/configure-dkim-office-365/ which might be easier to follow.

Finally for DMARC you can essentially create a new DNS record on your domain with the following to be covered:

Record type: TXT

Record Name: _dmarc

Record Content: v=DMARC1; p=none; rua=mailto:info@domain.com;

For the above record you can gradually work up to p=reject when you are confident everything that should be sending email on behalf of your domain is working correctly

• p=none = if DMARC authentication fails no action should be taken on that mail - aka it ends up in someone's inbox regardless of if its a legit email from you (not ideal long term)
• p=quarantine = if DMARC authentication fails the mail should go to someone's spam folder
• p=reject = if DMARC authentication fails the email should be rejected by the mail server receiving it

[grunger106]

Looks like your SPF record is still not correct or it hasn't yet propagated fully, paste it here (or expand the errors on the output of the test)

Also looks like you haven't enabled DKIM yet
DKIM is pretty straightforward: 

Go to https://security.microsoft.com/dkimv2 - select your primary domain initially - hit the slider to on and it will fail, but it will fail with an error that tells you exactly what you need to do and present you the records.
You need to create the CNAMEs it asks for in your DNS zone (selector1._domainkey pointing at the syntax it gives you and repeat with selector2._domainkey and it's associated content)
Then wait for propagation and and go try the slider again and it should then enable.

If you are setting up DMARC ensure you enable DKIM first.

 

[patseguin Global Moderator]

  On 10/03/2023 at 16:29, grunger106 said:

Looks like your SPF record is still not correct or it hasn't yet propagated fully, paste it here (or expand the errors on the output of the test)

Also looks like you haven't enabled DKIM yet
DKIM is pretty straightforward: 

Go to https://security.microsoft.com/dkimv2 - select your primary domain initially - hit the slider to on and it will fail, but it will fail with an error that tells you exactly what you need to do and present you the records.
You need to create the CNAMEs it asks for in your DNS zone (selector1._domainkey pointing at the syntax it gives you and repeat with selector2._domainkey and it's associated content)
Then wait for propagation and and go try the slider again and it should then enable.

If you are setting up DMARC ensure you enable DKIM first.

 

Expand  

I pasted it above, here you go: v=spf1 a mx ptr include:bluehost.com include:spf.protection.outlook.com -all

[limok]

SPF is still showing as fail on mxtoolbox website. Take out "a mx ptr" for now and see how that works. 

[+mram Subscriber²]

  On 10/03/2023 at 15:04, patseguin said:

I have the spf record set. The instructions said not to delete the bluehost entry if there was one which I had done, so I went back in and added the bluehost entry and appended the MS one like this: v=spf1 a mx ptr include:bluehost.com include:spf.protection.outlook.com -all

Does that look correct?

Expand  

using "a mx ptr" is really not recommended in general.  You didn't give the context though.  The point is that you really don't want to use extra DNS lookups, and there IS a HARD limit to how many lookups a receiving SMTP service will do before it times out and just rejects.  But from a standpoint of all of your mail being delivered from M365, you don't need those.

I realize you were told not to delete the bluehost entry, but unless you're actually sending mail using that host, get rid of it.  What you're doing is continuing to allow it to send mail.  This isn't a grey area, you only want SPF to contain the hosts you use for sending mail using that domain, full stop.

You want to avoid making a truckton of changes to DNS, in fact, you really need to look at your DNS expiry times, as regardless of making a change, you need to allow it to time out worldwide for it to not fail.  For example, you make a change right now, but MY dns server may not pick up the changes until after the expiry passes.  I always recommend to make these changes slowly as a result -- the irony is that if you don't the reputation of your hosted domain might be hurt.

Edit:  Sometimes DNS expiry times is set to a week, which means in practice it can take that long or longer for a receiving service to even recognize changes to the SPF record.

Get an example of a rejected/spammed piece of mail and look at the headers for WHY it was rejected.

Use MXToolbox to get a moment-in-time example of the health.

Hope any of this helps.

[patseguin Global Moderator]

  On 10/03/2023 at 16:29, grunger106 said:

Looks like your SPF record is still not correct or it hasn't yet propagated fully, paste it here (or expand the errors on the output of the test)

Also looks like you haven't enabled DKIM yet
DKIM is pretty straightforward: 

Go to https://security.microsoft.com/dkimv2 - select your primary domain initially - hit the slider to on and it will fail, but it will fail with an error that tells you exactly what you need to do and present you the records.
You need to create the CNAMEs it asks for in your DNS zone (selector1._domainkey pointing at the syntax it gives you and repeat with selector2._domainkey and it's associated content)
Then wait for propagation and and go try the slider again and it should then enable.

If you are setting up DMARC ensure you enable DKIM first.

 

Expand  

OK I'm doing this. I see 2 domain key choices. My email domain used is coveredwagonpromotions.com, not the onmicrosoft.com one. I'm not sure why that is listed as the default signing domain. Should I just do what you said for both of them or is there a way to set the domain that I use as the default signing domain?

  On 11/03/2023 at 07:47, mram said:

using "a mx ptr" is really not recommended in general.  You didn't give the context though.  The point is that you really don't want to use extra DNS lookups, and there IS a HARD limit to how many lookups a receiving SMTP service will do before it times out and just rejects.  But from a standpoint of all of your mail being delivered from M365, you don't need those.

I realize you were told not to delete the bluehost entry, but unless you're actually sending mail using that host, get rid of it.  What you're doing is continuing to allow it to send mail.  This isn't a grey area, you only want SPF to contain the hosts you use for sending mail using that domain, full stop.

You want to avoid making a truckton of changes to DNS, in fact, you really need to look at your DNS expiry times, as regardless of making a change, you need to allow it to time out worldwide for it to not fail.  For example, you make a change right now, but MY dns server may not pick up the changes until after the expiry passes.  I always recommend to make these changes slowly as a result -- the irony is that if you don't the reputation of your hosted domain might be hurt.

Edit:  Sometimes DNS expiry times is set to a week, which means in practice it can take that long or longer for a receiving service to even recognize changes to the SPF record.

Get an example of a rejected/spammed piece of mail and look at the headers for WHY it was rejected.

Use MXToolbox to get a moment-in-time example of the health.

Hope any of this helps.

Expand  

OK thank you! I change it to just what MS said to have in there.

[patseguin Global Moderator]

Update. I did both things that everyone told me to do and now got this at mail tester. Do the yellow checks mean there are still things that need to be done? I'm curious about the "do not have DMARC record" and "reverse DNS does not match sending domain" (is this because of the hosted Exchange?).

[+mram Subscriber²]

  On 14/03/2023 at 10:52, patseguin said:

Update. I did both things that everyone told me to do and now got this at mail tester. Do the yellow checks mean there are still things that need to be done? I'm curious about the "do not have DMARC record" and "reverse DNS does not match sending domain" (is this because of the hosted Exchange?).

Expand  

Having SPF is usually fine, DKIM is better, DMARC is best.  But living without DMARC is fine for most, truly.  Let everything else settle and be good before you consider DMARC policies.

All those yellow checkmarks are fine, in context.  

[patseguin Global Moderator]

  On 14/03/2023 at 11:24, mram said:

Having SPF is usually fine, DKIM is better, DMARC is best.  But living without DMARC is fine for most, truly.  Let everything else settle and be good before you consider DMARC policies.

All those yellow checkmarks are fine, in context.  

Expand  

OK so other than everything I've done, there's nothing else that could be done on my end? I'm hoping a lot of our emails are still not going to customer spam. This never happened with Rackspace who in fact used Exchange. That's why I'm not sure why the spam issues just moving directly to Microsoft and using the same domain. Thanks so much for your help.

[binaryzero]

Remove the second MX record pointing to the root domain, not required.

 

[+mram Subscriber²]

  On 14/03/2023 at 11:54, patseguin said:

OK so other than everything I've done, there's nothing else that could be done on my end? I'm hoping a lot of our emails are still not going to customer spam. This never happened with Rackspace who in fact used Exchange. That's why I'm not sure why the spam issues just moving directly to Microsoft and using the same domain. Thanks so much for your help.

Expand  

Your best bet is to send a test message to a google mail account and look at the headers and have them analyzed  .. I think MXToolbox does it, but also here Message Header Analyzer (mha.azurewebsites.net)  Once you look at it you can see the scores and usually why the score is good/bad.  

You can directly affect the score of the sending domain - your domain - through SPF/DKIM/DMARC and none of that is a mystery.  The only transient problems are DNS expiry.

The most common issues I've run into is just too much assumption.  For example that "a mx ptr" issie is huge -- I looked it up and SPF only does 10 DNS lookups at all before it errors out.  Those commands alone are 3 DNS lookups alone, you had the M365 one in there (which actually ends up being 2 dns lookups), and holy hell, you look at bluehost.com -- it's got SEVEN named lookups in and of itself before you even drill into the recursion.  It's no question, that was the problem.

This is Bluehost's SPF:

"v=spf1 ip4:209.17.115.0/24 ip4:64.69.218.0/24 include:spf2.bluehost.com include:_spf.qualtrics.com include:_spf.google.com include:_spf.salesforce.com include:sparkpostmail.com include:spf.mailjet.com include:spf.protection.outlook.com -all"

Each underline is a new DNS lookup.  Google alone is 3 DNS lookups - that'd be 10 total right there, not to mention more lookups for "a mx ptr"...  a receiving system would never even make it to the M365 lookups before failing.  Checks out.

Per the SPF RFC:  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. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit.

I'm just explaining why the original "v=spf1 a mx ptr include:bluehost.com include:spf.protection.outlook.com -all" failed.   Without drilling into it, SPF would generate a permerror and may not even reply with a viable and valid response - if even accepted, the first 10 are the only accepted.  Order matters too.  Not that I'm encouraging you to change but if you had it as...
     v=spf1 a mx ptr include:spf.protection.outlook.com include:bluehost.com -all
     (reversing the include order)
... it might've actually worked, even if it still generated a permerror.

It might seem to you that you just moved and suddenly you get these errors but looking at and analyzing the headers should ALWAYS be part of an analytics process when moving mail domains.  These above issues are black and white, and they would be visible in header logs.  I assumed what bluehost was doing even before drilling into the details because a lot of hosting companies like bluehost are notorious for stacking their SPF TXT records.  Bad juju, and makes it hard to leave, like somehow moving is bad.  It's not.

[patseguin Global Moderator]

  On 14/03/2023 at 11:24, mram said:

Having SPF is usually fine, DKIM is better, DMARC is best.  But living without DMARC is fine for most, truly.  Let everything else settle and be good before you consider DMARC policies.

All those yellow checkmarks are fine, in context.  

Expand  

I just emailed a customer and they replied and I noticed in the subject this...Does that just mean that my SPF change this morning hasn't propogated yet?

 

[binaryzero]

Talk about doxing... lol

The TTL on your MX and SPF records is far too long, set them to 3600 (1hr) as per what MS provides you.

[patseguin Global Moderator]

  On 14/03/2023 at 13:52, binaryzero said:

Talk about doxing... lol

The TTL on your MX and SPF records is far too long, set them to 3600 (1hr) as per what MS provides you.

Expand  

They are just domains, is that bad? The shortest Bluehost give is 4 hours

[binaryzero]

  On 14/03/2023 at 14:36, patseguin said:

They are just domains, is that bad? The shortest Bluehost give is 4 hours

Expand  

I'm sure Meghen wouldn't appreciate it...

Microsoft's recommended (and what's provided) TTLs for Exchange Online records is 3600. Set MX, SPF, and Autodiscover to 3600, the others meh up to you.

Review the headers of the email to understand why SPF failed\flagged, your records may be cached at the receiver's mail gateway (could be its own time limit, or TTLs 🤷‍♂️). In the Microsoft 365 admin centre, go to Settings > Domains, verify that the domains have been configured correctly, I suspect they are if you're receiving\sending mail as expected.

If you've changed a bunch of records in a short period of time, leave things for 24-48 hrs and see what results you get.

[patseguin Global Moderator]

  On 14/03/2023 at 14:43, binaryzero said:

I'm sure Meghen wouldn't appreciate it...

Microsoft's recommended (and what's provided) TTLs for Exchange Online records is 3600. Set MX, SPF, and Autodiscover to 3600, the others meh up to you.

Review the headers of the email to understand why SPF failed\flagged, your records may be cached at the receiver's mail gateway (could be its own time limit, or TTLs 🤷‍♂️). In the Microsoft 365 admin centre, go to Settings > Domains, verify that the domains have been configured correctly, I suspect they are if you're receiving\sending mail as expected.

If you've changed a bunch of records in a short period of time, leave things for 24-48 hrs and see what results you get.

Expand  

You're probably right. I removed the image. Blue host doesn't offer 3600. 

[binaryzero]

Time to get yourself a half decent DNS provider...