So I logged a support case with 3CX about this and was told it was expected behavior and I needed to submit a feature request... This was originally a request to support SIP OPTIONS for monitoring SIP server health, but actually just supporting SRV record lookups as per the SIP RFC would be a start. So here goes: 3CX does not support SRV records properly. From RFC3263: Session Initiation Protocol (SIP): Locating SIP Servers 4.3: For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP)... If a failure occurs, the client SHOULD create a new request, which is identical to the previous.... That request is sent to the next element in the list as specified by RFC 2782 [The next SRV record] Instead, 3CX does the following: It looks up the SRV record, attempts with the highest priority record, but if a failure occurs (or this server is down) 3CX fails the call. Subsequent calls will continue to use the non-working SIP Server from the SRV record randomly, even if there are other servers with lower priority (backups). This makes implementing redundant SBC's/SIP Servers a manual process of adding the trunk multiple times. We have (had) a planned rollout of hudreds of 3CX instances and the inability of 3CX to support DNS fail-over, a pretty essential part of the SIP protocol design, basically makes this a deal breaker. And a warning to anyone using SRV records for 3CX: If you have an SBC/SIP server failure, your calls WILL NOT work reliably outbound until this basic functionality is fixed.