Fix ERROR_DS_DRA_MAIL_PROBLEM (0x000020FF) in AD Replication

Cause #1: SMTP Replication Connector is Misconfigured or Missing

The culprit here is almost always the SMTP replication connector in Active Directory Sites and Services. This error pops up when a domain controller tries to replicate over SMTP instead of RPC, but the connector's mail settings point to a non-existent or unreachable mail server. I've seen it most often in multi-site environments where someone set up a site link bridge but forgot to configure the SMTP connector properly.

Here's the fix. Open Active Directory Sites and Services (dssite.msc). Expand your site, then Servers, then the DC that's failing. Right-click NTDS Settings and pick Properties. Under the General tab, you'll see a field for SMTP Mail Server. If it's blank or pointing to an old server, fix it. Use the FQDN of your internal SMTP relay (like an Exchange server or a dedicated SMTP gateway).

Example: smtp-relay.contoso.com

Then check the Site Link that connects the sites. Go to Inter-Site Transports > SMTP. Find the link causing the problem, right-click, Properties. Make sure the Cost isn't crazy high (over 1000 can cause issues) and that the transport is set to SMTP, not IP. Don't bother changing the Schedule unless you have a specific reason — it rarely helps here.

After you apply, force replication with repadmin /syncall /AeD. If the error clears, you're done with this cause.

Cause #2: Exchange or Mail Relay Is Not Accepting Connections from the DC

If the SMTP connector looks good, the next suspect is the mail relay itself. The DC needs to be able to talk to the mail server on port 25 (or whatever port you're using). I've seen this fail because a firewall rule was changed during a patching cycle, or the Exchange server's receive connector was locked down to only specific IPs.

Run a quick telnet test from the DC to the SMTP server:

telnet smtp-relay.contoso.com 25

If telnet fails or times out, you've got a network or firewall issue. Check Windows Firewall on both ends, and any physical firewalls between the DC and the mail server. On the Exchange side, open the Exchange Admin Center, go to Mail Flow > Receive Connectors. Find the connector that accepts from the DC's subnet. Make sure Anonymous users is allowed if you're using anonymous SMTP relay (common for AD replication). Set it like this:

PermissionGroups: AnonymousUsers, ExchangeServers

Also, verify the mail server is actually running the SMTP service. I've wasted hours on this — someone stopped the Simple Mail Transport Protocol (SMTP) service during maintenance and forgot to restart it. On an Exchange server, run Get-Service *SMTP* from PowerShell. You should see SMTPSVC and IIS Admin Service running.

Cause #3: Malformed Mail Attribute on the Site Link or Server Object

Less common, but when it happens it's a pain. The mail attribute on the site link or the server object in Active Directory can get corrupted during a schema update or a bad LDAP write from a third-party tool. The error message doesn't tell you which attribute is broken, so you'll need to dig.

Use ADSI Edit (or LDP.exe) to check the CN=NTDS Settings object on the failing DC. Look for the mail attribute. It should be a valid SMTP address (e.g., dc01-replication@contoso.com). If it's empty, has weird characters, or looks truncated, that's your problem. To fix it, right-click, Properties, delete the value, and set it correctly. You'll need Enterprise Admin rights. Then check the site link object under CN=Inter-Site Transports > CN=SMTP for the same attribute.

Another sneaky cause: someone renamed the site or server but didn't update the mail attribute manually. Use this PowerShell to scan for null or invalid mail attributes:

Get-ADObject -Filter 'mail -like "*" -and objectClass -eq "server"' -Properties mail | Select Name, mail

If you find blanks, set them with Set-ADObject. I've also seen distinguishedName mismatches if the server was moved between OUs in AD — the mail attribute might still reference the old path. In that case, just clear and re-set it.

Quick-Reference Summary Table

After any fix, run repadmin /replicate between the problem DCs. If the error still shows up, check the Event Viewer under Directory Service logs — you'll get a more detailed error ID (usually 1925 or 1126) that pinpoints the specific DC or site link. Don't restart the DC until you've tried these steps; 9 times out of 10 it's a config issue, not a service.