Domains

Domains lists every sending domain with its status (Pending / Verified / Failed / Disabled), DNS provider and transport. Verify a domain describes the wizard that adds a domain.

Domain page

The header shows the status pill, the provider (Cloudflare / Manual), the transport and region, and the last checked and last verified times. The actions depend on the role:

Action	Role	Effect
Verify now	Member+	Queues a verification; record pills update within seconds.
Publish to Cloudflare	Member+	Upserts every expected record in the zone (Cloudflare domains only).
Register with SES	Admin	Creates/updates the SES identity with the active DKIM key (BYODKIM) and bounce.<domain> as MAIL FROM.
Disable / Enable	Admin	Disabled domains cannot send; enabling sets Pending and verifies.
Enable MTA-STS/TLS-RPT	Admin	Adds the optional receiving-side records (publish them afterwards).
Set MTA-STS mode	Admin	testing or enforce; rewrites the _mta-sts TXT id and publishes it on Cloudflare domains.
Pause / Resume sending	Admin	Pauses this domain only: the API answers 403 sending_paused for it and its queued mail waits. Other domains keep sending. A domain-scoped bounce or complaint rule with the kill switch pauses the domain the same way.
Set policy (DMARC policy card)	Admin	Sets p= and pct=, rewrites the expected DMARC record, publishes it on Cloudflare, and verifies.
Stream (select + Save)	Admin	Sets what the domain may send: Transactional refuses bulk kinds (422 stream_mismatch), Bulk flags transactional kinds, Mixed allows both. See Streams.
Failover (select + Save)	Admin	Chooses a second delivery region for this domain. The worker uses it when the primary region pauses sending, when a provider hold lasts longer than two hours, or when the primary keeps failing. It returns to the primary on its own. Same DKIM key and MAIL FROM in both regions, so DMARC keeps passing. None turns failover off. The line under the select shows the last failover and its reason. Failover stays off until the identity is verified in the second region; the hourly check updates the line.
Rotate DKIM	Admin, SES domains	Writes a new key on the standby selector, publishes its TXT, then switches SES after DNS is OK. One rotation at a time: the button refuses a second rotation until the first one completes.

Streams

Gmail and Yahoo tell senders to keep bulk mail and transactional mail apart: different IPs or, at least, different DKIM domains. Each domain has a stream:

• Transactional — receipts, alerts, password resets (the default for new domains). The API refuses bulk kinds from this domain with 422 stream_mismatch.
• Bulk — newsletters and digests, best on news.<your-domain> with its own DKIM keys and reputation. A transactional kind from a bulk domain goes out tagged stream_warning.
• Mixed — both kinds share the domain. Use it only during a migration; split the streams when bulk volume is real.

The platform sends bulk kinds through a separate delivery configuration. This keeps the reputation data of bulk mail apart from transactional mail.

DNS records table

The table has one row per expected record: purpose, type, name, expected value, observed value, status and last-checked time. The status is OK, Mismatch, Missing, or Pending before the first check. Names and values have copy buttons.

• DKIM — two selectors, ep1 and ep2. One is active and signs messages. The other is a pre-published standby. Rotate DKIM writes a new standby key and switches after DNS is OK. Publish both; Verified needs only the active one.

• Return-Path — bounce.<domain>: an MX to the SES feedback host and an SPF TXT (v=spf1 include:amazonses.com -all). Receivers evaluate SPF against this domain, so your root SPF record does not need to change.

• DMARC — _dmarc.<domain> with adkim=s (strict DKIM) and aspf=r (relaxed SPF). Relaxed SPF lets bounce.<domain> align. The record also has a per-domain report address at dmarc.f5send.com. The p= and pct= come from the DMARC policy setting. New domains start at p=none; pct=100.

• Tracking / Inbound / MTA-STS / TLS-RPT — optional. These records are present only if you enable the feature.

DMARC policy card

The card shows the current setting as a pill (p=none, p=quarantine · pct=<n>, or p=reject) next to the status of the DMARC record in DNS. Admins see a Policy select and, for quarantine, a pct field (1 to 100). Click Set policy to save. The platform then rewrites the expected DMARC record and sets its status to Pending. On a Cloudflare domain it also publishes that one record and queues a verification. On a Manual domain the card shows the new name and value to copy; replace the TXT at your DNS provider and click Verify now.

The setting is the platform side of the ramp. The record status tells you whether DNS matches it. pct applies only to quarantine; none and reject always use pct=100.

The optional Also send reports to field keeps other report mailboxes in the record. Enter one or more email addresses, separated by commas. The platform writes them after its own address: rua=mailto:<platform address>,mailto:<your address>. Use this when a domain already sends DMARC reports to a security mailbox and you want to keep that feed.

DKIM keys card

The card shows the selector, active/standby, and the created and rotated dates. The platform generates the private keys and stores them encrypted. It never shows key material.

Rotate DKIM (Admin) writes a new key on the standby selector. After the new TXT verifies, SES signs with that selector. The old selector stays in DNS until the next rotation.

Deliverability checklist card

Six items that mailbox providers expect: SPF + DKIM, DMARC at quarantine or reject, MTA-STS, Gmail Postmaster data, Yahoo CFL and Microsoft SNDS. The platform computes the first four. An admin ticks the last two after the enrolment with Yahoo and Microsoft; the card shows the date. See Deliverability.

Gmail reputation card

This card shows the latest day that Gmail Postmaster Tools published for the domain. The Gmail compliance pill is green for Compliant, red for Needs work, and gray for Unknown. With Needs work, the card lists the sender requirements that fail, for example DMARC_POLICY. The pill is gray when the service account has only READER permission on the domain; compliance needs ADMIN permission.

The tiles show the user-reported spam rate, the SPF, DKIM and DMARC success rates, and the inbound and outbound TLS rates. The spam rate is green at or under 0.1 %, amber at or under 0.3 %, and red above 0.3 %.

The worker pulls the last 7 days once a day. Gmail publishes a day 1 to 3 days late, and only above a volume threshold. Until then the card shows "No data yet".

SPF audit card

This card is a live lookup of the root <domain> TXT record. It is advisory only. It shows the number of DNS lookups against the limit of 10. It shows flags: +all, no all mechanism, multiple SPF records, over the limit. It shows any include: not on the known-provider allowlist.

It also shows a read-only proposal that marks unknown includes and never removes them. Messages from the platform authenticate through the Return-Path host, so "no SPF record" on the root is acceptable.

DMARC tab

This tab shows the aggregate reports that arrived at the rua address of the domain in the last 30 days. It shows the total messages, the aligned percentage and the report coverage. It also shows a table of sending IPs with their DKIM/SPF alignment share. The DMARC policy card is also on this tab.

The Policy recommendation card recommends none → quarantine → reject. It moves up after 30 days of reports, ≥ 99 % alignment and no failing source above 1 % of volume. It compares the recommendation with the DMARC policy setting of the domain. If they differ, an admin can click Apply recommendation. That button runs the same action as Set policy with pct=100.

MTA-STS toggle

This toggle is for domains that also receive mail. When you enable it, the platform adds three records: _mta-sts.<domain> (v=STSv1; id=<yyyymmddHHMMSS>), _smtp._tls.<domain> (TLS-RPT to your DMARC intake address), and a mta-sts.<domain> CNAME to mta-sts.f5send.com. The CNAME target serves the policy file. Verified does not need these records.

The policy has a mode. When MTA-STS is on, the policy starts in testing. In this mode, senders report TLS failures to the TLS-RPT address but still deliver. After a week of clean reports, an admin sets enforce in the MTA-STS mode card. The card offers enforce only for a Verified domain with all three records OK. Each mode change gives the _mta-sts TXT a new id, so senders fetch the policy again.

Cloudflare domains get the new record at once. Manual domains need a publish and a verify.