Dela via

How SMTP DNS-based Authentication of Named Entities (DANE) works

  • Artikel

The SMTP protocol is the main protocol used to transfer messages between mail servers and is, by default, not secure. The Transport Layer Security (TLS) protocol was introduced years ago to support encrypted transmission of messages over SMTP. It’s commonly used opportunistically rather than as a requirement, leaving much email traffic in clear text, vulnerable to interception by nefarious actors. Furthermore, SMTP determines the IP addresses of destination servers through the public DNS infrastructure, which is susceptible to spoofing and Man-in-the-Middle (MITM) attacks. This vulnerability has led to many new standards being created to increase security for sending and receiving email, one of those standards being DNS-based Authentication of Named Entities (DANE).

DANE for SMTP RFC 7672 uses the presence of a Transport Layer Security Authentication (TLSA) record in a domain's DNS record set to signal a domain and its mail servers support DANE. If there's no TLSA record present, DNS resolution for mail flow works as usual without any DANE checks being attempted. The TLSA record securely signals TLS support and publishes the DANE policy for the domain. So, sending mail servers can successfully authenticate legitimate receiving mail servers using SMTP DANE. This authentication makes it resistant to downgrade and MITM attacks. DANE has direct dependencies on DNSSEC, which works by digitally signing records for DNS lookups using public key cryptography. DNSSEC checks occur on recursive DNS resolvers, the DNS servers that make DNS queries for clients. DNSSEC ensures that DNS records aren't tampered with and are authentic.

Once the MX, A/AAAA and DNSSEC-related resource records for a domain are returned to the DNS recursive resolver as DNSSEC authentic, the sending mail server asks for the TLSA record corresponding to the MX host entry or entries. If the TLSA record is present and proven authentic using another DNSSEC check, the DNS recursive resolver returns the TLSA record to the sending mail server.

After the authentic TLSA record is received, the sending mail server establishes an SMTP connection to the MX host associated with the authentic TLSA record. The sending mail server tries to set up TLS and compare the server's TLS certificate with the data in the TLSA record to validate that the destination mail server connected to the sender is the legitimate receiving mail server. The message is transmitted (using TLS) if authentication succeeds. When authentication fails or if TLS isn't supported by the destination server, Exchange Online will retry the entire validation process beginning with a DNS query for the same destination domain again after 15 minutes, then 15 minutes after that, then every hour for the next 24 hours. If authentication continues to fail after 24 hours of retrying, the message will expire, and an NDR with error details will be generated and sent to the sender.

What are the components of DANE?

TLSA Resource Record

The TLS Authentication (TLSA) record is used to associate a server's X.509 certificate or public key value with the domain name that contains the record. TLSA records can only be trusted if DNSSEC is enabled on your domain. If you're using a DNS provider to host your domain, the DNSSEC may be a setting offered when configuring a domain with them. To learn more about DNSSEC zone signing, visit this link: Overview of DNSSEC | Microsoft Docs.

Example TLSA record:

Screenshot that shows an example of a TLSA record.

There are four configurable fields unique to the TLSA record type:

Certificate Usage Field: Specifies how the sending email server should verify the destination email server's certificate.

Value Acronym Description
01 PKIX-TA Certificate used is the trust-anchor Public CA from the X.509 trust-chain.
11 PKIX-EE Certificate checked is the destination server; DNSSEC checks must verify its authenticity.
2 DANE-TA Use server's private key from the X.509 tree that must be validated by a trust anchor in the chain of trust. The TLSA record specifies the trust anchor to be used for validating the TLS certificates for the domain.
3 DANE-EE Only match against the destination server's certificate.

1 Exchange Online follows RFC implementation guidance that Certificate Usage Field values of 0 or 1 shouldn't be used when DANE is implemented with SMTP. When a TLSA record that has a Certificate Usage field value of 0 or 1 is returned to Exchange Online, Exchange Online treats it as not usable. If all TLSA records are found unusable, Exchange Online won't perform the DANE validation steps for 0 or 1 when sending the email. Instead, because of the presence of a TLSA record, Exchange Online enforces the use of TLS for sending the email, sending the email if the destination email server supports TLS or dropping the email and generating an NDR if the destination email server doesn't support TLS.

In the example TLSA record, the Certificate Usage Field is set to '3', so the Certificate Association Data ('abc123...xyz789') would be matched against the destination server's certificate only.

Selector field: Indicates which parts of the destination server's certificate should be checked.

Value Acronym Description
0 Cert Use full certificate.
1 SPKI (Subject Public Key Info) Use certificate's public key and the algorithm with which the public key is identified to use.

In the example TLSA record, the Selector Field is set to '1' so the Certificate Association Data would be matched using the destination server certificate's public key and the algorithm with which the public key is identified to use.

Matching Type Field: Indicates the format the certificate is represented in the TLSA record.

Value Acronym Description
0 Full The data in the TSLA record is the full certificate or SPKI.
1 SHA-256 The data in the TSLA record is an SHA-256 hash of either the certificate or the SPKI.
2 SHA-512 The data in the TSLA record is an SHA-512 hash of either the certificate or the SPKI.

In the example TLSA record, the Matching Type Field is set to '1' so the Certificate Association Data is an SHA-256 hash of the Subject Public Key Info from the destination server certificate.

Certificate Association Data: Specifies the certificate data that is used for matching against the destination server certificate. This data depends on the Selector Field value and the Matching Type Value.

In the example TLSA record, the Certificate Association data is set to 'abc123..xyz789'. Since the Selector Field value in the example is set to '1', it would reference the destination server certificate's public key and the algorithm that's identified to be used with it. And since the Matching Type field value in the example is set to '1', it would reference the SHA-256 hash of the Subject Public Key Info from the destination server certificate.

Per RFC implementation guidance for SMTP DANE, a TLSA record composed of the Certificate Usage field set to 3, the Selector field set to 1, and the Matching Type field set to 1 is recommended.

Exchange Online Mail Flow with SMTP DANE

The mail flow process for Exchange Online with SMTP DANE, shown in the flow chart below, validates domain and resource record security through DNSSEC, TLS support on the destination mail server, and that the destination mail server's certificate matches what is expected based on its associated TLSA record.

There are only two scenarios where an SMTP DANE failure results in the email being blocked:

  • The destination domain signaled DNSSEC support but one or more records were returned as inauthentic.

  • All MX records for the destination domain have TLSA records and none of the destination server's certificates match what was expected per the TSLA record data, or a TLS connection isn't supported by the destination server.

    Screenshot that shows Exchange online mail flow with SMTP DANE.

Technology Additional Information
Mail Transfer Agent - Strict Transport Security (MTA-STS) helps thwart downgrade and Man-in-the-Middle attacks by providing a mechanism for setting domain policies that specify whether the destination email server supports TLS and what to do when TLS can't be negotiated, for example stop the transmission. More information about Exchange Online's upcoming support for inbound and outbound MTA-STS will be published later this year.

Exchange Online Transport News from Microsoft Ignite 2020 - Microsoft Tech Community

rfc8461 (ietf.org)
Sender Policy Framework (SPF) uses IP information to ensure that destination email systems trust messages sent from your custom domain. How Sender Policy Framework (SPF) prevents spoofing
DomainKeys Identified Mail (DKIM) uses X.509 certificate information to ensure that destination email systems trust messages sent outbound from your custom domain. How to use DKIM for email in your custom domain
Domain-based Message Authentication, Reporting, and Conformance (DMARC) works with Sender Policy Framework and DomainKeys Identified Mail to authenticate mail senders and ensure that destination email systems trust messages sent from your domain. Use DMARC to validate email, setup steps

Inbound SMTP DANE with DNSSEC

Prerequisites

Before you start, ensure you meet the following prerequisites:

  1. You must have added the domain as an 'Accepted Domain' and the domain status must be 'Healthy' in the Microsoft 365 Admin Center. The documentation assumes the domain’s MX record is set to priority 0 or 10 and that there is no "fallback" or secondary MX record. If you have a fallback MX record, you need to work closely with your Exchange Online Administrator to ensure changes are carried out correctly.
  2. To receive the full security benefits of the feature, ensure that you have enabled DNSSEC for your domain.
  3. You must have access to Exchange Online PowerShell and the permissions to run the cmdlets described in Exchange Online PowerShell
  4. If the domain you want to secure with Inbound SMTP DANE with DNSSEC is referenced in any smarthost configurations, or in any connectors, you need to switch the smarthost name to tenantname.mail.protection.outlook.com before following the steps.

Note

If you want to enable DNSSEC for a domain that uses a third-party gateway, you can do that by following steps 1 through 3, following the note at the end of step 3 on third-party gateways.

Warning

If you want to configure inbound SMTP DANE with DNSSEC for your 'Accepted Domain' contoso.com, and your business partners are using connectors to your contoso-com.mail.protection.outlook.com endpoint, you need to work with your partners so they update their connectors to reference either the tenantname.onmicrosoft.com endpoint or the tenantname.mail.protection.outlook.com endpoint, before you configure inbound SMTP DANE with DNSSEC. Otherwise your business partners’ connectors mail fail after you complete the enablement. After completing the enablement, your partners can use your new contoso-com.<random>.mx.microsoft endpoint to re-establish the original connector.

Set up inbound SMTP DANE with DNSSEC

Note

DNS record provisioning and updates can take some time to complete. DNS changes can take longer than expected to become visible due to multiple layers of caching.

To set up inbound SMTP DANE with DNSSEC, perform the following steps:

  1. Update the TTL of your existing MX record to the lowest TTL possible (but not lower than 30 seconds). Then, wait for the previous TTL to expire before proceeding. For example, if the TTL of your existing MX record was '3600 seconds' or '1 hour' before you changed it, you need to wait 1 hour before proceeding to step 2.

  2. Connect to Exchange Online PowerShell.

    Warning

    If you're using MTA-STS, you need to set your policy mode to "testing" and update the ID in the MTA-STS txt record. (You can use the current time in UTC as the new policy ID.) Then, wait for the "max_age" of the policy to expire before proceeding. For example, if the "max_age" of your existing STS policy was 3600 seconds or 1 hour before you changed it, you need to wait for "1 hour" before proceeding.

  3. For the domain that you want to enable SMTP DANE with DNSSEC for, you need to first enable DNSSEC on the domain by running the following command (replace "domain" with the name of your chosen domain, for example, contosotest.com):

    Enable-DnssecForVerifiedDomain -DomainName <DomainName>

    Note

    This command can take a few minutes to execute.

    Example output of successful execution

    Result DnssecMxValue ErrorData
    Success contosotest-com.o-v1.mx.microsoft

    The success response provides the MX value for the domain. This value is the name that the new MX record points to for the domain you're enabling with DNSSEC. For example, contosotest-com.o-v1.mx.microsoft.

  4. Take the "DnssecMxValue" value, navigate to the DNS registrar hosting the domain, add a new MX record using the value returned in step 3, set the TTL to the lowest possible value (but not lower than 30 seconds), and set the priority of the new MX record to 20.

    Note

    If you're using a third-party email gateway and want to use this value as the new Exchange Online target host to which the third-party email gateway will send your inbound mail, navigate to the third party’s admin portal, update the target smart host that the third party uses to send to Exchange Online, then validate that "mail flow working via the DNSSEC test (ensure that you select “DNSSEC Validation” during test input, not “DANE Validation [including DNSSEC])” in the Microsoft Remote Connectivity Analyzer: Test Input". If mail is flowing as expected, you DO NOT need to continue following the below steps. If you want to enable SMTP DANE for this domain, skip to step 7.

    Warning

    If you're using MTA-STS, ensure that the policy mode is set to "testing". Then, delete the current mx row containing the legacy MX record information and add the new FQDN to your MTA-STS policy file as a new mx row. Then, update the policy id in the policy and the MTA-STS TXT record (you can use the current time in UTC as the new policy id).

  5. Verify that the new MX is working via the Inbound SMTP Email test (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input) by expanding the Test Steps and verifying the Mail Exchanger ending in mx.microsoft was tested successfully. You may have to retry this test, depending on DNS caching.

    Example success output

    Screenshot that shows the example of an output that notifies a success of the process implemented.

  6. Change the priority of the legacy MX pointing to mail.protection.outlook.com from current priority to 30; change the priority of the MX record created in step 3 so that it's set to priority 0 (highest priority).

  7. Delete the legacy MX record ending with "mail.protection.outlook.com", "mail.eo.outlook.com", or "mail.protection.outlook.de". Then, update the TTL for the MX record ending in mx.microsoft to 3600 seconds. Optionally, you can confirm everything is working as expected using the DNSSEC test (ensure that you select “DNSSEC Validation” during test input, not “DANE Validation [including DNSSEC])” in the Remote Connectivity Analyzer. You may have to retry this test, depending on DNS caching and TTLs.

    Once TTLs on the legacy MX record have expired, a successful output would look like:

    Screenshot that shows the example of an output that notifies that domains have successfully passed the DNSSEC validation test.

  8. Run the following command [replace (DomainName) with the name of your chosen domain, for example, contosotest.com] if you want to enable SMTP DANE for that same domain once the DNSSEC enablement is complete:

    Enable-SmtpDaneInbound -DomainName <DomainName>
    Result ErrorData
    Success

  9. Verify that the TLSA record has been propagated (which can take 15-30 minutes) by using an online tool of your choice and the Microsoft Remote Connectivity Analyzer: Test Input.

    Once you have completed DNSSEC enablement and the SMTP DANE record (TLSA) has been provisioned by Exchange Online, a successful output is displayed as shown in the following screenshot:

    Screenshot that shows the example of an output that notifies that domains have successfully passed the Dane validation test.

    Exchange Online hosts multiple TLSA records to increase the reliability of a success of SMTP DANE validations. It's expected that some of the TLSA records may fail validation. As long as 1 TLSA record is passing validation, SMTP DANE is configured correctly and the email is secured with SMTP DANE.

    Warning

    If you're using MTA-STS, after validating that the policy is working and that the mail is flowing as expected, set the policy mode back to "enforce" and update the ID in the MTA-STS txt record. (You can use the current time in UTC as the new policy ID.)

Limitations

  1. Viral or self-service sign-up domains: Domains that were set up as "self service" aren't currently supported with Inbound SMTP DANE with DNSSEC.
  2. onmicrosoft.com domains: The ‘onmicrosoft.com’ domain for the tenant isn't currently supported with Inbound SMTP DANE with DNSSEC. We're investigating the support for Inbound SMTP DANE with DNSSEC for the onmicrosoft.com domains; however, the ETA is unknown.
  3. Third-party gateways: Customers using a third-party email gateway on the inbound path (that accepts mail for the tenant, does some processing, then relays it to Exchange Online) will only be able to use this feature to secure emails relayed from the third-party gateway to Exchange Online if the third-party gateway supports SMTP DANE with DNSSEC validation. Customers in this configuration would need to set up Inbound SMTP DANE with DNSSEC using Exchange PowerShell.
  4. Other third-party integration with mail flow: There are customers for third-party gateways on the outbound path, where the email is sent to the third party via a connector, the third party does some processing and then resubmits to Exchange Online, then Exchange Online finally sends the email. These customers may need to work with their third-party provider when enabling the feature so that there are no disruptions. The third-party relay needs to use a DNS lookup when submitting the email back to Exchange Online, and use the new MX record hostname -> contoso-com.(subdomain).mx.microsoft created during feature enablement. The third party SHOULD NOT use the old MX record hostname -> contoso-com.mail.protection.outlook.com as Exchange Online will delete the A record approximately within 2 days (48 hours) after the feature enablement once we reach GA.
  5. Fully Delegated domains: Domains that are hosted by Microsoft and use NS delegation so that Microsoft’s name servers are authoritative for the domain are supported with Inbound SMTP DANE with DNSSEC. We do intend to support Inbound SMTP DANE with DNSSEC for these domains; however, the ETA is unknown.

Debugging issues that come up while enabling Inbound SMTP DANE with DNSSEC

Issues with Enable/Disable-DnssecForVerifiedDomain and Enable/Disable-SmtpDane Inbound

  1. DomainNotFound

    Message (DNSSEC): ‘DNSSEC enabling/disabling failed due to domain contoso.com not existing in AAD.‘
    Messages (SMTP DANE):

    • ‘SMTP DANE enabling/disabling failed due to domain contoso.com not existing in AAD.’
    • ‘SMTP DANE enabling/disabling failed due to domain contoso.com not found in the list of accepted domains.’
      Cause: The provided domain wasn't found in the list of accepted domains.
      Action(s) To Take: Navigate to the Microsoft 365 Admin Center and ensure the domain has been verified with the tenant. If the domain is healthy in the Microsoft 365 Admin Center, navigate to the Exchange Admin Center and ensure the domain has been added as an "Accepted Domain".

    DNSSEC

    Result DnssecMxValue ErrorData
    Error ErrorCode: ‘DomainNotFound’ ErrorDetails ’DNSSEC enabling failed...

    SMTP DANE

    Result ErrorData
    Error ErrorCode: ‘DomainNotFound’ ErrorDetails ’SMTP DANE enabling...

  2. DnsSecOperationFailed

    Message (DNSSEC): ‘DNSSEC enabling/disabling failed due to AdditionalErrorDetails. Retry the operation at a later time.‘
    Messages (SMTP DANE): SMTP DANE enabling/disabling failed due to AdditionalErrorDetails. Retry the operation at a later time.
    Cause: An attempt to create the proper DNS zone and/or records failed.
    Action(s) To Take: Try rerunning the cmdlet.

    DNSSEC

    Result DnssecMxValue ErrorData
    Error ErrorCode: ‘DnssecOperationFailed’ ErrorDetails ’DNSSEC enabling failed...

    SMTP DANE

    Result ErrorData
    Error ErrorCode: ‘DnssecOperationFailed’ ErrorDetails ’SMTP DANE enabling ...

  3. PartitionNotFound

    Messages (SMTP DANE): ‘SMTP DANE enabling/disabling failed due to domain contoso.com not having a partition.’
    Cause: DNSSEC is not enabled for the domain.
    Action(s) To Take: Ensure that you use a DNSSEC-enabled domain.

    Result ErrorData
    Error ErrorCode: ‘PartitionNotFound’ ErrorDetails ’SMTP DANE enabling

  4. DomainNotSupported

    Message (DNSSEC): ‘The specified domain is an onmicrosoft domain: contoso-com.onmicrosoft.com.’
    Messages (SMTP DANE): ‘The specified domain is an onmicrosoft domain: contoso-com.onmicrosoft.com.’
    Cause: The domain is an initial or MOERA domain. Those are currently not supported.
    Action(s) To Take: Ensure that you use a domain that doesn't end with ‘onmicrosoft.com.'

    DNSSEC

    Result DnssecMxValue ErrorData
    Error ErrorCode: ‘DomainNotSupported’ ErrorDetails ’The specified domain ...

    SMTP DANE

    Result ErrorData
    Error ErrorCode: ‘DomainNotSupported’ ErrorDetails ’The specified domain ...
Issues with Get-DnssecStatusForVerifiedDomain

  1. Message: ‘EG001: Cannot retrieve DNSSEC feature status for domain [{domain}].’
    Cause: While validating the domain’s configuration in Exchange Online, we found that the domain hasn't been added to Exchange Online. If you think you’ve already added this domain to Exchange Online, retry running the cmdlet as this could be a transient issue.
    Action(s) To Take: Retry the cmdlet. If it continues to fail, navigate into the Microsoft 365 Admin Center and complete the setup process for this domain.

  2. Message: ‘EG002: Domain [{domain}] is not verified domain of the organization.’
    Cause: While validating the domain’s configuration in Exchange Online, we found that the domain has been added to Exchange Online but not verified.
    Action(s) To Take: Navigate into the Microsoft 365 Admin Center and complete the setup and verification process for this domain.

  3. Message: ‘DNS query error occurs while getting MX records for [{domain}] domain.’
    Cause: During DNS validation, we received a generic DNS failure when querying the domain.
    Action(s) To Take: Retry running the cmdlet. You may need to review your configuration for the domain you're trying to enable with SMTP DANE with DNSSEC.

  4. Message: ‘Domain [{domain}] not found.’
    Cause: During DNS validation, we received NXDOMAIN failure when querying the domain.
    Action(s) To Take: Retry running the cmdlet after verifying the MX record configuration for the domain. DNS propagation can take up to 48 hours for some DNS providers.

  5. Message: ‘ED003: Domain [{domain}] found. No authentic MX records found.’
    Cause: During DNSSEC validation, we weren't able to find an MX record that resolved to a DNSSEC-secured A record (the A record for the 'hostname' value of the MX record).
    Action(s) To Take: Retry running the cmdlet after verifying the MX record configuration for the domain. DNS propagation can take up to 48 hours for some DNS providers.

  6. Message: ‘EX002: Value of MX record did not match the expected one.’
    Cause: During MX validation, we didn't find an MX record that matches the expected one.
    Action(s) To Take: Review your MX records in your domain. Ensure that one MX record matches the expected record that is outputted after running Enable-DnssecForVerifiedDomain or Get-DnssecStatusForVerifiedDomain.

  7. Message: ‘EX003: Priority of MX record did not match the expected one.’
    Cause: During MX validation, we found the expected MX record but its priority wasn't set to 0.
    Action(s) To Take: Set your MX record (containing the value returned when running Enable-DnssecForVerifiedDomainor Get-DnssecStatusForVerifiedDomain) to be priority 0.

  8. Message: ‘EX004: There is a different MX record with same preference as the expected one.’
    Cause: During MX validation, we found that the highest-priority MX record was not the expected MX record.
    Action(s) To Take: If you have already completed steps 1 through 4 of Set up inbound SMTP DANE with DNSSEC, complete steps 5 and 6 by switching the priorities of your MX records so that the expected MX is 0 (highest priority), validating the configuration, and then deleting the legacy MX record.

  9. Message: ‘EX005: There is a different MX record with lower preference than the expected one.’
    Cause: During MX validation, we found an MX record for the domain that doesn't match the expected MX record.
    Action(s) To Take: If you have already completed steps 1 through 5 of Set up inbound SMTP DANE with DNSSEC, complete step 6 by deleting the legacy MX record.

  10. Message: ‘EX006: There is a different MX record with higher preference than the expected one.’
    Cause: During MX validation, we found a different MX record with higher preference than the expected one.
    Action(s) To Take: Set your legacy MX record (ending in mail.protection.outlook.com, mail.eo.outlook.com, or mail.protection.outlook.de) to be priority 20.

  11. Message: ‘EX007: MX record was not found.’
    Cause: During MX validation, we didn't find an MX record that matches the expected one.
    Action(s) To Take: Review your MX records in your domain. Ensure that one MX record matches the expected record which is outputted after running Enable-DnssecForVerifiedDomain or Get-DnssecStatusForVerifiedDomain.

  12. Message: ‘EX008: The correct MX record found, but with lower preference than expected.’
    Cause: During MX validation, we found that the expected MX record has the wrong priority.
    Action(s) To Take: Set your MX record (containing the value returned when running Enable-DnssecForVerifiedDomain or Get-DnssecStatusForVerifiedDomain) to be priority 0.

  13. Message: ‘EX009: The correct MX record found, but with higher preference than expected.’
    Cause: During MX validation, we found that the expected MX record has the wrong priority.
    Action(s) To Take: Set your MX record (containing the value returned when running Enable-DnssecForVerifiedDomain or Get-DnssecStatusForVerifiedDomain) to be priority 0.

  14. Message: ‘EX010: Unknown error while searching MX records for domain [{domain}].’
    Cause: During MX validation, we experienced a generic DNS error.
    Action(s) To Take: Retry running the cmdlet after verifying the MX record configuration for the domain. DNS propagation can take up to 48 hours for some DNS providers.

  15. Message: ‘EX012: MX records not found for domain [{domain}].’
    Cause: During MX validation, we didn't find an MX record that matches the expected one.
    Action(s) To Take: Review your MX records in your domain. Ensure that one MX record matches the expected record which is outputted after running Enable-DnssecForVerifiedDomain or Get-DnssecStatusForVerifiedDomain.

  16. Message: ‘EX013: Unknown expected MX record for domain [{domain}].’
    Cause: During MX validation, we didn't find an MX record that matches the expected one.
    Action(s) To Take: Review your MX records in your domain. Ensure that one MX record matches the expected record which is outputted after running Enable-DnssecForVerifiedDomain or Get-DnssecStatusForVerifiedDomain.

  17. Message: ‘ES001: Expected MX record missing in policy while mode is ‘‘enforced’’.’
    Cause: During MTA-STS validation, we weren't able to find the mx value matching your expected record.
    Action(s) To Take: Set the mode of your MTA-STS policy to test; then, add the mxhostname value (returned when running Enable-DnssecForVerifiedDomain or Get-DnssecStatusForVerifiedDomain) as a row in the MTA-STS policy.

  18. Message: 'ES002: No expected MX record found to compare policy with. Enable DNSSEC feature for domain [{domain}] first.'
    Cause: MTA-STS was found but DNSSEC status of the domain was unretrievable.
    Action(s) To Take: Complete the steps in Set up inbound SMTP DANE with DNSSEC.

Mitigating mail flow issues with Inbound SMTP DANE with DNSSEC

There are 3 key scenarios for mail flow issues once Inbound SMTP DANE with DNSSEC has been enabled:

  1. Issue with SMTP DANE validations failing: For information on how to mitigate this issue, Mitigating SMTP DANE validations failing.
  2. Issue with DNSSEC validations failing: For information on how to mitigate this issue, see Mitigating DNSSEC validations failing.
  3. Issue with MX value: For information on how to mitigate this issue, see Mitigating issues with MX value.
Mitigating SMTP DANE validations failing

To mitigate impact from SMTP DANE validations, run the following command:

Disable-SmtpDaneInbound -DomainName <DomainName>
Mitigating DNSSEC validations failing

  1. To mitigate any impact from DNSSEC validations failing, you need to disable DNSSEC on your domain (contoso.com) through your DNS provider.

    Note

    If disablement of DNSSEC doesn’t resolve the issue, it may be a problem with your MX value.

  2. Once you have disabled DNSSEC on your domain through your DNS provider, open a support ticket with your DNS provider to determine how to safely re-enable DNSSEC for your domain.

Mitigating issues with MX value

  1. Ensure that your MX value matches the value in the Microsoft 365 Admin Center -> Settings -> Domains.

  2. Select the domain, select DNS records, then run Check health.

  3. Ensure that the MX record shows as OK; if it doesn’t, update the value to what is provided in the admin center.

  4. Navigate into your DNS registrar and find the MX record for your domain. The hostname value will be:

    <MX token>.<subdomain>.mx.microsoft

  5. Create a second MX record with the following hostname value and set the priority to 20:

    <MX token>.mail.protection.outlook.com

    Note

    Replace the "MX Token" value with the MX token from the current MX Record for your domain found in step 4. For example, the MX token for contosotest.com is contosotest-com.

  6. Ensure that the MX created in step 5 is working.

    Important

    One way to ensure the second MX record is working is to use the Microsoft Remote Connectivity Analyzer.

    1. Input the domain (for example, contoso.com) into the test; then select Perform Test.
    2. Open Test Steps.
    3. Open Test Steps for Testing inbound SMTP mail flow for domain “admin@(domain)”.
    4. Open Additional Details under Attempting to retrieve DNS MX records for domain ‘(domain)’.
    5. Confirm that the (MX token).mail.protection.outlook.com MX record is healthy.

  7. If mail flow is working with the MX token.mail.protection.outlook.com MX record, then run the following command:

    Disable-DnssecForVerifiedDomain -DomainName <DomainName>

  8. Delete the DNSSEC MX record that matches the values below:

    <MX token>.<subdomain>.mx.microsoft

  9. Ensure that the MX record you created in step 5 is the only MX record, and that it's set to priority 0 (highest priority).

How can Exchange Online customers use Outbound SMTP DANE with DNSSEC?

As an Exchange Online customer, there isn't anything you need to do to configure this enhanced email security for your outbound email. This enhanced email security is something we have built for you and it's ON by default for all Exchange Online customers and is used when the destination domain advertises support for DANE. To reap the benefits of sending email with DNSSEC and DANE checks, communicate to your business partners with whom you exchange email that they need to implement DNSSEC and DANE so they can receive email using these standards.

Troubleshooting sending emails with SMTP DANE

Currently, there are four error codes for DANE when sending emails with Exchange Online. Microsoft is actively updating this error code list. The errors will be visible in:

  1. The Exchange Admin Center portal through the Message Trace Details view.

  2. NDRs generated when a message isn't sent due to a DANE or DNSSEC failure.

  3. Remote Connectivity Analyzer tool Microsoft Remote Connectivity Analyzer.

    NDR Code Description
    4/5.7.321 starttls-not-supported: Destination mail server must support TLS to receive mail.
    4/5.7.322 certificate-expired: Destination mail server's certificate is expired.
    4/5.7.323 tlsa-invalid: The domain failed DANE validation.
    4/5.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records.

    Note

    Currently, when a domain signals that it supports DNSSEC but fails DNSSEC checks, Exchange Online does not generate the 4/5.7.324 dnssec-invalid error. It generates a generic DNS error:

    4/5.4.312 DNS query failed

    We are actively working to remedy this known limitation. If you receive this error statement, navigate to the Microsoft Remote Connectivity Analyzer and perform the DANE validation test against the domain that generated the 4/5.4.312 error. The results will show if it is a DNSSEC issue or a different DNS issue.

Troubleshooting 4/5.7.321 starttls-not-supported

This error usually indicates an issue with the destination mail server. After receiving the message:

  1. Check that the destination email address was entered correctly.
  2. Alert the destination email administrator that you received this error code so they can determine if the destination server is configured correctly to receive messages using TLS.
  3. Retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.

Troubleshooting 4/5.7.322 certificate-expired

A valid X.509 certificate that hasn't expired must be presented to the sending email server. X.509 certificates must be renewed after their expiration, commonly annually. After receiving the message:

  1. Alert the destination email administrator that you received this error code and provide the error code string.
  2. Allow time for the destination server certificate to be renewed and the TLSA record to be updated to reference the new certificate. Then, retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.

Troubleshooting 4/5.7.323 tlsa-invalid

This error code is related to a TLSA record misconfiguration and can only be generated after a DNSSEC-authentic TLSA record has been returned. There are many scenarios during the DANE validation that occur after the record has been returned that can result in the code being generated. Microsoft is actively working on the scenarios that are covered by this error code, so that each scenario has a specific code. Currently, one or more of these scenarios could cause the generation of the error code:

  1. The destination mail server's certificate doesn't match with what is expected per the authentic TLSA record.
  2. Authentic TLSA record is misconfigured.
  3. The destination domain is being attacked.
  4. Any other DANE failure.

After receiving the message:

  1. Alert the destination email administrator that you received this error code and provide them with the error code string.
  2. Allow time for the destination email admin to review their DANE configuration and email server certificate validity. Then, retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.

Troubleshooting 4/5.7.324 dnssec-invalid

This error code is generated when the destination domain indicated it was DNSSEC-authentic but Exchange Online wasn't able to verify it as DNSSEC-authentic.

After receiving the message:

  1. Alert the destination email administrator that you received this error code and provide them with the error code string.
  2. Allow time for the destination email admin to review their domain's DNSSEC configuration. Then, retry sending the email and review the Message Trace Details for the message in the Exchange Admin Center portal.

Troubleshooting receiving emails with SMTP DANE

Currently, there are two methods an admin of a receiving domain can use to validate and troubleshoot their DNSSEC and DANE configuration to receive email from Exchange Online using the following standards:

  1. Adopt SMTP TLS-RPT (Transport Layer Security Reporting) introduced in RFC8460
  2. Use the Remote Connectivity Analyzer tool Microsoft Remote Connectivity Analyzer

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 is a reporting mechanism for senders to provide details to destination domain administrators about DANE and MTA-STS successes and failures with those respective destination domains. To receive TLS-RPT reports, you only need to add a TXT record in your domain's DNS records that includes the email address or URI you would like the reports to be sent to. Exchange Online will send TLS-RPT reports in JSON format.

The following table's data is an example of a record:

Type Domain Name TTL Record
TXT _smtp._tls.microsoft.com 3600 v=TLSRPTv1;rua=https://tlsrpt.azurewebsites.net/report

The second method is to use the Remote Connectivity Analyzer Microsoft Remote Connectivity Analyzer, which can do the same DNSSEC and DANE checks against your DNS configuration that Exchange Online will do when sending email outside the service. This method is the most direct way of troubleshooting errors in your configuration to receive email from Exchange Online using these standards.

When errors are being troubleshooted, the below error codes may be generated:

NDR Code Description
4/5.7.321 starttls-not-supported: Destination mail server must support TLS to receive mail.
4/5.7.322 certificate-expired: Destination mail server's certificate has expired.
4/5.7.323 tlsa-invalid: The domain failed DANE validation.
4/5.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records.

Note

Currently, when a domain signals that it supports DNSSEC but fails DNSSEC checks, Exchange Online does not generate the 4/5.7.324 dnssec-invalid error. It generates a generic DNS error:

4/5.4.312 DNS query failed

We are actively working to remedy this known limitation. If you receive this error statement, navigate to the Microsoft Remote Connectivity Analyzer and perform the DANE validation test against the domain that generated the 4/5.4.312 error. The results will show if it is a DNSSEC issue or a different DNS issue.

Troubleshooting 4/5.7.321 starttls-not-supported

Note

These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.

This error usually indicates an issue with the destination mail server. The mail server that the Remote Connectivity Analyzer is testing connecting with. There are generally two scenarios that generate this code:

  1. The destination mail server doesn't support secure communication at all, and plain, non-encrypted communication must be used.
  2. The destination server is configured improperly and ignores the STARTTLS command.

After receiving the message:

  1. Check the email address.
  2. Locate the IP address that is associated with the error statement so you can identify the mail server the statement is associated with.
  3. Check your mail server's setting to make sure it's configured to listen for SMTP traffic (commonly ports 25 and 587).
  4. Wait a few minutes, then retry the test with the Remote Connectivity Analyzer tool.
  5. If it still fails, then try removing the TLSA record and run the test with the Remote Connectivity Analyzer tool again.
  6. If there are no failures, this message may indicate the mail server you're using to receive mail doesn't support STARTTLS and you may need to upgrade to one that does in order to use DANE.

Troubleshooting 4/5.7.322 certificate-expired

Note

These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.

A valid X.509 certificate that hasn't expired must be presented to the sending email server. X.509 certificates must be renewed after their expiration, commonly annually. After receiving the message:

  1. Check the IP that is associated with the error statement, so you can identify the mail server it's associated with. Locate the expired certificate on the email server you identified.
  2. Sign in to your certificate provider's website.
  3. Select the expired certificate and follow the instructions to renew and to pay for the renewal.
  4. After your provider has verified the purchase, you may download a new certificate.
  5. Install the renewed certificate into its associated mail server.
  6. Update the mail server's associated TLSA record with the new certificate's data.
  7. After waiting an appropriate amount of time, retry the test with the Remote Connectivity Analyzer tool.

Troubleshooting 4/5.7.323 tlsa-invalid

Note

These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.

This error code is related to a TLSA record misconfiguration and can only be generated after a DNSSEC-authentic TSLA record has been returned. But, there are many scenarios during the DANE validation that occur after the record has been returned that can result in the code being generated. Microsoft is actively working on the scenarios that are covered by this error code, so that each scenario has a specific code. Currently, one or more of these scenarios could cause the generation of the error code:

  1. Authentic TLSA record is misconfigured.
  2. The certificate isn't yet time valid/configured for a future time window.
  3. Destination domain is being attacked.
  4. Any other DANE failure.

After receiving the message:

  1. Check the IP that is associated with the error statement to identify the mail server it's associated with.
  2. Identify the TLSA record that is associated with the identified mail server.
  3. Verify the configuration of the TLSA record to ensure that it signals the sender to perform the preferred DANE checks and that the correct certificate data has been included in the TLSA record.
    1. If you have to make any updates to the record for discrepancies, then wait a few minutes then rerun the test with the Remote Connectivity Analyzer tool.
  4. Locate the certificate on the identified mail server.
  5. Check the time window for which the certificate is valid. If it's set to start validity at a future date, it needs to be renewed for the current date.
    1. Sign in to your certificate provider's website.
    2. Select the expired certificate and follow the instructions to renew and to pay for the renewal.
    3. After your provider has verified the purchase, you may download a new certificate.
    4. Install the renewed certificate into its associated mail server.

Troubleshooting 4/5.7.324 dnssec-invalid

Note

These steps are for email administrators troubleshooting receiving email from Exchange Online using SMTP DANE.

This error code is generated when the destination domain indicated it's DNSSEC-authentic but Exchange Online isn't able to verify it as DNSSEC-authentic. This section won't be comprehensive for troubleshooting DNSSEC issues and focuses on scenarios where domains previously passed DNSSEC authentication but not now.

Note

This error code is also generated if Exchange Online receives SERVFAIL response from DNS server on TLSA query for the destination domain.

After receiving the message:

  1. If you're using a DNS provider, for example GoDaddy, alert your DNS provider of the error so they can work on the troubleshooting and configuration change.
  2. If you're managing your own DNSSEC infrastructure, there are many DNSSEC misconfigurations that may generate this error message. Some common problems to check for if your zone was previously passing DNSSEC authentication:
    1. Broken trust chain, when the parent zone holds a set of DS records that point to something that doesn't exist in the child zone. Such pointers by DS records can result in the child zone being marked as bogus by validating resolvers.
      • Resolve by reviewing the child domains RRSIG key IDs and ensuring that they match with the key IDs in the DS records published in the parent zone.
    2. RRSIG resource record for the domain isn't time valid, it has either expired or its validity period hasn't begun.
      • Resolve by generating new signatures for the domain using valid timespans.

When an outbound email is being sent, if the receiving domain has DNSSEC enabled, we query for TLSA records associated with MX entries in the domain. If no TLSA record is published, the response to the TLSA lookup must be NOERROR (no records of requested type for this domain) or NXDOMAIN (there's no such domain). DNSSEC requires this response if no TLSA record is published; otherwise, Exchange Online interprets the lack of response as a SERVFAIL error. As per RFC 7672, a SERVFAIL response is untrustworthy; so, the destination domain fails DNSSEC validation. This email is then deferred with the following error:

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

If the email sender reports receipt of the message

If you're using a DNS provider, for example, GoDaddy, alert your DNS provider of the error so that they can troubleshoot the DNS response. If you're managing your own DNSSEC infrastructure, it could be an issue with the DNS server itself or with the network.

Frequently Asked Questions

As an Exchange Online customer, can I opt out of using DNSSEC and/or DANE?

We strongly believe DNSSEC and DANE will significantly increase the security position of our service and benefit all of our customers. We've worked diligently over the last year to reduce the risk and severity of the potential impact this deployment might have for Microsoft 365 customers. We'll be actively monitoring and tracking the deployment to ensure negative impact is minimized as it rolls out. Because of this, tenant-level exceptions or opt-out won't be available. If you experience any issues related to the enablement of DNSSEC and/or DANE, the different methods for investigating failures noted in this document will help you identify the source of the error. In most cases, the issue will be with the external destination party and you'll need to communicate to these business partners that they need to correctly configure DNSSEC and DANE in order to receive email from Exchange Online using these standards.

How does DNSSEC relate to DANE?

DNSSEC adds a layer of trust into DNS resolution by applying the public key infrastructure to ensure the records returned in response to a DNS query are authentic. DANE ensures that the receiving mail server is the legitimate and expected mail server for the authentic MX record.

What is the difference between MTA-STS and DANE for SMTP?

DANE and MTA-STS serve the same purpose, but DANE requires DNSSEC for DNS authentication while MTA-STS relies on certificate authorities.

Why isn't Opportunistic TLS sufficient?

Opportunistic TLS will encrypt communication between two endpoints if both agree to support it. However, even if TLS encrypts the transmission, a domain could be spoofed during DNS resolution such that it points to a malicious actor's endpoint instead of the real endpoint for the domain. This spoof is a gap in email security that is addressed by implementing MTA-STS and/or SMTP DANE with DNSSEC.

Why isn't DNSSEC sufficient?

DNSSEC isn't fully resistant to Man-in-the-Middle attacks and downgrade (from TLS to clear text) attacks for mail flow scenarios. The addition of MTA-STS and DANE along with DNSSEC provides a comprehensive security method to thwart both MITM and downgrade attacks.

Find and fix issues after adding your domain or DNS records

Overview of DNSSEC | Microsoft Docs

Use DMARC to validate email, setup steps - Office 365 | Microsoft Docs

How to use DKIM for email in your custom domain - Office 365 | Microsoft Docs

How Sender Policy Framework (SPF) prevents spoofing - Office 365 | Microsoft Docs

Exchange Online Transport News from Microsoft Ignite 2020 - Microsoft Tech Community

rfc8461 (ietf.org)