DocsTroubleshooting

Mail deferred or refused

What each RubySig SMTP response means, and which ones mean a message is waiting rather than lost.

Updated August 29, 2026

RubySig answers every message with a standard SMTP reply. Your platform shows it in its message trace (Microsoft: Mail flow → Message trace; Google: Reporting → Email Log Search). The reply text is written to be read.

Temporary — the message is waiting, not lost

A 451 reply tells your platform to retry. Microsoft and Google both queue the message and try again on a back-off schedule for up to a day or more. Nothing is bounced to the user unless the condition persists.

Reply Meaning What to do
451 4.3.2 RubySig is not yet configured to route mail for this domain Your organization is approved but onboarding is not finished — RubySig does not yet know where to hand your mail back. Nothing on your side; RubySig completes routing during onboarding and queued mail flows the moment it is set.
451 4.3.2 RubySig cannot reach its directory, try again shortly A transient fault between the relay and its directory. Wait; the retry succeeds. If it persists for more than an hour, contact support.
451 4.4.1 RubySig could not forward the message (…) RubySig accepted the message but your platform refused it on the return leg. The inbound connector (Microsoft) or SMTP relay rule (Google) is missing or does not list the relay's address, 167.233.237.1.

Permanent — the message is refused

A 550 reply is final for that message; your platform bounces it to the sender.

Reply Meaning What to do
550 5.7.1 RubySig does not relay for this domain The sender's domain is not one RubySig has been asked to serve. Your organization may not be approved yet, or mail is being sent from a domain not registered to it. Check the domains listed on the portal's Setup page. A refused domain also appears in RubySig's pending-connection queue, where it can be approved.
550 5.7.1 RubySig endpoint does not match the sender's tenant The connection arrived on a relay address that belongs to a different organization. The smart host on your outbound connector (or Google route) must be your <tenant>.smtp.rubysig.com, from your own Setup page.
550 5.3.0 RubySig could not forward the message (…) Your platform permanently refused the returned message. As for the 4.4.1 case above, but check the reason in the parentheses — it is your platform's own words.

Connector validation

The Microsoft 365 connector wizard's Validate step sends a test message with an empty sender address. RubySig accepts it and hands it back as an address in your domain so that Microsoft can attribute it to your tenant; the test arrives in the mailbox you named. If validation reports Send test email: Failed with one of the replies above, the table tells you why.

The relay is not responding at all

If your platform reports it cannot connect — rather than a reply — check the hostname on the outbound connector's Routing screen (or the Google route): it must be <tenant>.smtp.rubysig.com with nothing appended, and the TLS options must require a trusted certificate matching that name. The relay only accepts connections from Microsoft's and Google's mail infrastructure; it is not reachable from a workstation, so a failed telnet from your desk proves nothing.