dns
3 TopicsClarifications on MTA-STS Policy with CNAME Records
TechCommunity and The_Exchange_Team, In the article "Introducing MTA-STS for Exchange Online," there's a statement: The_Exchange_Team wrote: We do not support CNAMEs when MTA-STS is used. If a domain uses a CNAME and follows the MTA-STS RFC, that domain will fail our MTA-STS checks, and will not receive emails from us. I have several technical questions regarding this: CNAME Reference: Is the "domain uses a CNAME" part specifically referring to MX servers using CNAME records, or the mta-sts and _mta-sts DNS records? CNAME Usage: Many MTA-ST hosting services utilize CNAME records for MTA-STS configurations. Additionally, it appears Microsoft uses CNAMEs for serving its MTA-STS policies. What's the rationale? Record Type Implications: Is there a functional difference, from a Microsoft implementation standpoint, if an mta-sts record is served via an A/AAAA record vs. a CNAME record? Looking for technical clarifications on these points.1.6KViews0likes2CommentsOutgoing mails get marked as spam
We are using Office365 and our whole mail communication is handled via Exchange. For months we are facing the problem of our outgoing mails being marked as spam. I can't exactly tell how much of an impact this has, but even just 1% of mails being affected could do harm in a business case. I'm not too familiar with DNS settings, but I just want to verify they are done correctly and maybe someone can help me with that. Incoming mails are being handled by Baracuda Mail Gateway. Microsoft 365 Admin is warning about invalid entries in the MX records... TXT: v=spf1 mx include:spf.protection.outlook.com a:DOMAIN.de -all MX: dXXXXX.a.ess.de.barracudanetworks.com MX: dXXXXX.b.ess.de.barracudanetworks.com Microsoft 365 Admin is suggesting: MX: DOMAIN-de.mail.protection.outlook.com Might this be related to our DNS settings being poorly adapted by our IT agency? Is there anything else that comes to your mind that could cause these problems?2.2KViews0likes2CommentsIssue with DnsConnectorDelivery
Background: We are currently migrating from Exchange 2016 to 2019 in a hybrid environment. We have 2 2016 servers both in our main datacenter, and 2 2019 servers, one in our main datacenter and one in our offsite datacenter. Backup datacenter has its own DCs that are replicas of our main datacenter's DCs. Exchange 2019 has been installed and updated to CU 11. Problem: When I run the hybrid configuration wizard and select all 4 servers to be included in the send and receive connectors, everything completes and no errors appear. However, mail gets stuck in the DnsConnectorDelivery queue on the server in our backup datacenter. The NextHopDomain for the stuck mail is our M365 domain, domain.mail.onmicrosoft.com As soon as I remove the server in the backup site from the send and receive connectors, mail flows correctly again. I've done a lot of internet searching and it seems the issue has something to do with our MX record, but both domains have the correct record in their DNS. What could be causing the issue? Any help is appreciated!2.8KViews0likes0Comments