Ways to improve deliverability when DKIM, DMARC, and SPF all pass?

[thecomputerguy]

I have a client who I created a new tenant for and added their domain. We'll call the domain badinsurance.com

All email accounts were setup and they started using emails like john@badinsurance.com

Shortly after they discovered they were not allowed to use Bad Insurance or badinsurance.com for their company, the reasons don't matter.

So we registered goodinsurance.com

It seemed simple enough ... I added goodinsurance.com into the tenant, added DNS for MX, DKIM, DMARC, SPF, Autodiscover ... the usual. Added goodinsurance.com email addresses as Alias's then just swapped the primary email over to all of their goodinsurance.com emails.

We do not know if they experienced deliverability issues while using badinsurance.com - it was used sparingly. The company launched officially as goodinsurance.com

They are finding that they are having an issue with deliverability, inconsistently. For example I sent myself an email from a licensed account I have in their tenant for myself, to my Gmail and it went to spam even though everything passes ... see image below. That and everything passes here as well: https://www.learndmarc.com/

Of course when it comes to deliverability it's ultimately ends up in an IT game of finger pointing.



The only weird thing I can see is goodinsurance.com DKIM is authorized by badinsurance.com but I just popped whatever MS told me to pop into the DNS.

badinsurance.com
Host Name : selector1._domainkey
Points to address or value: selector1-badinsurance-com._domainkey.badinsurance.q-v1.dkim.mail.microsoft

Host Name : selector2._domainkey
Points to address or value: selector2-badinsurance-com._domainkey.badinsurance.q-v1.dkim.mail.microsoft

goodinsurance.com
Host Name : selector1._domainkey
Points to address or value: selector1-goodinsurance-com._domainkey.badinsurance.p-v1.dkim.mail.microsoft

Host Name : selector2._domainkey
Points to address or value: selector2-goodinsurance-com._domainkey.badinsurance.p-v1.dkim.mail.microsoft

SPF for Both: v=spf1 include:spf.protection.outlook.com -all

DMARC for Both: v=DMARC1; p=none;

HALP

 

[thecomputerguy]

Maybe it's this:

 

[YeOldeStonecat]

So with the original tenant name when the 365 tenant was born...was it like...badinsurance.onmicrosoft.com?
Is ANYthing still using the badinsurance domain? If not...can you remove every trace from the 365 tenant? And DNS records in the DNS panel that point to that DKIM.

Microsoft DKIM records always point to the originanal blahblah.onmicrosoft.com tenant name. No matter what additional domains you add.
Wondering if the badinsurance.com domain has a bad rep?

 

[thecomputerguy]

So with the original tenant name when the 365 tenant was born...was it like...badinsurance.onmicrosoft.com?
Is ANYthing still using the badinsurance domain? If not...can you remove every trace from the 365 tenant? And DNS records in the DNS panel that point to that DKIM.

Microsoft DKIM records always point to the originanal blahblah.onmicrosoft.com tenant name. No matter what additional domains you add.
Wondering if the badinsurance.com domain has a bad rep?

Hmmm .. well to prevent any loss the aliases were added for badinsurance.com for the short time period that it was in service. I suppose it could be removed but I left it in there to apply aliases.

Strangely neither badinsurance.com or goodinsurance.com do not point to onmicrosoft.com for DKIM. When the tab is flipped in the security center Microsoft advises the following CNAME's.

This was done by allowing MS to auto add the DKIM records during the domain setup process under Setup > Domains

There is a new checkbox to auto-add DKIM for you ... if you allow the tenant access to add records for you automatically by logging into the domain registrar.

badinsurance.com
Host Name : selector1._domainkey
Points to address or value: selector1-badinsurance-com._domainkey.badinsurance.q-v1.dkim.mail.microsoft

goodinsurance.com
Host Name : selector1._domainkey
Points to address or value: selector1-goodinsurance-com._domainkey.badinsurance.p-v1.dkim.mail.microsoft

 

[Sky-Knight]

Dont touch it... and let it ride.

New domains are filtered as spam simply because they are new. Time and use resolve it, you have to let the automation work.

Double and triple checking DKIM is a good idea, but again new domains have crap reputation. It takes time to build.

 

[thecomputerguy]

Ughhh more calls and complaints from the same client that emails are not being delivered ... It looks like they started using this domain to send emails about 20 days ago.

 

[Sky-Knight]

Ughhh more calls and complaints from the same client that emails are not being delivered ... It looks like they started using this domain to send emails about 20 days ago.

You can double check the black lists, mxtoolbox.com for this. Double check SPF, DKIM, DMARC

But honestly... without the real domain to test I can't offer anything more specific. But if the domain is less than a month old, all they can do is tell the people they are communicating with to report it as not spam. I'm willing to bet the bulk of their issues are with a receiving org that has a barracuda or something, and all their mail is going into an external quarantine. RELEASING that mail is the signal that needs to happen to fix this, and that's all on the receiver's side, there is nothing the sender can do.

 

[thecomputerguy]

You can double check the black lists, mxtoolbox.com for this. Double check SPF, DKIM, DMARC

But honestly... without the real domain to test I can't offer anything more specific. But if the domain is less than a month old, all they can do is tell the people they are communicating with to report it as not spam. I'm willing to bet the bulk of their issues are with a receiving org that has a barracuda or something, and all their mail is going into an external quarantine. RELEASING that mail is the signal that needs to happen to fix this, and that's all on the receiver's side, there is nothing the sender can do.

Based on the DKIM records above ... since the Domain (goodinsurance.com) was not the first added Domain into the tenant (badinsurance.com) goodinsurance.com is authenticating DKIM using the original domain as part of the DKIM record even though goodinsurance.com is set as the default domain in settings > domains

badinsurance.com is listed at spamhaus as a reputation score of -2


goodinsurance.com is listed as "no detections for goodinsurance.com"


The record goodinsurance.com is using for DKIM is:

goodinsurance.com
Host Name : selector1._domainkey
Points to address or value: selector1-goodinsurance-com._domainkey.badinsurance.p-v1.dkim.mail.microsoft

Maybe if I remove the original domain that is... basically unused then reset the DKIM record for goodinsurance.com it will then authenticate either with itself ... or the onmicrosoft.com DKIM record?

Then I can possible re-add badinsurance.com at a later date when the DKIM doesn't reference badinsurance.com at all?

 

[thecomputerguy]

Maybe none of that matters since it's probably not actually referencing badinsurance.com - It's referencing badinsurance (The name of the tenant).

 

[Sky-Knight]

@thecomputerguy The DNS records reference the CNAME for the source tenant. DKIM is digital signatures on each email. What you're doing is allowing the receiver to access a public key, to decrypt the signature. The name on the DNS record is irrelevant, all that matters is the public key in the DNS record can decrypt the signature on the email.

If you want to validate this, head into the Defender Admin panel, and check the policies for DKIM and make sure all domains are authoritative there, and if you'd like you can disable it, and re-enable it. That process will check the DNS before it comes back on, and provide you the correct DNS records. Which are by design based on the onmicrosoft.com domain.

 

[thecomputerguy]

@thecomputerguy The DNS records reference the CNAME for the source tenant. DKIM is digital signatures on each email. What you're doing is allowing the receiver to access a public key, to decrypt the signature. The name on the DNS record is irrelevant, all that matters is the public key in the DNS record can decrypt the signature on the email.

If you want to validate this, head into the Defender Admin panel, and check the policies for DKIM and make sure all domains are authoritative there, and if you'd like you can disable it, and re-enable it. That process will check the DNS before it comes back on, and provide you the correct DNS records. Which are by design based on the onmicrosoft.com domain.

Interestlingy...

Both complaints about deliver ability are coming from domains whose mx records both reference ppehosted or ... Proofpoint...

Coincidence... I think not

Just let it ride?

 

[YeOldeStonecat]

Poop-point..ah...client may have been with stop-daddy..err..godaddy? With their advanced security plan? (although, poop-point is far from advanced..just a pain)

 

[Sky-Knight]

Interestlingy...

Both complaints about deliver ability are coming from domains whose mx records both reference ppehosted or ... Proofpoint...

Coincidence... I think not

Just let it ride?

WINNER WINNER CHICKEN DINNER!

Only way this gets sorted is the people in question open tickets with Proofpoint and tell them to knock that crap off. Unless you're a Proofpoint customer, you don't get to file those requests.