Outlook emails not deliverable to yahoo and aol

Please try the links provided to earlier in this thread to check your office365 configuration of SPF, DMARC, and DKIM. In that order. It's best to have all three but if you have spf and dmarc configured and the message weight is low, (no external links) the message should deliver. You can verify or test those records at mxtoolbox

Emails are not getting delivered from Microsoft 365 to AOL, Yahoo or Verizon. We are hosted by GoDaddy, problem began on 3/31/24 around 6:30pm ET

The solution has been posted if you read the thread, it will require some work on your end or the person who manages your email DNS entries. I posted the most detailed solution on 3-11-2024, should be around page 18 of this thread.

Once you've read that, see how far you can get and if you get stuck, you'll need to post your domain name for us to assist further.

Good luck.

-Brad

Hey Brad have you tried doing this before using your instructions? It seems to be severely over complicated with options not everyone will need. Also I disagree with your dmarc and dkim. Please check the portal and try it yourself.

The DMARC needs only this information to pass all compliance and requirements for AOL/YAHOO/Anyone else. Nothing else.

v=DMARC1; p=quarantine; rua=mailto:adminemail@domaindotcom

SPF is the most important part and you do not describe this. As mentioned I agree they should check mxtoolbox but they also have to know their spam filtering service, if any, scanner or bizhub IP, website, and any other outbound IP used to send email for any reason. mxtoolbox just shows you what is on public dns, it doesn't create spf for you.

The dkim is different with each domain. When the user logs into the portal you can use the web slider toggle DKIM off and on for the default domain and this will display what your DNS records should be. After you create these records, give it 15min or so to publish, then try to enable the primary or vanity domain and it will check dns to verify the cname records exist as required. The DKIM records required for the onmicrosoft dot com domain name are the exact same cname records required for any other domains under the tenant. They do not change by domain.

Also you can only test the active key. Therefore when it's enabled the first time you can only resolve DKIM selector 1 and if you "rotate keys" you will only be able to resolve DKIM selector 2. This is important to know when testing.

However DKIM is not a requirement for AOL and YAHOO. SPF and DMARC are. I suggest people focus there first with the basic requirements and add complexity only as needed.

Hey Brad have you tried doing this before using your instructions? ...

SPF is the most important part and you do not describe this.

...

Also you can only test the active key. Therefore when it's enabled the first time you can only resolve DKIM selector 1 and if you "rotate keys" you will only be able to resolve DKIM selector 2. This is important to know when testing.

...

However DKIM is not a requirement for AOL and YAHOO. SPF and DMARC are. I suggest people focus there first with the basic requirements and add complexity only as needed.

I followed my own instructions for about half of my tenants (maybe about about 12-15), the first half I just followed in my head.

If you read back in the thread, I did not include DKIM in it, but found later it was necessary for some tenants which is why I added it. (Either yahoo classified them as bulk mailers even tho they aren't, or possibly DKIM being enabled on the OnMicrosoft domain caused emails to be signed with that and then subsequently failing delivery) Three tenants where I did not setup DKIM when the issue first came up, had their emails being blocked about 3 weeks later. I thought bringing up cycling the keys added more complexity than was needed to resolve, so I intentionally left that out. I wondered to myself if yahoo looked at the volume of mail coming from Microsoft as a whole, rather than each domain, thus classifying everyone as a bulk sender.

SPF is always the first step and I do reference it in my post, I'll re-post my guide below in case you were looking at a different post. I don't reference adding other authorized senders to the SPF because the people coming here are not going have those added entries, and if they do, then they must know SPF well enough to have gotten them in there before. I state that they might have other data in there (if they have outgoing spam filters, or whatever) and that is fine as long as the "include" for Microsoft is present.

Yes, the instructions are complicated, but it is a complicated process and I tried to write them for average people with just a tiny bit of computer knowledge to be able to either follow, or find someone who can follow them for them.

If you'd like to write a comprehensive post that tells everyone what they need to do from start to finish, by all means, go ahead and do so and I'm HAPPY to reference it.

Here is a copy of my comprehensive instructions. LET ME KNOW WHERE I HAVE AN ERROR SO I CAN FIX THEM.

=====================================================================================

PRELIMINARY STEPS

You need access to your domain DNS records and your M365 security admin center.

Get familiar with the MX Toolbox “SuperTool”. Google search SPF lookup and click on the result for MX Toolbox, we will use this site to check your records as you enter them.

Most DNS entries will update within a minute or 2, but some DNS hosts might take longer (Network Solutions has been slow historically). If the DNS checks at MX Toolbox don’t update, give it up to 15-20 minutes or longer for Network Solutions.

-----SPF-----

The universal Microsoft 365 SPF record is –

v=spf1 include:spf.protection.outlook.com ~all

(under certain circumstances, you might have more info on that line, but minimally you must have the include:spf.protection.outlook.com ~all entry)

Check your SPF record by filling in your domain name at the SPF Lookup on the MX Toolbox site. Once there, put in your domain name and lookup your SPF record.

If you do not have any SPF record at all, log in to your DNS provider, create a TXT record, the name is either blank or @, the value is the one listed above, starting with v=. Save it, give it a few minutes and confirm the correct record now shows up in the MX Toolbox checker when you re-run the check.

If you already had an SPF record, but it is wrong, do NOT create another one, you are only allowed 1. You have to find the existing SPF record and edit it, and then confirm in the MX Toolbox checker.

-----DMARC-----

Once SPF is setup, we need to create the DMARC record. Use the MX Toolbox to check for an existing DMARC record…leave your domain name filled in and click on the drop down arrow next to “SPF Record Lookup” and select “DMARC Lookup” and click the button.

There are many options in creating a DMARC record, but the following one is generic enough that you should be able to use it. You’ll need to fill in the <email_address_for_reports> with a valid email address on your domain, without the <> brackets.

Back in your DNS records, create a new TXT record if you do not have a DMARC already.

The Name is _dmarc

The value/data is –

v=DMARC1; p=quarantine; rua=mailto:<email_address_for_reports>; pct=100; aspf=r; adkim=r

(again, fill in the email address on your domain that you want to use for the <email…> section. If you don’t want to use your email, you can easily create a shared mailbox, name it Postmaster, and give it an email address of postmaster@ and select your domain. I’m not going to get into details on how to setup a shared mailbox, it is pretty easy in the exchange admin center – mailboxes – Create shared mailbox button. NOTE: shared mailboxes do not require a license, so it doesn’t cost you anything to create it)

If you already have a dmarc record and MX toolbox says it is valid, you can skip this step for now, but if you still have issues once we are all done, you could try editing it and use my sample record rather than what’s in there.

After creating the record, use the MX Toolbox checker to make sure it is valid.

------DKIM – PART 1 – M365-----

Log into M365 admin center, and click on “show all” then go to the Security admin center. If you purchased M365 from a discount provider, you might need to login to admin.exchange.microsoft.com and then once logged in, open a new tab and type in security.microsoft.com and it should automatically log you into the security admin center.

In the Security Admin Center (Microsoft Defender), under Email & Collaboration, click on Policies and Rules. Then click on Threat Policies, then under Rules, click Email Authentication Settings. Click DKIM at the top, make note of your “onmicrosoft” domain name, we’ll need it later. It should say it is your “Default Signing Domain” and this is fine. Click on the onmicrosoft domain name and make sure DKIM is enabled, if not, go ahead and enable it. Once enabled, it will give you some DNS entries, but we don’t use those as those are for the onmicrosoft domain, which Microsoft handles.

Next, click on your own custom domain name. If it says “No DKIM keys…” click on “Create DKIM keys” and then it will give you a popup with the DNS entries that you need to create. Copy those DNS entries into a document or text file to make sure you have them, then you can close out of this screen without enabling DKIM for now. If you do not have a prompt to “Create DKIM Keys, and you only have a slide bar to enable them, go ahead and try to enable. You WILL get a “Client Error” box, and this dialog box will tell you the DNS entries we need. Copy all of this text into a document that we’ll reference later. It won’t let you save it, so you can just click ok and close out for now with it still disabled.

-----DKIM – PART 2 – DNS ENTRIES-----

Back in your DNS records, you will need to create 2 CNAME dns entries that were provided to you in the previous step that you should have copied into a document. The “Name” will be the same for everyone, the Value/Data will be different for everyone. The info comes from the DKIM or Client Error dialog box, and when you dig into it, it should be in the format shown below, substituting your own domain name and your OnMicrosoft domain name as needed. Don’t include the <>. Also if your domain is not a .com then the first part where it shows your_domain-com will be -org or -net or -whatever your domain ends in. The OnMicrosoft domain will always end in .com. Again, you won’t have to type this info in, you’ll just have to extract it from the text we copied from the popup in the security admin center.

1st record to create:

Record type: CNAME

Name: selector1._domainkey

Value/Data: (whatever was in the text that popped up, should look like below)

selector1-<your_custom_domain>-com._domainkey.<your_OnMicrosoft_domain>.com

2nd record to create:

Record type: CNAME

Name: selector2._domainkey

Value/Data: (whatever was in the 2nd record in the text that popped up, should look like below)

selector2-<your_custom_domain>-com._domainkey.<your_OnMicrosoft_domain>.com

NOTE: The -com in the selector1 and selector2 assumes your domian is a .com, if it is somethign else, fill in the appropriate value, ie: -net -org, etc.

(best if you are copying and pasting from the DKIM or “Client Error” popup, just make sure you don’t get any extra spaces)

Now, after you create those records, you go back where we were in the M365 Security Admin center and enable DKIM for your custom domain. NOTE: DNS records might take a few minutes, Network Solutions is especially slow, so after creating the DNS, give it a few minutes before you try to enable. If you keep getting errors after 15-20 minutes double check that the settings shown in the Pop up EXACTLY match what you created in DNS.

If you were able to successfully enable DKIM on your domain, give it 2-3 minutes, then we can check it back in MX Toolbox. Select DKIM from the orange drop down. However, for your domain name, we need to tell it the selector to use, so the value you look up will be like this –

yourdomain.com:selector1

At this point, your issues should be resolved. You can send a test message to a yahoo email address and it should go through. FYI – for my test emails I was seeing a 3-5 minute lag on them, but they always went through, so I’m calling that good.

-Brad

respectfully Brad,

When you write a novel no one reads it. We need to be concise as engineers. Not convoluted or bloviated. This thread is about email failing to yahoo and aol. Neither yahoo nor gmail require DKIM unless you are using your account inside of a third party mailer, and this was off topic for discussion here.

What is required, according to their public documentation is DMARC and SPF. Most everyone has SPF. I gave the DMARC in a single sentence. One sentence will cover everything you need and you can test it to verify and we can move on.

If you want to make a tutorial for something then start a new thread and offer guidance. You're adding a lot of things that no one needs or asked for to troubleshoot delivery problems to yahoo and aol. The onmicrososft.com DKIM matches any DKIM under the tenant. These are not separate keys. You only have one DKIM per exchange deployment. If you rotate the keys for one then you rotate for the other domains also. You can test this with dns. I do not recommend people fumble through things until they start working with a bunch of extra settings or switches they don't understand.

Understand the technology and deploy in the right manner or seek support that can assist you so you don't create more problems than you were asked to fix. Keep it basic. If more is needed they can ask. DKIM is not required for delivery to AOL or YAHOO and you wrote more than ten paragraphs with misleading DKIM information. Next time you setup a client, just make spf and dmarc as I posted and test it. If you configure those two records correctly it will pass every time. If you still have failures then you did not make those two records right. Yahoo only rejects mail for dkim if someone tried to set up DKIM but it's not configured properly. If it's not enabled on your domain then you can't fail sending to yahoo.