Deliverability

Deliverability is the sum of every choice a receiving server sees: DNS
records, authentication, address hygiene, and message quality. relay manages
the infrastructure of all four. You focus on content and your recipient list.
This page explains what relay does and why each piece matters for the
receiver’s decision.

The record set relay manages

relay runs its own authoritative nameserver. For a delegated domain, for
example acme.com, you deploy the delegation and add DMARC, and relay serves
the rest. The dashboard lists the exact records, and its checks confirm each
one:

Four public-key selectors, two per domain (RSA-2048 and Ed25519),
sign every message with h=sha256. Both algorithms ride on every
outgoing message, so receivers that cannot read Ed25519 names yet still
find an RSA signature they accept.

Your message carries one more identity besides your domain keys. relay
cosigns customers’ messages with the keys of the platform domain. The cosign
carries the platform domain’s name, so a receiver can tell the platform
apart from your domain. Your domain signatures and the cosign cover the same
headers: From, To, Subject, Date, Message-ID, and Feedback-ID.

relay sets that header for you from the sending domain, your organization,
the mail type, and the platform’s own identifier last. Gmail groups its
complaint rates by those identifiers. It reports an identifier only when that
identifier appears in enough mail, so every message of a stream carries the
same four values. The format is on the
Feedback-ID
page. The complaint path is on the
Sender
reputation page.

A working sender domain from signup

Every organization gets a managed sender domain at {org}.open.{platform},
pre-verified and DKIM-signed, with all records served by the internal
nameserver. Your first message needs no DNS configuration. You can delegate
your own domains in parallel whenever you want your own domain in the
equation above.

The delivery pipeline, step by step

sequenceDiagram
    participant App as Your application
    participant MSA as relay SMTP (587/465)
    participant Worker as relay worker
    participant Scan as Scanner
    participant Sign as DKIM signer
    participant Remote as Recipient MX

    App->>MSA: STARTTLS, AUTH, message
    MSA->>MSA: sender-domain, suppression, billing checks
    MSA-->>App: 250 OK enqueued
    MSA->>Worker: enqueue spam scan for the stored message
    Worker->>Scan: scan the stored message
    Scan-->>Worker: score and action
    alt score reaches the hold threshold
        Worker->>Worker: status held, stop
    else clean
        Worker->>Sign: sign with RSA-2048, Ed25519
        Sign-->>Worker: signed message
        Worker->>Remote: STARTTLS on 25, per-MX attempts
        Remote-->>Worker: SMTP response, recorded in the dashboard
    end

Each step has a user-visible consequence in the dashboard, listed in the next
sections.

Address hygiene: the suppression list

Every message gets a fresh Return-Path of the form
bounce+{token}@{sender-subdomain} with a short signed token that names one
message, and only relay can mint the address a bounce report must carry. When
a recipient server rejects a message permanently, relay records
the bounce, marks the message as bounced, and adds the address to your
suppression list. The rejection does not have to happen during the SMTP
conversation. A recipient server can also accept the message first and fail
it later, for example on a full mailbox or on its own content filter. Its
bounce report comes back to the per-message bounce address, and relay marks
the message bounced and suppresses the address the same way. relay then
refuses further sends to that address. The submission still succeeds, and
relay stores the message as suppressed, so your application sees no error
and no retry loop.

You can add entries manually, for example before a large import.
If the address returns, remove the entry. Clearing the whole list is a
separate action, and it warns first: every address that bounced starts
receiving mail again, and those bounces count against your sender
reputation. Addresses store as salted SHA-256 hashes
only. See Data
privacy for what that means.

Content quality: the outbound spam gate

Before delivery, relay scores each outgoing message and scans it for
malware. A message whose score reaches the hold threshold, or that the scan
rejects, stays HELD and does not reach the recipient. If the scanner cannot
run, the message stays pending instead of being held. You see the score,
the spam action, the malware verdict, and the message content in the
dashboard, so you can fix the template, not fight the queue. This gate
catches compromised credentials, broken templates, and spamtraps before
they hurt your domain.

When delivery fails

relay tries every MX host of the recipient domain in preference order and
records one transmission per attempt, with the host and the reason on each
row. The outcomes:

• 5xx answer. The remote server rejects the message permanently.
  relay marks the message as bounced and suppresses the address. The
  dashboard shows the exact SMTP answer.
• 4xx answer. The remote server is not accepting the message right now.
  relay records the answer for that host and tries the next one. When no
  host accepted the message, relay keeps it pending and retries the whole
  list on a backoff schedule: 2, 4, 8, 16 and 32 minutes between attempts,
  about an hour in total. The sixth failed attempt ends the message failed,
  and every host keeps its own answer from every attempt.
• Bounce report after acceptance. The remote accepted the message and
  failed it permanently later. relay marks the message as bounced and
  suppresses the address, and the dashboard shows the remote’s answer.
  A report that only announces a delay records a retry and changes no
  status.
• No MX records or a failed lookup. relay records why there was nothing
  to try, and separates a domain without MX records from a lookup that
  failed, for example a resolver timeout. Both are retried like a temporary
  answer, because a delegation or a resolver may recover.
• MTA-STS rejection. relay skips the host and records which policy
  pattern rejected it. A policy that blocks every host is final: relay
  cannot talk its way past a published policy.
• Transport or storage problems. relay records the failing host and the
  error, for example a connection timeout or a dropped connection, and
  retries the message. A fault inside relay, for example a storage error,
  is recorded and retried the same way.

A 250 acceptance from your submission is not a delivery confirmation. The
dashboard’s transmissions are the confirmation path.

What your application sees

TLS and reputation inputs, briefly

MTA-STS enforcement, TLS-RPT collection, and the SPF/DKIM/DMARC alignment
above exist because receivers grade those signals. The sender-reputation page
explains why they are also your reputation story. Read
Sender reputation.

Related pages

• Sending. The SMTP
  interface and all acceptance rules.
• Reliability. What
  happens on each failure path.