Testing SMTP relay is mainly a security and policy validation task.
You are verifying that your server relays only for authorized senders and approved scopes.
Quick answer: what to test
You should test two paths:
- unauthenticated relay attempts (must be rejected)
- authenticated relay attempts (must follow allowed policy)
If unauthenticated cross-domain relay is accepted, your server behaves like an open relay.
What is SMTP relay?
SMTP relay is the forwarding step where one mail server passes a message toward another domain's destination.
Relay is required for normal cross-domain email delivery, but it must be policy-controlled.
Open relay test concept
An open relay is an SMTP server that accepts and forwards mail from unauthorized senders.
This is typically validated by attempting external-to-external relay without authentication.
Manual relay test flow
High-level session:
Expected secure behavior:
- relay attempt rejected with policy/auth response (
,,depending on server) - no queue acceptance for unauthorized path
Recommended tools for relay testing
1) SMTP CLI tools (swaks / smtp-cli)
These are better than raw telnet for repeatable tests with auth and TLS combinations.
2) OpenSSL for TLS relay-path validation
Use OpenSSL to ensure encrypted relay session behavior is correct where STARTTLS is required.
3) Staged CI assertions
Use automated tests to enforce relay policy across environments and prevent regressions.
Practical relay test scenarios
Scenario A: unauthenticated external relay
- should fail
- confirms open relay protections
Scenario B: authenticated sender to approved domain scope
- should pass if policy allows
- confirms valid submission path
Scenario C: authenticated sender to disallowed scope
- should fail with policy rejection
- confirms least-privilege relay boundaries
Common relay test failures and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Unauthenticated external relay accepted | Open relay misconfiguration | Restrict relay to authenticated/authorized senders |
| Authenticated relay denied unexpectedly | Wrong auth/TLS mode or policy mismatch | Verify |
| Production-only relay failures | Environment-specific policy or egress drift | Standardize config and add CI relay assertions |
Secure relay checklist
- Reject unauthenticated cross-domain relay attempts.
- Enforce SMTP AUTH and TLS before relay.
- Restrict relay by sender identity and policy scope.
- Log and alert on relay-denied spikes.
- Validate domain authentication posture (SPF, DKIM, DMARC).
Release workflow for relay changes
- Validate policy behavior in Email Sandbox.
- Add regression checks via Email integration testing.
- Capture rejects and bounces through Email Webhooks.
- Monitor sender outcomes with Email deliverability testing.
FAQ
Is relay always bad?
No. Relay is necessary for cross-domain delivery. Open relay is the problem.
Can AUTH alone prevent open relay?
It helps, but policy/ACL configuration still determines allowed relay scope.
Which error means relay was blocked?
Commonly /, and sometimes when auth is required first.