External Attack Surface

Your compliance scans look inside your tenant. The External Attack Surface scan looks at it from the outside, the way an attacker would: it inspects the public-facing edge of your domains - TLS certificates, DNS security records, and exposed service endpoints - and flags what is weak, misconfigured, or worth a closer look.

It needs no agent and no access to your servers. Everything it checks is already public, so the scan simply gathers it, compares it against good practice, and turns it into clear findings.

Requires a paid plan

The External Attack Surface scan is included with paid plans. Without a paid plan the page shows an upgrade prompt instead of results. See the plans page for what each plan includes.

What it checks

Findings are grouped into three sections.

SSL/TLS

Overview. This section inspects the certificates and TLS configuration on your public hosts - the handshake a browser, a mail server, or an attacker negotiates the moment they connect. A weak or expired setup undermines every other control behind it.

Certificate expiry - whether a certificate is valid and not about to lapse. An expired certificate breaks trust and blocks users.
Protocol version - whether the host still negotiates weak, deprecated protocols (SSL 3.0, TLS 1.0 and 1.1) instead of TLS 1.2 or 1.3.
Cipher strength - whether the host accepts weak cipher suites, such as RC4, 3DES, or export-grade ciphers.
New certificates - certificates seen in public Certificate Transparency logs that are new since the last scan, so an unexpected issuance for your domain does not go unnoticed.

Remediation.

Renew certificates well before they expire, and automate renewal (for example ACME / Let's Encrypt, or your certificate authority's auto-renew) so a lapse cannot catch you out.
Disable SSL 3.0 and TLS 1.0/1.1 and serve only TLS 1.2 and 1.3 on every public host. For hosts you do not run directly - a CDN, a load balancer, a SaaS site - set this in that platform's TLS policy.
Remove weak and legacy cipher suites; the Mozilla "Intermediate" profile is a safe default unless you have a specific reason to differ.
Microsoft 365 service hostnames (such as outlook and autodiscover) use certificates and TLS settings that Microsoft owns, so there is nothing to change there - act on the custom hosts you operate.
Publish a CAA record so only your chosen certificate authorities may issue for the domain, and keep watching Certificate Transparency so an unexpected certificate is noticed quickly.

References.

DNS Security

This section covers the DNS records that protect your domain and your email - the controls that stop others from spoofing your domain, reading or tampering with your mail, or hijacking a forgotten record. Each record is explained on its own below: what it is, why it matters, and what a good, secure value looks like.

Email and domain-security records

Record	Type	Why it matters	What good looks like
SPF	TXT	Lists which mail servers may send as your domain, so receivers can reject spoofed mail.	One TXT record on the apex that authorises Microsoft 365 and ends in a hard fail: `v=spf1 include:spf.protection.outlook.com -all`. Never use `+all`, which authorises every sender.
DKIM	CNAME	Signs your outgoing mail so receivers can prove it was not altered in transit.	DKIM signing enabled for the domain in the Microsoft Defender portal, with the two `selector1` and `selector2` CNAME records it issues published.
DMARC	TXT	Tells receivers what to do with mail that fails SPF or DKIM, and sends you reports.	A `_dmarc` TXT record of at least `v=DMARC1; p=quarantine` with a `rua=` report address. Move to `p=reject` once you are confident. `p=none` only monitors and does not protect.
MX	MX	Directs where mail for your domain is delivered.	MX points at `<your-domain>.mail.protection.outlook.com` for mail routed through Microsoft 365.
DNSSEC	-	Signs your DNS answers so they cannot be spoofed on the way to a resolver.	DNSSEC enabled at your DNS provider or registrar, so your zone is signed.
Subdomain takeover	CNAME	Finds dangling records pointing at a service you no longer run, which an attacker could claim.	No CNAME left pointing at an unused service. Remove or repoint any dangling record before someone else claims it.

Microsoft 365 service records

These standard records let Microsoft 365 services find their endpoints on your domain. The scan shows the value each should point at next to the value it points at now.

Record	Host	Should point at	Purpose
Autodiscover	`autodiscover`	`autodiscover.outlook.com`	Lets Outlook find its mailbox settings automatically.
Skype / Teams	`lyncdiscover`, `sip`	`webdir.online.lync.com`, `sipdir.online.lync.com`	Discovery for Skype for Business / Teams.
Device management	`enterpriseregistration`, `enterpriseenrollment`	`enterpriseregistration.windows.net`, `enterpriseenrollment.manage.microsoft.com`	Windows device registration and enrolment.

A record that is simply absent is shown for information (you may not use that service). A record that points somewhere other than the Microsoft target is flagged, because it can break the service or be a sign of a stale or hijacked entry.

References.

Exposed Endpoints

Public surfaces that widen your attack surface:

Legacy authentication endpoints - older protocols that bypass modern sign-in protections and are a common route for password attacks.
External sharing - how broadly SharePoint and OneDrive allow sharing outside your organization.
Guest access - how freely guests can be invited into your tenant.

Additional Domains

The scan needs to know which hosts to look at. There are two kinds of target.

Auto-discovered domains

When a scan runs, Aether365 reads the verified domains from your connected Microsoft 365 tenant and scans those automatically, along with the standard Microsoft 365 service hostnames derived from them (such as autodiscover and owa). Because Microsoft has already verified that you own these domains, they are trusted and scanned without any extra step from you.

You can exclude an auto-discovered host from scanning if you do not want it included, but you cannot delete it - it would simply be rediscovered on the next scan.

Custom domains

You can add your own domains - for example a marketing site or a product domain that is not part of your Microsoft 365 tenant. Open Additional Domains, enter a bare domain name (like example.com, with no https:// and no path), and add it.

Before issuing a verification step, Aether365 confirms the domain is actually registered and resolving (it exists in the DNS and has address or mail records). A misspelled or parked domain is rejected up front, because there would be nothing to scan. Domains already covered by your Microsoft 365 tenant are also rejected, since they are scanned automatically.

Custom domains must then be verified before Aether365 will scan them. This proves you control the domain and stops anyone from pointing our scanner at a site they do not own.

Verifying a custom domain

When you add a custom domain it starts as Unverified and is not scanned yet. To verify it:

In Additional Domains, find the domain. It shows a DNS TXT record to publish, in the form:
```
aether365-site-verification=<your-unique-token>
```
Add that value as a TXT record at your DNS provider, on the domain itself (the apex). The exact steps depend on your provider, but you are creating a new TXT record whose value is the line shown in the app. Use the Copy record button to copy it exactly.
Save the record at your provider and give DNS a few minutes to propagate.
Back in Aether365, click Verify. We look up the domain's TXT records and confirm yours is present. Once it matches, the domain is marked Verified and will be included in your next scan.

DNS takes a little time

If verification fails right after you publish the record, wait a few minutes and try again - DNS changes are not always visible immediately. The token stays valid, so you can retry as often as you need.

You only need to verify each custom domain once. Auto-discovered Microsoft 365 domains never need this step.

Running a scan

Open the Attack Surface page and select Run scan. The scan runs in the background and the page shows its progress; when it finishes, the three sections fill with findings and the posture summary at the top reflects the latest run. You can run a scan on demand whenever you want a fresh picture.

Reading the results

Results are grouped by domain. Each domain has its own card, and every Microsoft 365 service hostname (such as autodiscover.example.com or sip.example.com) sits inside the card for its root domain rather than as a separate entry. A card is open by default; click its header to collapse it.

Inside a card the checks are split into the services they belong to - Mail security, Domain security, Autodiscover, Skype / Teams, Device management, Certificates, and Exposed endpoints - so related records sit together.

Each card opens in a readable list, and a table toggle in the card header switches the DNS records into a scannable table so you can read every record at a single glance. The table has one row per record with four columns:

Column	What it shows
Type	The record type as a pill: TXT, CNAME, MX, and so on.
Host / name	The host the record lives on, such as `autodiscover.example.com`.
Status	A coloured pill: Match (green) when the published value is correct, Mismatch (red) when a value is published but wrong, or Missing (amber) when nothing is published.
Published value	The value published right now. When a record needs fixing, the value Microsoft 365 expects is shown directly beneath it, so you can compare expected against current side by side. Long values such as DKIM keys stay on one line until you expand them.

Records that need attention are listed first, so the ones worth fixing sit at the top. A missing record may be fine if you do not use that service. Whichever view you use, each finding links to more detail on the specific check.

The summary at the top of the page totals the open issues by severity, and each domain card shows how many of its records need attention, so you can see where to look first.

Frequently asked questions

Does the scan touch my servers? No. It only reads information that is already public - DNS records, TLS handshakes on standard ports, and Certificate Transparency logs.

Why is a custom domain not being scanned? It is probably still Unverified. Add the TXT record shown in Additional Domains and click Verify. Until a custom domain is verified, it is skipped.

Can I remove an auto-discovered domain? You cannot delete it, but you can exclude it so it is left out of scans.

External Attack Surface ​

What it checks ​

SSL/TLS ​

DNS Security ​

Email and domain-security records ​

Microsoft 365 service records ​

Exposed Endpoints ​

Additional Domains ​

Auto-discovered domains ​

Custom domains ​

Verifying a custom domain ​

Running a scan ​

Reading the results ​

Frequently asked questions ​