Domain Setup

Verifying a domain proves you own it and lets Sendry send authenticated emails on your behalf. This improves deliverability and prevents your emails from being flagged as spam.

Required DNS records

Sendry requires three DNS records:

Record	Purpose
SPF	Authorizes Sendry's mail servers to send for your domain
DKIM	Signs outgoing emails to prevent spoofing
DMARC	Defines policy for handling unauthenticated mail

Step 1: Add your domain

Via the API:

const domain = await sendry.domains.create({ name: "acme.com" });

Or in the dashboard under Domains → Add Domain.

Sendry returns the exact DNS record values to add.

Step 2: Add DNS records

Log in to your DNS provider and add the three records. The exact steps vary by provider:

Cloudflare

1. Go to your domain → DNS → Records
2. Click Add record for each of the three records
3. For SPF and DMARC, set type to TXT
4. For DKIM, set type to TXT
5. Set Proxy status to DNS only (orange cloud off) for all three

AWS Route 53

1. Open the hosted zone for your domain
2. Click Create record for each record
3. For simple routing policy, paste the value directly

Namecheap

1. Go to Domain List → Manage → Advanced DNS
2. Under Host Records, click Add New Record
3. Select record type, enter host and value

GoDaddy

1. Go to DNS Management for your domain
2. Click Add and select the record type
3. Enter the host (without the domain suffix) and value

SPF record

Type:  TXT
Host:  @  (or your root domain)
Value: v=spf1 include:spf.sendry.online ~all

If you already have an SPF record, add include:spf.sendry.online to it:

v=spf1 include:spf.sendry.online include:other-provider.com ~all

Do not create two separate SPF TXT records — only one SPF record is allowed per domain.

DKIM record

Type:  TXT
Host:  sendry._domainkey  (i.e., sendry._domainkey.acme.com)
Value: v=DKIM1; k=rsa; p=<public key from Sendry>

The public key value is unique to your domain and provided by Sendry when you add the domain.

DMARC record

Type:  TXT
Host:  _dmarc  (i.e., _dmarc.acme.com)
Value: v=DMARC1; p=none; rua=mailto:dmarc@acme.com

Start with p=none (monitor mode) before enforcing. Upgrade to p=quarantine or p=reject once you've confirmed no legitimate emails are failing.

Step 3: Verify

After adding all three records, trigger verification:

const result = await sendry.domains.verify("dom_abc123");
console.log(result.status);         // "verified" or "pending"
console.log(result.spf_verified);   // true
console.log(result.dkim_verified);  // true
console.log(result.dmarc_verified); // true

Or click Verify in the dashboard.

DNS propagation

Changes typically propagate within 2–10 minutes but can take up to 48 hours. If verification fails, wait a few minutes and try again.

Check propagation with:

# SPF
dig TXT acme.com | grep spf

# DKIM
dig TXT sendry._domainkey.acme.com

# DMARC
dig TXT _dmarc.acme.com

BIMI (Brand logo in inbox)

BIMI displays your company logo in supporting email clients (Gmail, Apple Mail, Yahoo). Available on Pro and higher plans.

Requirements:

1. DMARC policy must be p=quarantine or p=reject (not p=none)
2. A verified BIMI record with an SVG logo URL
3. A VMC certificate (for Google — optional but recommended)

Type:  TXT
Host:  default._bimi
Value: v=BIMI1; l=https://acme.com/logo.svg; a=https://acme.com/vmc.pem

Transport security (MTA-STS and TLS-RPT)

SPF, DKIM and DMARC prove who sent a message. MTA-STS and TLS-RPT are about how mail reaches you: they tell other mail servers to require TLS when they connect to your domain, and give you a report when TLS fails. Mailbox providers increasingly read both as part of a sender's posture.

Both are optional. A domain never becomes unverified because they are missing, and sending keeps working without them. Sendry checks them on every DNS check and shows the result under Transport security on the domain detail page.

Record	Purpose
MTA-STS	Tells senders which MX hosts may receive your mail and that they must use validated TLS
TLS-RPT	Tells senders where to post daily reports about TLS and MTA-STS failures

MTA-STS

MTA-STS has two halves, and it only works when both are in place.

1. A TXT record at _mta-sts.acme.com:

Type:  TXT
Host:  _mta-sts  (i.e., _mta-sts.acme.com)
Value: v=STSv1; id=9f2c1a4b7d3e5061;

The id is an opaque version marker. Senders cache your policy and only refetch it when the id changes, so change the id every time you edit the policy file. Sendry derives the recommended id from the policy contents, so copying the pair we show you keeps the two in step.

2. A policy file served over HTTPS. This is the part people miss: MTA-STS is not DNS alone. You must host a plain-text file at exactly:

https://mta-sts.acme.com/.well-known/mta-sts.txt

with contents like:

version: STSv1
mode: testing
mx: inbound-smtp.us-east-1.amazonaws.com
max_age: 604800

Requirements for the policy host:

• The certificate must be valid for mta-sts.acme.com. A self-signed or mismatched certificate makes senders ignore the policy.
• The URL must return the file directly. Redirects are not followed.
• The mx lines must cover every host that receives mail for the domain. List each MX host you publish; a single leading *. wildcard covering one label is allowed, for example *.acme.com.

Sendry shows the exact record and policy body for your domain, including the MX hosts it found in your DNS, on the domain detail page.

Start in testing, not enforce

mode takes three values:

Mode	What senders do
none	Ignore MTA-STS for this domain. Use this to retire a policy.
testing	Attempt validated TLS, deliver anyway on failure, and report the failure through TLS-RPT.
enforce	Refuse to deliver when TLS validation against your policy fails.

Always publish testing first. An enforce policy that omits one of your MX hosts, or that points at a host with an expired certificate, silently blackholes inbound mail. Run testing for a few weeks, read the TLS-RPT reports, and switch to enforce only once they come back clean.

Raising max_age also raises the cost of a mistake: senders keep a cached policy for that long. Keep max_age low (a day) while testing, then raise it to a week or more once you enforce.

TLS-RPT

TLS-RPT is a single TXT record, and it is what makes testing mode useful:

Type:  TXT
Host:  _smtp._tls  (i.e., _smtp._tls.acme.com)
Value: v=TLSRPTv1; rua=mailto:tls-reports@acme.com

rua accepts one or more comma-separated targets, each either a mailto: address or an https: endpoint. Point it at a mailbox you actually read. If you have Sendry inbound enabled, we recommend your Sendry inbound address so reports land in the dashboard instead.

Verifying

Both are refreshed by the same call as the rest of your DNS:

const result = await sendry.domains.verify("dom_abc123");
console.log(result.mta_sts_verified);  // true once record + policy agree
console.log(result.tls_rpt_verified);  // true once the TXT record is published
console.log(result.status);            // unchanged by either of the above

Check them by hand with:

# MTA-STS record
dig TXT _mta-sts.acme.com +short

# MTA-STS policy file
curl -sS https://mta-sts.acme.com/.well-known/mta-sts.txt

# TLS-RPT record
dig TXT _smtp._tls.acme.com +short

Subdomain sending

You can send from subdomains of a verified domain. Add and verify mail.acme.com as a separate domain — it gets its own DNS records.

Sending domain vs. root domain

You can verify acme.com for sending without affecting your website's DNS (MX records, etc.) as long as you don't change existing records.