Skip to content
Skip to main content

Email deliverability for Agent Accounts

An Agent Account sends from a domain you own, so its inbox placement is yours to manage the same way it would be for any mail from your company. Deliverability comes down to proving the mail is really from you, sending at a pace mailbox providers trust, and watching the signals that show whether recipients want it. This page pulls those pieces together for Agent Accounts and links to the deeper references for each.

Deliverability checklist for Agent Accounts

Section titled “Deliverability checklist for Agent Accounts”

Five things determine whether an Agent Account reaches the inbox, and you can act on all of them before you send at volume. Work through them in order: authentication first, because nothing else matters if recipient servers can’t confirm the mail is yours, then volume and monitoring once mail is flowing. Each item links to the section or reference that covers it in full.

  1. Authenticate the domain with DKIM and SPF as part of domain verification.
  2. Set up DMARC so providers know how to treat mail that fails authentication.
  3. Warm up a new domain before sending at volume, following the warm-up schedule.
  4. Monitor bounces and complaints through the Agent Account deliverability webhooks.
  5. Stay under the bounce and complaint thresholds that pause sending, documented in Usage limits.

Authenticate your sending domain

Section titled “Authenticate your sending domain”

Authentication is the foundation, and for Agent Accounts it relies on the two records you already publish during domain setup: DKIM and SPF. DKIM adds a cryptographic signature that proves the message wasn’t altered and really came from your domain. SPF authorizes Nylas to send on your behalf. Both are verified before a custom domain can host accounts, so a verified Agent Account domain is already DKIM- and SPF-authenticated.

The records, and where to enter them at each DNS provider, are covered in Managing domains and Set up DNS records. Nylas also tracks DMARC and ARC, but it doesn’t enforce them, so DMARC is the one authentication layer you add yourself. See the next section for more details.

Set up DMARC

Section titled “Set up DMARC”

DMARC tells receiving servers what to do when a message claiming to be from your domain fails authentication, and it gives you reports on who is sending as you. It builds on DKIM and SPF: a message passes DMARC when either one passes and aligns with the domain in the visible From address. Because Agent Accounts sign with your domain’s DKIM key and send from your verified domain, alignment works out of the box once you publish a DMARC record.

Roll it out in three stages so you never block legitimate mail before you’ve confirmed everything authenticates. Add a single TXT record at the host _dmarc.yourdomain.com (use the same subdomain your accounts send from), then tighten the policy over a few weeks as the reports come in clean.

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100
  1. Monitor with p=none. Start here. Mail is delivered as normal, but providers send aggregate reports to your rua address so you can confirm your Agent Account mail (and any other sources) authenticate and align.
  2. Quarantine with p=quarantine. Once reports look clean, move failing mail to spam instead of the inbox. You can ease in with pct=25 to apply the policy to a quarter of failing mail, then raise it to 100.
  3. Reject with p=reject. The end state. Receiving servers refuse mail that fails DMARC outright, which gives your domain the strongest protection against spoofing.

Give each stage a couple of weeks of clean reports before tightening. The rua address collects the daily aggregate reports described below; point it at a mailbox or a DMARC monitoring service you check regularly.

If your rua address is on a different domain than the one you publish DMARC for, such as a DMARC monitoring service or a separate company domain, that other domain has to confirm it accepts your reports, or compliant receivers won’t send them and the reports silently never arrive. The reporting domain publishes a TXT record that authorizes yours, at <your-domain>._report._dmarc.<reporting-domain> with the value v=DMARC1;. For example, if yourdomain.com reports to [email protected], then monitoring.example adds:

yourdomain.com._report._dmarc.monitoring.example  IN  TXT  "v=DMARC1;"

Most monitoring services publish a wildcard (*._report._dmarc.<their-domain>) and handle this for you; add the record yourself only when the reporting address is on a domain you control. A rua on your own domain, like the example above, needs no extra record.

Warm up a new domain

Section titled “Warm up a new domain”

A brand-new domain has no sending reputation, so a sudden burst of mail looks like spam to mailbox providers and gets filtered. Warming up means raising volume gradually, over roughly four weeks, while real recipients open and reply. The reputation an Agent Account builds is tied to its domain, so warming matters most when you launch a new custom domain or split traffic across several.

The full ramp-up schedule, engagement guidance, and a daily send script are in the domain warm-up guide. If you provision one Agent Account per customer on separate domains, warm each domain on its own schedule, since reputation doesn’t transfer between them.

Monitor delivery with webhooks

Section titled “Monitor delivery with webhooks”

You can’t manage deliverability you can’t see, and for Agent Accounts the four deliverability webhooks are your real-time signal. Subscribe to message.delivered, message.bounced, message.complaint, and message.rejected to track exactly what happens to each outbound message, the same events Nylas uses to calculate your bounce and complaint rates.

Wire these into your own logic: pause or slow outbound when bounces or complaints climb, and stop mailing any address that hard-bounces or complaints. Catching a problem in your own telemetry is what keeps you under the thresholds that pause sending. Those thresholds, and what a pause looks like to your code, are in Usage limits.

Read your DMARC reports

Section titled “Read your DMARC reports”

DMARC aggregate reports are how you confirm authentication is working before you tighten the policy. After you publish a record with an rua address, participating providers send an XML report to that address about once per day, summarizing how much mail passed or failed SPF, DKIM, and alignment for your domain.

Read the reports before each policy change. You’re looking for two things: that mail from your Agent Account domain shows DKIM and SPF passing with alignment, and that you recognize every other sending source in the report. Unfamiliar sources passing as your domain are either forgotten services to fix or spoofers the policy will soon block. Raw XML is hard to scan, so most teams feed the rua reports into a DMARC monitoring tool that renders them as a dashboard.

Troubleshoot SPF and DKIM alignment

Section titled “Troubleshoot SPF and DKIM alignment”

When DMARC reports show failures for mail you sent, the cause is almost always alignment rather than a broken signature. DMARC offers two alignment modes per mechanism, set with the adkim and aspf tags: relaxed (the default, which matches the organizational domain) and strict (which requires an exact domain match). Relaxed alignment is the right default for most senders and is what Agent Accounts are set up for.

Two patterns cause most failures. Forwarding breaks SPF because the forwarding server’s address isn’t in your SPF record, but DKIM survives forwarding intact, which is exactly why DMARC accepts a pass from either mechanism. And mail sent from a different subdomain than your DMARC record covers can fail strict alignment, so keep the From domain consistent with the domain your Agent Accounts are verified on. For broader sender-reputation hygiene that applies to any mailbox, see Improving email deliverability.

What’s next

Section titled “What’s next”