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. A mailbox
provider copies Feedback-ID into spam complaints, so the complaint points
back at one message. 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+{message-id}@{sender-subdomain}, so every bounce points at one
message. 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. 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 or the recipient
  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 every
  host answers with a temporary failure, the message ends failed, and each
  host keeps its own answer.
• 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.
• MTA-STS rejection. relay skips the host and records which policy
  pattern rejected it.
• Transport problems. relay records the failing host and the error, for
  example a connection timeout or a dropped connection.

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.