Azure Communication Services Email: Reverse DNS (PTR) mismatch on outbound infra causing deliverability failures to strict mail servers

Question

Azure Communication Services Email: Reverse DNS (PTR) mismatch on outbound infra causing deliverability failures to strict mail servers

Joan 0

We are experiencing consistent email delivery failures from our Azure Communication Services Email custom domain to specific corporate mail servers (e.g. Arsys-hosted mailboxes), while delivery to major providers (Gmail) succeeds without issue.

Resource details:

Communication Service: CommServiceFiskAppCloud
Resource group: DefaultResourceGroup-CCAN
Email Communication Service: EmailServiceFiskAppCloud (resource group PGC)
Custom domain: mail.fiskappcloud.com
Sender: ******@mail.fiskappcloud.com

Domain authentication status (verified in Azure Portal, Provision Domains):

Domain status: Verified
SPF: Verified - v=spf1 include:spf.protection.outlook.com -all (matches Microsoft's official documentation for ACS custom domains)
DKIM: Verified
DMARC: Published (_dmarc.fiskappcloud.com, p=none)

Problem:

Despite SPF and DKIM passing, emails sent to several recipients hosted on Arsys (arsys.es) webmail and other corporate mail servers are not delivered, with no bounce received either (silent rejection/drop).

Diagnostic evidence (mail-tester.com, message sent from ******@mail.fiskappcloud.com via Try Email):

Overall score: 7/10
SPF: PASS, sending server 40.93.81.90 authorized for ******@mail.fiskappcloud.com
DKIM: valid signature
Reverse DNS (PTR) does not match the sending domain.
- No MX record found behind mail.fiskappcloud.com (expected, it is a send-only domain).
- The reverse DNS of the sending IP resolves to OSPPR02CU001.outbound.protection.outlook.com, which does not align with our custom domain.

This matches a pattern reported by other ACS Email customers (PTR record mismatch causing delivery failures to strict recipient mail servers), where the shared outbound IP's PTR record does not align with the tenant's custom sending domain, even though SPF/DKIM/DMARC are correctly configured.

Question:

Since the PTR record for the outbound IP/hostname is managed by Microsoft's shared ACS Email infrastructure and not something we can modify via our own DNS, is there any way to get this reverse DNS alignment fixed or mitigated? Our Azure subscription is on the Basic support plan, which does not include technical support tickets, so we are asking here first.

Happy to provide further diagnostic details on request.

0 comments

2 answers

Your answer

Answer 1

TP 163.1K Volunteer Moderator

Hi Joan,

I checked your email domain and confirmed it still doesn't have MX record--it needs to have one for best deliverability.

1. Please add MX record for mail.fiskappcloud.com

I don't know specifically how Arsys treats lack of MX record, but I do know in general it is considered potential spam signal.

ACS documentation recommends having MX record. I would go a step further and say it is best to not only have MX record, but that it points to valid email server that will receive messages for that domain and the MailFrom addresses (e.g. DoNotReply -at- mail.fiskappcloud.com, etc.) you have configured.

Have automation that processes any messages that comes in for Non Delivery Reports, manual unsubscribes, opt-outs, etc. This automation part isn't necessary for trying to solve your immediate issue.

After MX record is in place, please verify it resolves correctly using command similar to below:

nslookup -q=mx mail.fiskappcloud.com 8.8.8.8

2. Please consider changing your DMARC TXT record to p=reject or p=quarantine, instead of p=none. I suspect some subset of email servers/gateways prefer p=reject (this is what ACS managed domain is set to) or p=quarantine. Of course make sure the email address you put in your DMARC is real and receives messages.

After making above changes, please test again and reply back with your results, whether positive or negative.

Thanks.

-TP

Joan 0 Reputation points

2026-09-03T03:11:42.9966667+00:00

Hi TP, thanks for the detailed follow-up.

For context: since posting this question we've moved away from Azure Communication Services Email entirely for this domain. The root cause we identified (PTR/reverse-DNS mismatch on the shared ACS outbound infrastructure, with no dedicated-IP option available on our plan) turned out to be a structural limitation we couldn't work around from our side — confirmed by Microsoft's own documentation and by other reports of the same pattern.

We switched to sending directly via SMTP through our existing mail provider (with proper SPF/DKIM/DMARC alignment on our own sending domain), which resolved the delivery failures to strict recipient servers like Arsys.

Regarding your two suggestions (MX record for mail.fiskappcloud.com, and tightening DMARC to p=reject/p=quarantine): since we no longer send from that domain, they're not actionable for us right now, but they're useful, concrete pointers — I'll leave this thread open in case they help other ACS Email users hitting the same PTR-mismatch pattern.

Thanks again for taking the time to look into this!
TP 163.1K Reputation points Volunteer Moderator

2026-09-03T03:45:34.1933333+00:00

@Joan Thanks for the follow up. In regards to PTR mismatch, that is relatively common and in my experience is not a cause, by itself, for a message to fail to be delivered in most cases. This assumes other important aspects like SPF, DKIM, DMARC are in place, and sending IP isn't blacklisted and/or have poor/no reputation.

For example, messages sent by Microsoft 365 Business/Exchange Online (used by large percentage of businesses every day) are sent successfully in most cases even though PTR record doesn't match.

The posts here on Q & A that I have seen have been the author putting PTR mismatch forward as a potential theory as to why messages are not being delivered, without confirmation.

Answer 2

Hi ,

Thanks for reaching out to Microsoft Q&A.

Based on the information provided, your DNS configuration appears to be correctly set up:

SPF is verified and passing.
DKIM is verified and signing messages successfully.
DMARC is published.
A missing MX record is not an issue for a send-only domain.

Regarding the reported PTR (reverse DNS) mismatch, this is expected when using azure communication services email. The outbound IP addresses and their reverse DNS records are managed by Microsoft's shared sending infrastructure, and customers cannot modify the PTR records associated with those IPs.

A few points are worth noting:

SPF, DKIM, and DMARC alignment are the primary email authentication mechanisms. A PTR hostname matching the custom sending domain is not a requirement for standards-compliant mail delivery.

Mail-tester warnings about reverse DNS do not necessarily indicate a deliverability problem. Many Microsoft 365 and Azure-managed sending systems use shared outbound infrastructure where the PTR resolves to a Microsoft-managed hostname rather than the customer's domain.

The silent rejection by specific recipient systems may be related to local filtering policies, IP reputation checks, or reverse DNS validation rules enforced by those mail servers. Based on the information provided, it is difficult to conclude that the PTR mismatch alone is the root cause.

Because the outbound infrastructure is controlled by Microsoft, customers cannot directly change the outbound PTR records or select alternate outbound IP addresses for ACS Email.

For further investigation, it would be helpful to obtain:

SMTP rejection logs or NDRs (if available) from the recipient mail system.
Message IDs and timestamps for failed deliveries.
Email Delivery Reports from Azure Communication Services.

If the issue is ultimately determined to be related to the Microsoft managed sending infrastructure, investigation and any potential remediation would need to be performed by Microsoft, as the PTR configuration is not customer-managed.

Overall, based on the details provided, I do not see any obvious misconfiguration in your SPF, DKIM, DMARC, or custom domain setup. The next step would be to gather recipient-side rejection evidence and delivery diagnostics to identify the specific reason for the delivery failures.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Joan 0 Reputation points

2026-09-03T03:15:07.7866667+00:00

Thanks for the detailed clarification — that's a fair and important correction to the earlier suggestion. You're right that we never had direct SMTP rejection logs or NDRs from the recipient side (the failures were silent), so the PTR mismatch was always a plausible hypothesis based on the mail-tester pattern, not a confirmed root cause.

Since we've since moved this domain's sending off ACS Email entirely (direct SMTP through our own provider, with SPF/DKIM/DMARC aligned on our own domain), we're no longer in a position to reproduce the issue or gather the diagnostics you mentioned. I'll leave this thread open for other ACS Email users who hit the same silent-rejection pattern and can gather better evidence.

Thanks again for taking the time to look into this properly.