Deliverability

• Built-in MTA (the default self-host provider): one DKIM TXT record plus a DMARC record. An SPF record is added only when the operator has configured the MTA_SPF_INCLUDE environment variable. No MAIL FROM record is generated — DKIM + DMARC alignment is fully functional without one.
• Amazon SES: an SPF TXT record, three DKIM CNAME records, a DMARC record, and a MAIL FROM pair (an MX record plus a TXT record). ::

Owned-MTA escape hatch with Amazon SES

An admin can enable the automatic SES escape hatch under Settings > Technical > Provider Routing. Owlat then provisions an SES identity for each verified owned-MTA domain and shows its publishable DNS plan and verification status on that page. Fallback stays off for a domain until both DNS and SES report it verified.

When an apex SPF row is displayed, publish it as the single reviewed merge of your existing policy and the owned-MTA authorization; adding it as a second v=spf1 record would break SPF. If no apex SPF row is shown, keep your reviewed manual primary SPF unchanged—Owlat marks that proof as not applicable to the SES relay because SES authenticates through its verified DKIM and dedicated ses-mail MAIL FROM records. Keep the domain's existing DMARC record too; Owlat does not ask you to publish a second policy.

Verification flow

1. Registering — your domain is being set up. DNS records are generated.
2. Pending — records are displayed. Add them to your DNS provider.
3. Click Verify — Owlat checks that your DNS records are in place and correctly configured.
4. Verified — all checks passed. You're ready to send.

Raising your DMARC policy

New domains start in monitor-only mode (p=none) so you can raise the policy gradually without risking legitimate mail. Once SPF and DKIM are aligned and verified, raise enforcement from the DMARC enforcement policy selector beneath the DMARC record in Settings > Technical > Sending Domains:

Changing the policy regenerates the _dmarc record shown above. Re-publish the updated record at your DNS provider and click Verify again so the new policy is confirmed. Only owners and admins can change the policy.

DKIM key rotation

Rotating your DKIM signing key periodically is good hygiene. When the domains.dkimRotation flag is on, Owlat flags keys that are due for rotation and, once an operator generates a new key, publishes the new public key as a DNS record for you to add. The new key only becomes active after its DNS record verifies, so there's no window where signatures break. On the built-in MTA, keys rotate on a safe overlap schedule (a new key is generated ahead of time and both keys remain valid during DNS propagation). You don't need to do anything beyond adding the new record when prompted.

Blocklist management

Owlat automatically blocks sends to email addresses that have caused problems — hard bounces, spam complaints, and other delivery failures. This protects your sender reputation.

How contacts get blocklisted

Contacts are automatically added to the blocklist when:

• An email bounces (hard bounce from the email provider)
• A recipient files a spam complaint

You can also manually add addresses to the blocklist from Settings > Technical > Email Blocklist.

How the blocklist affects sending

Blocked contacts are skipped during campaign sends — they won't receive any marketing emails. This happens automatically; you don't need to exclude them manually when selecting your audience.

Viewing the blocklist

Open Settings > Technical > Email Blocklist to see blocked addresses. For each entry you'll find:

• Email address — the blocked recipient
• Reason — why they were blocked (bounce, complaint, manual)
• Date — when they were added

Managing blocked addresses

In most cases, you should leave blocklist entries in place — they're there for a reason. However, if you know an address is valid and the block was a one-time issue (like a temporary mailbox-full bounce), you can remove the entry to allow re-sending.

Sending reputation

Owlat tracks your sending reputation automatically and surfaces it under Delivery health (/dashboard/admin/delivery). You don't configure anything here — it's a monitoring view that updates as you send.

The dashboard has three monitoring cards plus a best-practices card:

• Sending limits — your current warm-up phase, today's daily send cap, how much of it you've used, and the individual sending IPs the built-in MTA is warming. Warm-up phases are shown as Warming Up (capacity ramping), Paused, or Fully Warmed. The MTA raises your daily capacity automatically based on bounce and deferral signals; new IPs typically take around 30 days to fully warm. This card also surfaces your account health: if your bounce or complaint rates cross critical thresholds, your account status moves from clean to warned, suspended, or banned, and a banner explains the restriction.
• Account reputation — your rolling 30-day bounce rate, complaint rate, delivery rate, total sent, and an overall risk level. Targets are below 2% bounce and below 0.1% complaints.
• Domain reputation — the same bounce/complaint/risk breakdown per sending domain, joined with each domain's verification status, so you can spot which domain is dragging down delivery.
• How to Improve — best-practice tips for keeping your reputation healthy.

Current mailbox-provider requirements

These are receiver requirements, not Owlat product limits. They apply to mail sent to each provider's consumer service and can change independently of Owlat. The table was rechecked against official sources on July 26, 2026.

Sources: Google Email sender guidelines, Google sender FAQ, Yahoo Sender Requirements & Recommendations, Yahoo sender FAQ, Microsoft's current 550 5.7.515 guidance, and Microsoft's high-volume announcement.

Microsoft began rejecting non-compliant high-volume consumer mail with 550 5.7.515 on May 5, 2025. This requirement is specifically for Microsoft's consumer mailbox domains; do not generalize it to every Microsoft 365 tenant.

What 0.1% and 0.3% mean

The Delivery health page separates two related numbers:

• FBL spam rate is feedback-loop complaints divided by delivered volume over the rolling 30-day Owlat window. Keep it below 0.1% and prevent it from reaching 0.3%. Google calculates its Postmaster Tools rate daily, while Yahoo uses messages delivered to the inbox as its denominator. Owlat's internal FBL rate is an early operational signal, not a reproduction of either provider's private measurement.
• Owlat's circuit breaker remains deliberately stricter: it stops an organization at more than 0.2% after 100 sends (with an additional fast early-signal window). This is the “we stop you before Gmail stops you” safeguard, not Google's threshold.

Google's operational target is below 0.10%; it says to avoid ever reaching 0.30% or higher. Its mitigation FAQ uses greater than 0.3% for ineligibility and calls for seven consecutive days below that line to regain eligibility. The dashboard shows only how many completed, active sending days in Owlat's internal FBL data provide matching clean-day evidence; no-volume days do not claim evidence. This is an input to investigation, not a mitigation-eligibility verdict: verify Google's daily rate in Postmaster Tools and confirm every other sender requirement.

Gmail considers a sender that sends close to 5,000 messages to personal Gmail accounts in 24 hours from the same primary domain a bulk sender, permanently. Owlat uses the built-in MTA's MX-derived provider identity and the registrable sending domain to warn from 4,000 accepted messages. Google Workspace recipients are not personal Gmail accounts, but MX alone cannot distinguish a Workspace mailbox from a personal one; the indicator is intentionally conservative.

The dashboard returns the 100 highest-volume primary domains from its hourly materialized totals, refreshed asynchronously within about a minute of new delivery evidence. If more domains are active, it marks the list as truncated; the highest-volume warning remains accurate because the cap is applied after indexed volume ordering, not before aggregation.

Unsubscribe and preferences

Owlat includes built-in unsubscribe and preference management to keep you compliant:

• One-click unsubscribe — every marketing email includes an unsubscribe mechanism that meets CAN-SPAM and GDPR requirements
• Preference center — contacts can manage their per-topic subscription preferences, choosing which topics they want to remain subscribed to

Preference center

The preference center is a hosted page where contacts can manage their own subscriptions. It shows all topics the contact belongs to and lets them opt out of individual topics without unsubscribing from everything.

• Links to the preference center are automatically included in email footers
• Access is secured with HMAC-signed tokens — contacts can only view and modify their own preferences
• Available at the /preferences public endpoint

These work automatically for all marketing campaigns. You don't need to set anything up.

Campaign and marketing-automation envelopes are refused before provider dispatch unless they carry both RFC 8058 headers (List-Unsubscribe and List-Unsubscribe-Post) and the canonical DKIM signer contract covers both. The Delivery page also reports the actual one-click endpoint's 30-day p95 processing latency. Unsubscribe suppression is applied synchronously; Google and Yahoo expect requests honored within 48 hours.

Gmail has required one-click for bulk marketing and subscribed messages since 2024; Yahoo began enforcing its List-Unsubscribe rule in June 2024. As of the July 2026 recheck, Google's FAQ says missing one-click does not automatically cause rejection or spam placement by itself, but makes a bulk sender ineligible for delivery mitigation and increases complaint risk. Google's broader November 2025 compliance enforcement can include temporary and permanent failures for listed authentication, DNS, TLS, and formatting failures. Do not restate that general enforcement date as a header-specific guaranteed bounce.

Protocol details: RFC 8058.

Compliance essentials

Email laws vary by region, but the core principles are universal:

CAN-SPAM (United States)

• Include a valid physical mailing address
• Provide a clear unsubscribe mechanism (handled automatically by Owlat)
• Honor unsubscribe requests promptly
• Don't use misleading subject lines or sender information

GDPR (European Union)

• Obtain explicit consent before sending marketing emails
• Provide easy opt-out mechanisms
• Respect data subject access and deletion requests
• Document your consent collection process

General best practices

• Only send to people who have opted in
• Make it easy to unsubscribe
• Set clear expectations about what subscribers will receive
• Process unsubscribes and complaints quickly

Sending hygiene checklist

Good deliverability is an ongoing practice, not a one-time setup:

• Verify your domain before your first send
• Start small — warm up a new domain by sending smaller batches first and gradually increasing volume. The built-in MTA handles this for you and ramps your daily cap automatically; track progress under Sending reputation
• Keep bounce rates low — remove invalid addresses after they bounce
• Keep complaint rates below 0.1% — high complaints signal to email providers that your emails aren't wanted
• Clean your lists regularly — remove contacts who haven't engaged in 6+ months
• Use double opt-in on public signup forms to verify email ownership
• Monitor your metrics — watch for sudden changes in open rates, bounce rates, or complaint rates

Next steps

• Sending from a VPS — choose direct, relay, or hybrid delivery and prepare a new sending IP
• Campaigns & Reporting — monitor your campaign performance
• Topics — manage subscription and double opt-in
• Contacts — maintain a clean audience
• Forms — collect contacts with proper opt-in