Email security

Cloud > Email security looks after the mail authentication of every customer domain: whether the DNS records are right, what they should be, who is really sending as the domain, and when it is safe to move DMARC on towards reject.

The domain list#

Each domain shows its Customer, overall Status (OK, Attention or Problem), a dot for each check (MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT) and its DMARC stage. Filter by customer, status, stage, platform, DNS provider and unknown senders.

Where domains come from#

• Every connected tenant's verified domains that carry email are added by themselves. onmicrosoft.com addresses and service hostnames (signature services, gateways and the like) are never added, and nothing is removed when a tenant stops listing a domain.
• Press Add domain to add one by hand for any customer, for example a Google Workspace customer or a parked domain.
• Press Add several at once in that dialog to add many (below).

Adding many domains#

1. Press Add domain, then Add several at once.
2. Choose Paste a list for one customer, or CSV file for several. A CSV has the columns customer, domain and platform (customer by name or code; platform m365, google, other, none, or empty to detect it), and there is a template to download.
3. For a pasted list, choose the Customer and paste the domains, one per line or separated by commas or spaces. The customer's own email domains that are not here yet are offered too.
4. Press Check. Every row is checked first: new, already here, twice in the list, not a domain, a service hostname, an unknown customer or platform, or a domain of another customer's Microsoft 365 tenant.
5. Add the new ones. Each gets its first check straight away.

Working with the list#

• Check now on selected domains (or Check these N now under a filtered list) checks a set at once.
• The Never set up view lists domains with no DNS record ever written and no report ever received. Select them and Remove them in one go. A tenant's own domain is switched off rather than removed, since the next sync would bring it back.

The mail platform (Microsoft 365, Google, other or no mail) is worked out from the MX records, and you can set it yourself.

The checks#

Each domain is checked every hour and whenever you press Check now:

Domains that route mail through a signature service such as Exclaimer or CodeTwo are recognised: the service's routing domain is not judged as DKIM off.

Autodiscover, DNSSEC and BIMI are also looked at, for information only. A lookup that fails is shown grey and never counted against the domain. The overall status is the worst of the six scored checks.

A domain's page#

Open a domain to see its Customer, Tenant, Platform, DNS host and DMARC stage, with Check now. The tabs are Overview, DNS, SPF, Reports, Senders, TLS, MTA-STS, Ramp and History.

The Overview lists each check with what is wrong and exactly what to change, how many DNS records need adding or changing, messages and DMARC pass rate over 30 days from the reports, and the domain's report addresses.

Fixing the DNS#

The DNS tab lists every record the domain should have, with its State (In place, To add, to change, or a conflict), Type, Name, what it Should be and Why.

How you apply them depends on where the DNS is hosted:

• Cloudflare: with a Cloudflare account connected in Settings, Tenvara writes the records itself when you apply them.
• Anywhere else: press Copy all, add the records at the DNS host, then press I have added these. Tenvara logs them and checks the domain again.

Tenvara is careful with existing records. SPF is edited, never replaced, adding the platform's includes. An MX that points somewhere else is never overwritten. Unrelated TXT records are never touched. Every record written, refused or advised is kept in the domain's History.

For Microsoft 365 domains, DKIM is switched on in Exchange by itself once both selector CNAMEs are correct and signing is still off: Tenvara checks after every domain check and in a daily sweep, and makes the change through the change log (shown as Automatic, and it can be undone). If Exchange refuses, the domain raises an alert until DKIM is on. You can switch this off in Settings > Microsoft 365, the Email security tab, for everyone or per customer. The DKIM signs mail for every domain fix does the same by hand (see Security findings).

Bulk setup writes every record that needs writing for all the domains Tenvara can write to and fully work out.

Reports and senders#

Tenvara publishes its own report addresses in each domain's DMARC and TLS-RPT records, then reads the aggregate, failure and TLS reports receivers send.

• Reports shows the DMARC reports received, TLS the TLS reports.
• Senders lists who sends as the domain, named from a catalogue of 44 known services (Microsoft 365, Google Workspace, Mimecast, HubSpot and so on) or by IP address, with messages, DMARC pass and SPF and DKIM alignment. Mark each as Approved, Unknown or Unauthorised.

An unknown sender with 20 or more messages, or an approved one failing more than 10% over the last seven days, raises an alert. After you edit the sender catalogue, the senders of every domain are worked out again from the reports already received (Rebuild senders in Settings does it on demand).

The report inbox#

Cloud > Email security, the Report inbox tab, lists every DMARC and TLS report mail received, however it arrived, newest first, with All, Parsed, Ignored and Failed tabs and their counts. Each row shows when, the sender, the subject (with any error under it), the domain it was filed under (or Unmatched) and its status.

• Open a row to see the headers, attachments, the error or why it was set aside, and the reports it gave. Administrators can download the raw mail.
• Reprocess reads a mail again from its kept copy (press r on the active row). Reprocess all failed does every failed one in the view. Reprocessing never counts a report twice.
• Where reports come from shows how report mail reaches Tenvara.

Raw mail is kept for 90 days to start with (Settings > Microsoft 365, the Timings tab, Email security history). People who only look after some customers see those customers' domains' mail; unmatched mail is for everyone else.

Moving to reject#

The Ramp tab takes a domain from monitoring to reject in stages: Monitor (p=none), Quarantine 25%, Quarantine and Reject. It shows the record for the next stage and what must be true first.

Tenvara only advises moving on when, over the last 30 days: SPF and DMARC are not failing, DKIM works for Microsoft 365, there are enough days of reports (14 at monitor, 7 after), it is at least seven days since the last move, at least one sender is approved, no unknown sender has 20 or more messages, and every approved sender passes at least 98%. You always make the move yourself with Move here; Tenvara writes the DMARC record where it can. An alert tells you when a domain is ready.

When a domain arrives already reporting to another DMARC provider, Tenvara keeps sending them copies for 14 days before cutting over, and you can cut over sooner or extend. A domain never cuts over until Tenvara's daily report test has passed in the last 7 days and a real DMARC report for the domain has arrived in the last 30, so no reports are lost; until then dual reporting carries on and the Ramp tab says why.

MTA-STS#

MTA-STS makes other mail servers use TLS when delivering to the domain. Tenvara hosts the policy for you: mta-sts.<domain> only needs a CNAME pointing at your Tenvara host. The CNAME must be DNS only: Tenvara writes it that way on Cloudflare, sets a proxied one to DNS only when the plan is applied again, and the check turns red with "set it to DNS only" when Cloudflare's own rules answer for the host. The tab shows a Proxy line (DNS only, proxied or not known). The MTA-STS tab shows the policy served, TLS sessions and failures over 14 days, and the settings (Mode, Max age, MX hosts).

Start in testing mode. Tenvara advises enforcing once the MTA-STS and TLS-RPT checks pass and TLS reports show at least 7 days of reports and 20 sessions with no failures. Enforce anyway is there if you are sure.

Settings#

Settings > Microsoft 365, the Email security tab (administrators) holds:

• Use the relay: one click registers your install with the Tenvara mail relay, which gives you a report domain and sets up its MX, the report authorisation record, TLS and the MTA-STS host, with nothing to add to your own DNS. Installs Tenvara hosts are registered by themselves.
• Or your own Report domain and MTA-STS host. Check now checks each part (the MX and that it takes mail, the report authorisation record, TLS on the MX, the MTA-STS host and, for your own domain, its SPF and DMARC) with a state and words for each, and Set up writes what is missing where Tenvara can (a connected Cloudflare zone) and lists the rest plainly. Choose these once: changing either later changes every domain's records.
• How reports arrive: through the relay, a Reports mailbox in your own Microsoft 365, read every five minutes, or an SMTP relay webhook signed with a secret. A reports mailbox can take every domain's reports through plus addresses, so you need no alias per domain.
• Switch DKIM on in Microsoft 365 once the CNAMEs resolve (on to start with).
• Cloudflare accounts: a token with Zone DNS edit, Zone read and Config Rules edit lets Tenvara write records for every domain in the account.
• The Sender catalogue, where you can add or edit services, and Rebuild senders.
• The alert thresholds (also in Settings > Microsoft 365, the Timings tab, under Email security alerts).

Is report mail arriving?#

Every day Tenvara sends a test DMARC report and a test TLS report to your report domain and follows them until both are read. The health line under the records, and the Email security reports row on Settings > System status (the System health tab), say whether report mail is flowing. When domains send their reports here and no real report has arrived for 24 hours, or the daily test fails, one install-wide Report mail stopped alert says so (rather than one alert per domain), and it clears once reports flow again.