Glossary — Website, SSL, DNS & Security Terms

When a check fails, the app tells you exactly what it found — an expired certificate, a missing DNSSEC signature, a weak cipher. This page explains what those things actually mean and why they matter, in the same groups and in the same order as the glossary built into the app, so a term you meet on a scan report reads the same in both places.

Find a term

Search all 144 terms by name or by the words in their definition.

Monitoring basics

Monitoring: Checking a website automatically, on a schedule, so you find out about a problem before a visitor does. Beyond Site does the checking for you, so you do not have to keep opening the site to see whether it is still there.
Uptime: The proportion of time a site answers checks successfully. Usually quoted as a percentage over a period, so 99.9% over a month still allows roughly 43 minutes of downtime. Higher is better.
Downtime: Any period where a check fails: the server does not respond, or it responds with an error. Beyond Site records the start and end of each failure so you can see how long an outage lasted.
Response time: How long the server took to answer, measured from the request being sent to the first byte coming back. A site can be technically up and still be slow enough to lose visitors. Lower is better.
Threshold: The number of days before a certificate expires at which Beyond Site warns you. You set three of them, Green, Orange and Red, and each has to be less than or equal to the one above it so the warnings arrive in a sensible order.
Green / Orange / Red alert levels: The three warning stages for a certificate running out. Green is the first, gentle heads-up, Orange means start planning the renewal, and Red means act now. You choose how many days of warning each one gives you.
Alert recipients: The email addresses told about a problem at each level. You can use different addresses for Green, Orange and Red. If a level has no addresses, no email is sent for that level.
Alerts enabled / disabled: A per-site switch. When alerts are switched off for a site, Beyond Site keeps monitoring it but never sends you an alert about it, which is useful for a site someone else looks after.
Duplicate alert: The same alert arriving twice for a problem you already know about. Beyond Site remembers the last alert it sent per site and only sends a new one when something actually changes, so your inbox is not filled with repeats.
Notification: A message from the app on your phone. Beyond Site can notify you when a site goes down or when a certificate is close to expiry, even while the app is closed.
Email alert: An alert delivered as a normal email instead of a notification on your phone, using a mailbox you configure yourself. Email alerts are never capped, and only alerts that were actually delivered count, so a send that failed does not use anything up.

Beyond Site features

Check interval: How often Beyond Site tests each site. A shorter interval catches problems sooner but uses more battery and data, so you choose it with the auto-refresh timer rather than being stuck with a fixed rate.
Background refresh: Checks that run while the app is closed, so a certificate that expires overnight is already known about before you next open the app. The phone operating system decides exactly when these run.
Monitoring log: The running history of every check performed against a site: when it ran, what status came back, and how long it took. It is what turns a single result into a trend you can act on.
Dashboard: The summary screen: how many sites are up, how many are down, response times, and which certificates are closest to expiring, all shown in charts you can export.
Scheduled downtime (DT): A window you set during which monitoring is deliberately paused, for planned maintenance. Monitoring resumes automatically when the window ends, so deliberate work does not produce a page full of false alarms. You can set it for one site on its own, a category, or every site at once, and either start it straight away or schedule it ahead, once or on a repeat, from the DT button in the app bar.
Per-site downtime: Downtime that applies to a single site rather than the whole list. Each site card carries its own DT chip: pause just the site you are working on and every other site carries on being checked and alerted on as normal. That chip offers the same choices as the all-sites Downtime button on the Schedule Downtime screen, a timed window from five minutes to a day or a pause with no end date, and while a site is parked it shows a DT badge counting down the time left.
Pinned site: A site kept at the top of the list so it is always the first thing you see. Pin the site you care about most.
Site category: A label, for example Work, Home or Live, that groups related sites. Categories let you filter the list and run one security scan across a whole group of sites at once.
Speed Trace: A single-site diagnosis that breaks a slow page down into the stages that make it slow: finding the address, connecting, the secure handshake and the response. It shows where the delay actually is.
DNS Monitor: A tool that records a domain’s DNS configuration and tells you if any of it changes, which is often the first warning that a domain has been tampered with or that a change went out unexpectedly.
Security Scan: A deep, single-site inspection. It checks the DNS, the connection, the secure handshake, the certificate and the security settings the server sends back, then lists the problems it found in plain language.
Group Security Scan: The same deep scan run across every site in a category at once, so a whole estate of sites can be checked together instead of one at a time.
Posture Score: A number from 0 to 100 summarising the whole scan, shown next to the security band. It starts at full marks and takes points off for specific things that were found: an outdated protocol, a weak encryption option, a certificate close to expiry, a missing protection header. Higher is better, and the breakdown underneath says exactly where the points went.
Security band: A word summarising the Posture Score, so you can judge a report at a glance without reading the number: Hardened (90–100), Strong (75–89), Moderate (50–74), Weak (25–49) and Critical (0–24). Each band also has a single-letter grade — A for Hardened, B for Strong, C for Moderate, D for Weak and F for Critical — shown beside the word as a quick shorthand. The letter is not a separate judgement: it is worked out from the same Posture Score, so a grade and its band can never disagree. There are no plus or minus steps, and no separate penalty grades; one letter belongs to each band. Reports saved before bands existed still show their old letter, and the app shows the matching band next to it.
Layers checked: How many of the five stages of the scan actually completed: DNS, connection, handshake, certificate and protection headers. If an early stage fails the later ones cannot be reached, so the score is held at zero until the site answers. A low score for an unreachable site is a statement about reachability, not about how well it is set up.
What the scan does not check: The scan looks only at what a server tells the outside world. It cannot see your passwords, your users, your database, your login page, your code, or anything behind a login. A good score means the front door is in order, not that the whole building is safe.
Detected risk: A specific problem the security scan found, written out in full: for example a weak cipher, an outdated protocol, a missing security header or a certificate close to expiry. Tap one to see what it refers to.
Ping: A minimal test that asks whether a machine is reachable at all. It is the quickest way to tell a network problem apart from a website problem.
CSV import / export: Your site list and settings written out as a plain spreadsheet file that other programs can read, and read back in again. It is a backup you control and a way to move your sites to a new phone.
Demo data: Sample sites, logs and notifications added so you can explore the app without typing in real addresses first. Clear it whenever you like.
Filter sites: Narrow a long site list down to the ones you care about, across four choices: category, a detected problem, certificate state, or an expiry date range. Filtering never changes your sites; it only hides the ones that do not match, and the count at the top of the filter screen shows how many sites still match as you choose. Nothing is applied until you confirm, so backing out leaves the list as it was. While a filter is on, the filter button shows an ON badge and the list states how many sites of the total are being shown.
Dark mode: A darker colour scheme that is easier on the eyes at night and uses less power on an OLED screen. Tap the single button in the app bar to step through light, dark, and following whatever your phone is set to. It shows a sun, a moon, or an A for automatic, so you can see which one is in use.
Web address (search box): The field near the top of the main screen where you type a domain to add. Two buttons sit beside it: one opens the filter screen, which narrows the list you already have, and the other opens the Logs screen, which shows the recent check results behind the list.

What a site card shows

Up / Down / Unknown: The three states a site can be in. Up means the last check succeeded, Down means it failed, and Unknown means there is not yet a trustworthy result, for example before the first check has finished. Unknown is shown rather than guessing.
HTTP status code: The three-digit number a web server returns with every reply. It is the single clearest signal of whether a request worked, was sent elsewhere, or failed. Beyond Site shows it beside each site.
2xx, 3xx, 4xx, 5xx: The four families of status code. 2xx means success, 3xx means the request was redirected somewhere else which is usually fine, 4xx means the request was refused (a missing page, a blocked visitor), and 5xx means the server itself failed. Beyond Site treats 2xx and 3xx as healthy.
200 OK: The normal everything-worked reply. A page that loads correctly returns 200.
301 / 302 redirect: A 301 or 302 reply means what you asked for has moved and you should go here instead. This is normal, since most sites send you from the plain address to the www or the secure https address, but a long chain of them slows every visit down.
404 Not Found: The page asked for does not exist. On a homepage this usually means the site is misconfigured; on a deep link it may just be a stale address.
5xx server error: A 500, 502, 503 or 504 reply means the server itself is broken or too busy, as opposed to the request being refused. This is the kind of failure that takes a whole site down.
Redirect chain: The sequence of hops a request follows before it lands on the final page, for example to https, then to www, then to the real page. Each hop adds a delay and is a link that can break. Beyond Site flags chains that get too long.
Timeout: When a site does not answer within a set time, so Beyond Site gives up and records a failure. A timeout usually means the server is overloaded, offline, or something between you and it is blocking the way.
Certificate status: A plain-language summary of the site’s security certificate: Secure, Not secure (expired), or Not secure (missing or invalid).
Days until expiry: How many days are left before the site’s security certificate stops being trusted. When it reaches zero, browsers start warning visitors away from the site. Beyond Site shows the count so you can renew in good time.
Last checked: The date and time the most recent check ran, so you always know how fresh the result on screen is.

Why a check failed

DNS resolution failed: The name could not be turned into an address, so there was nothing to connect to. This is the most common cause of a site disappearing: the domain has expired, its nameservers are down, or a DNS change has not spread yet.
Connection refused: The address was found, but the machine at the other end actively turned the connection away. It is usually reachable but is not running the web service you expected, or a firewall is blocking you.
Connection timed out: Nothing answered at all before the time limit ran out. Often a firewall silently dropping the traffic, or a server that is overloaded or off.
SSL handshake failed: The secure connection could not be set up, so an https site will not load at all. Common causes are an expired or mismatched certificate, an unsupported protocol version, or a firewall blocking the secure port.
Network unreachable: There was no route to the address at all, which is a lower-level networking problem rather than a problem with the website itself.
Redirect loop: The site keeps sending the visitor back and forth between addresses forever, so the page can never load. It is a configuration mistake on the server.

SSL, HTTPS and certificates

SSL / TLS: The encryption that protects a connection to a website, which is what turns http:// into https://. It stops anyone in between reading or altering what is sent. TLS is simply the modern name for what is still widely called SSL.
HTTPS: The secure version of a website address, protected by SSL/TLS. The padlock in a browser address bar means https is in use. Google and browsers now actively warn visitors about sites that do not use it.
Certificate: A digital document a website shows to prove it really is the site it claims to be. Browsers check it automatically, and if it is missing, expired or wrong they show a full-page security warning instead of the site.
Certificate expiry: The day a certificate stops being trusted. Certificates are valid for about a year at most, and letting one lapse is the single most common reason a working site suddenly starts turning visitors away. Beyond Site tracks this and warns you in advance.
Certificate Authority (CA): The trusted organisation that issues and signs a certificate, for example Let’s Encrypt, DigiCert or Google Trust Services. Knowing which one signed your certificate tells you who to contact if a renewal fails.
Issuer: The specific signing authority whose name is inside a certificate. It should be one you recognise, and an unfamiliar issuer is worth investigating.
SAN (Subject Alternative Name): The list of addresses one certificate covers. A certificate for example.com may also cover www.example.com and mail.example.com. Checking this list is how you confirm a particular address is genuinely covered rather than hoping it is.
Certificate chain: The path of certificates from the one a server presents up to a root that browsers already trust. A missing link in the middle is a classic cause of a site working on one device but failing on another.
Self-signed certificate: A certificate a server signed itself rather than getting it from a trusted authority. Browsers do not trust these and will warn visitors, so they are fine for testing but not for a public site.
Hostname verification: Checking that the address the visitor typed actually matches one the certificate is valid for. A mismatch means the certificate is being reused on the wrong name, and browsers will refuse it.
Expired certificate: A certificate whose expiry date has passed. Until it is renewed, browsers will not let visitors through without an alarming warning, which is why Beyond Site alerts on it early.

Security scan findings

Cipher suite: The specific combination of encryption methods used to protect a connection. Older servers often still offer weak or outdated ones, which is a real weakness even when the site appears to work perfectly.
Weak cipher: An encryption method that is no longer considered strong enough. A site still offering one can have its traffic decrypted by a determined attacker, so the scan flags it.
Forward secrecy: A property that stops a recorded conversation from being decrypted later, even if the server’s private key is eventually stolen. Modern setups have it, older ones do not, and the scan says so.
Protocol version (TLS 1.0–1.3): The version of the secure-conversation rules being used. TLS 1.2 and 1.3 are current, while 1.0 and 1.1 are obsolete and are reported as a finding.
Deprecated protocol: An old version of the secure-conversation rules that is still supported but should no longer be, because known attacks exist against it. Supporting it widens the ways in for an attacker.
Hardening: The work of tightening a server’s settings, turning off old protocols, removing weak ciphers and adding security headers, so it is not easy to attack. The scan’s findings are a to-do list for that work.
HSTS (Strict Transport Security): An instruction a site sends telling browsers to always use the secure version of it from now on. Without it, a visitor’s first request can be intercepted and downgraded to an unencrypted one.
HPKP (Public Key Pinning): An older instruction that told browsers to only ever accept one specific certificate for a site. It proved risky in practice and is now largely abandoned, so the scan reports it as absent rather than a problem.
Security headers: Small instructions a server attaches to its replies that tell browsers how to behave, for example which content they may run and whether the site may be shown inside another page. Missing ones widen the ways a site can be attacked.
Content-Security-Policy (CSP): A security header that lists which scripts and content a page is allowed to load. It is the main defence that limits the damage if malicious code does find its way onto a site.
X-Frame-Options: A security header that says whether the site may be displayed inside another page. Without it, an attacker can overlay a fake page on top of the real one to trick visitors, a clickjacking attack.
OSCP / CRL (revocation): Two ways of publishing that a certificate was cancelled before its expiry date. The scan checks whether the server tells browsers where to look for that information.
Key strength: How long the certificate’s encryption key is, in bits. The threshold depends on the kind of key, because the two kinds are measured on different scales: an ordinary RSA key needs at least 2048 bits, while an elliptic-curve key needs at least 256 bits, since a 256-bit curve already gives about as much protection as a much longer RSA key. A key below the figure for its own kind is flagged.
SHA-1 / signature algorithm: The method used to seal a certificate against tampering. SHA-1 is old and broken, so a certificate still using it is flagged even if everything else is in order.
CRIME: A known attack that exploits a compression setting in old secure connections. The scan reports the setting as vulnerable when it is enabled, because turning it off costs nothing.
ALPN / Negotiated protocol: A note about which higher-level version the client and server agreed to use during the secure handshake. It is informational and rarely needs any action.
Elliptic Curve (EC) key: A kind of encryption key that gives the same strength as a much longer traditional key, so it is faster. Its presence is a good sign, not a problem.
Port / TCP: TCP is the underlying way two machines hold a conversation, and a port is the numbered door a particular service listens on. The web normally uses 443 for https and 80 for http. A port can be closed to you even when the site itself is fine.

Reading a scan report

Security Scan report: The full report produced by the Security Scan tool: one domain, checked end to end. It works in five stages, the domain name, the connection, the secure handshake, the certificate, and what the server sends back, and writes down what it found at each one. The top of the report carries the security band, the Posture Score and how those points were divided up, and the Detected Risks list is placed with it so the actionable summary is the first thing you read. Everything below that is the supporting detail.
Monitored host: The exact machine the scan asked for the site, for example shop.example.com, which is often not the plain domain name, example.com, that it belongs to. Being sent on to another machine is normal, because it is how large sites share the load.
Protocols supported: The list of versions of the secure-conversation rules the server will accept, such as TLS 1.3, 1.2, 1.1 and 1.0. A well-set-up server offers only the current ones. Seeing the old ones listed is not a fault by itself, but the older they are the more they weaken what is offered.
Negotiated protocol: The single version the scan and the server actually agreed to use for this connection, usually the best one both sides understand. It is shown separately from the full list of protocols supported because it is the one really in use.
Negotiated ALPN: The short code the two sides swap to agree what kind of conversation this is, h2 for the modern version of http and http/1.1 for the older one. It says nothing about security, because it only tells you which way the data will be carried.
Certificate count: How many certificates the server handed over in one go. Serving more than one is normal, because it lets the server send a replacement chain for older browsers that do not know a newer signing method.
Handshake simulation: A test that pretends to be different visitors, an up-to-date browser and an older one, and reports which protocol and cipher each of them ended up with. It shows whether old devices silently get a weaker connection than new ones.
Cipher suites section: The list of every encryption combination the server was found to offer, one row each, with the protocol it works over, the key size it uses, whether it keeps forward secrecy and whether it is considered weak. Explained fully under the security terms, because this is simply where the report puts it.
Certificates section: Everything the scan learned about the certificates the server sent: the subject and issuer, the valid-from and valid-to dates, the signature method, the key strength and whether the chain is trusted. Each of those is defined separately in the security terms.
Certificate policy: A note the issuing authority can attach to a certificate saying which of its own published rules the certificate was issued under. The commonest one marks a certificate as identity-checked, which some authorities will only do after confirming the business by hand. The scan reports the note the issuer attached; it does not carry out that check itself, so treat this row as what the authority says rather than as an independent guarantee.
Protocol details and vulnerabilities: The longest part of the report: a line-by-line answer for each older or riskier feature, covering whether HSTS is set and how, whether the safe-content headers are present, whether TLS compression is enabled, and whether the certificate still uses SHA-1. It is the evidence behind the shorter Detected Risks list rather than a second list of problems.
Detected Risks: The plain-language list of everything the scan judged to be a problem, shown near the top of the report, just under the security band and Posture Score. Each entry starts with how serious it is, Critical, Warning or Info, so reading just this list tells you whether anything needs doing. The detail further down the report is the evidence behind these entries, not a second list of problems.
Risk severity (Critical / Warning / Info): The three labels the Detected Risks list uses. Critical means a real weakness an attacker could use, such as an expired certificate or encryption that can be broken. Warning means something that should be fixed but is not an open door. Info is context that is worth knowing and usually needs no action, for example an older protocol still being supported.
What a risk means: Every entry in the Detected Risks list carries a short plain-language explanation of the idea behind it, directly under the finding. So "lacks forward secrecy" is followed by a sentence saying what was actually lost and who could take advantage of it, without expecting any background knowledge. Those explanations use the same wording as this glossary, so the two always agree.
How to read a risk: Each finding is one sentence naming what was found, then a sentence saying what it means in practice. Tapping a finding expands the exact items it refers to, which cipher suites, which certificate, so the evidence sits directly under the conclusion. A finding with nothing further to show has no expansion at all.
No significant risks detected: The scan’s way of saying it looked and found nothing worth acting on. It is the result you want, not a failure or an empty report, because it means every check ran and none of them flagged anything.
Extended master secret: A hardening step added to the older secure-conversation rules. It ties the keys for a conversation to the whole of the handshake that set it up, so a replayed opening cannot be spliced onto a different conversation. A server that does not support it is reported as a warning, because without it an attacker sitting between you and the server has a harder-to-spot route to interfering. The newest rules do the equivalent automatically, so the row does not apply to a site that only speaks them.
Secure renegotiation: A way for both sides to prove they took part in the original handshake before changing settings part-way through a connection. Without it, a connection can be made to look as though it was started against a different site than it really was. The scan reports it from the server’s own reply, so a site that does not support it is flagged.
Session resumption: Reusing the settings from an earlier visit instead of agreeing them all over again. The report says whether the server offered a way to do this. It is neither good nor bad on its own, since it is a speed feature, but it is worth knowing about because resumed sessions are where the hardening steps above do their work.
Cipher suite preference: Which end of the connection gets to choose the one encryption combination that will be used, the client or the server. When the server chooses, it can refuse to be talked into a combination it would rather not offer; when the client chooses, a visitor can steer the choice. The scan works this out by offering the same two combinations in both orders and seeing which one comes back each time.
Cipher construction: How the encryption combination in use is actually built: which cipher seals the data, and how the message is checked for tampering. The modern way does both jobs in one step and is called AEAD; older combinations seal and check separately and use a block mode such as CBC, which has a history of padding attacks. The report names the construction so you can see at a glance which kind the site is using.
CBC-mode cipher suites enabled: How many of the offered encryption combinations use the older CBC block mode. It is not broken by itself, but it is the setting behind a long line of padding-related attacks, and it is one of the things the newest rules dropped entirely. Counting them turns how much older ways survive here into a number you can compare across sites.
TLS 1.3-compatible cipher suites: How many of the combinations the server offers are the kind the newest secure-conversation rules allow. Those rules threw out the older ones outright, so this is a quick way to see how much of the server’s list is still current. It is a count from the scan’s own probing and does not affect your score.
Key exchange without forward secrecy: How many of the offered combinations set up the secret keys by encrypting them with the server’s long-term certificate key. If that key is ever obtained, every conversation set up that way can be unlocked later. Combinations that instead agree a fresh secret each time do not have this weakness. This row counts the ones that do.
Negotiated key-exchange group: The particular mathematical group both sides used to agree their shared secret. The named curves and the newer x25519 are the current choices; older or shorter groups are weaker even when everything else looks fine. The report names the group the server actually selected, which is the one in force for the connection. A server that agreed the secret by encrypting it with its certificate key instead has no group to name, so the row stays blank in that case.
DNS CAA: A note in your domain name settings naming which certificate authorities are permitted to issue certificates for that domain. It is a guard rail that stops an unauthorised authority from issuing one behind your back. A site with no such note can have a certificate issued for it by any publicly trusted authority. This is the one row a Security Scan fills in by asking a public name resolver rather than the site itself, because the note lives in the domain name system.

Group and comparison reports

Group Security Scan report: The many-site version of the Security Scan. You pick a site category and it scans every site in it using the same deep check, then compares the results side by side so you can spot the one site that is set up differently from the rest. It saves scanning each domain on its own.
Sites scanned: The plain list of every site included in a group scan, showing each one’s own result. The Differences Across Sites panel above it is drawn from these rows.
Differences Across Sites: The panel at the top of a group scan, in the app and in the PDF, that names the settings which are not the same on every site in the group, for example one site still offering TLS 1.0 while the rest do not. It lists the compared sites first, then each difference with the value every site reported. In a well-run group almost everything should match, so each listed difference is a shortlist of things to look at.
Comparison metrics: The fixed set of settings a group scan lines up across all its sites: the security band, the agreed protocol, forward secrecy, the cipher in use, how that cipher is built, the certificate subject, issuer, key strength, signature, expiry, chain and policy, whether the server supports the hardened session features, which end chooses the cipher, the HTTP status, the protection headers, the cookie flags, the CAA records and whether the site redirects. Only the metrics that differ are shown.
Protection headers in comparison: The state of each site’s main protection headers gathered into one line for the comparison, with each header shown as agreed, weak or missing rather than just being listed as present. Two sites can both send HSTS and still differ, because one sets a long lifetime and the other a very short one, and this line makes that visible.
Group Security Report (PDF): The shareable file a group scan produces: a cover page, then the Differences Across Sites summary straight away, then every site’s own results below it. The summary is deliberately placed above the per-site detail so the answer to how these sites differ is the first thing you read. It is the version to keep, print, or send to a client.

DNS records

DNS (Domain Name System): The system that translates a name people can read, like example.com, into the numeric address computers use. Almost every website problem starts as a DNS problem, which is why it is checked first.
DNS record: A single entry in a domain’s DNS configuration. Each record type answers a different kind of question, and reading them together is how you understand how a domain is set up.
A record: Points a hostname at an IPv4 address, the most common form such as 203.0.113.10.
AAAA record: The same as an A record but for an IPv6 address. Sites that publish only an A record are unreachable over IPv6.
CNAME record: An alias that points one hostname at another rather than at an address, so www.example.com can simply follow wherever example.com points.
MX record: Directs email for a domain to its mail servers. If the MX records are wrong or missing, mail silently fails to arrive even though the website works perfectly.
TXT record: A free-text record used to carry verification data and email authentication policies such as SPF and DMARC.
CAA record: Names which certificate authorities are allowed to issue certificates for the domain. It is a guard rail that stops an unauthorised CA from issuing one.
SOA record: The record that identifies the authoritative nameserver for a domain and carries its timing defaults. It is the anchor the rest of the zone hangs from.
Nameserver: The server that holds the authoritative copy of a domain’s records. If a nameserver is unreachable, the whole domain becomes impossible to look up.
TTL (Time To Live): How long a resolver may cache a DNS answer before asking again. A high TTL means fewer lookups but slower propagation when you change something.
DNS propagation: The delay while a DNS change spreads to resolvers worldwide. Because cached copies expire on their own schedules, different people can still see the old setting for hours after an edit.
DNSSEC: Extra protection that cryptographically signs DNS answers so they cannot be forged in transit. Without it, an attacker who intercepts a lookup can send a visitor to a fake copy of the site.
Resolver: The server that looks up DNS answers on your behalf, often run by your internet provider or by a public service such as Cloudflare or Google. The resolver you use can affect how quickly you see a change.

Email and mail servers

SMTP: The standard way computers send email to each other. Beyond Site can talk to an SMTP server directly to confirm it accepts connections and will start a secure session, which is why a broken mailbox can be diagnosed without sending anything.
IMAP: The standard way a mail program reads the mail already sitting in a mailbox, as opposed to SMTP, which sends it. Beyond Site can be given IMAP details as well as SMTP ones and will check the incoming side opens too, so you find out before an alert fails to arrive that the mailbox was the problem rather than the alert.
Outgoing server / incoming server: The two halves of a mailbox setup. The outgoing (SMTP) server is the one that sends, and Beyond Site needs it to deliver an alert by email. The incoming (IMAP) server is the one that reads, and it is optional — it is only used to confirm the mailbox can be opened.
App password: A long, one-off password a provider issues for a single program, used instead of your normal account password. Gmail, for example, requires one unless you let the program sign in through the provider directly; using your everyday password is usually refused. Beyond Site’s setup screen says which providers need one and points out the exact setting to create it.
Email provider preset: A shortcut that fills in the usual server, port and encryption for a well-known provider — Gmail, Microsoft 365, Yahoo, iCloud, Zoho or Fastmail — so you only have to supply the address and password. Picking one only pre-fills the boxes; you can still change every value, or choose Custom and enter any server you like.
Test email: A message Beyond Site sends to a mailbox of your choosing to prove the setup actually works before you rely on it. Test emails are always free: they are never counted as an alert, because setting email up should not cost you one.
Email diagnostic: A check that connects to your mail servers and reports what happened, without sending anything. It tests the outgoing side and the incoming side separately and says plainly which one failed and what to look at, so a typo in a port number does not look the same as a rejected password.
Email allowed / blocked: Whether Beyond Site may send another email alert right now. Nothing is rationed — email alerts are unlimited and once email is connected the app can send whenever a threshold is crossed.
SMTP banner: The short greeting a mail server says when you connect. It usually names the server, so it is a quick way to confirm you are talking to the machine you think you are.
STARTTLS: A command that upgrades an ordinary mail connection to an encrypted one. Without it, mail can travel in plain text where anyone on the way could read it.
Reverse DNS (PTR): A lookup that goes the other way, from an address back to a name. Many mail servers reject anything sent from an address that has no matching reverse name, so it matters even though it looks obscure.
Open relay: A mail server that will forward email for anyone who asks, including spammers. It is a serious misconfiguration and a fast route onto blocklists. The diagnostic can probe for one, but the probe is off unless you switch it on, since it asks the server to accept mail for an outsider. A fault is only reported when the server actually answers.
SPF (Sender Policy Framework): A DNS record listing which servers are allowed to send email for your domain. Without it, anyone can send mail that claims to come from you.
DKIM (DomainKeys Identified Mail): A digital signature added to outgoing mail so the receiving server can check it was not tampered with on the way and really did come from your domain.
DMARC: The policy that ties SPF and DKIM together: it tells receiving servers what to do when a message fails those checks, and where to send reports. It is what makes the other two enforceable rather than advisory.
Email authentication: The umbrella term for proving an email really came from the domain it claims to. SPF, DKIM and DMARC are the three parts of it.
FQDN: A full, complete machine name, for example mail.example.com rather than just mail. Mail servers expect a full name and may distrust a server that offers only a partial one.

Putting it into practice

See these signals on a real screen, or read what the app checks in full

User Guide

A walkthrough of the app screen by screen, so you can see where each of these results appears and what it is telling you.

Open the guide →

Features

The complete list of what Beyond Site checks, from availability and response time through to certificate chains and DNS records.

See all features →

Notification Guide

Every alert the app can send, shown as it appears on your phone, with what it means and what to do about it.

See the alerts →

Missing a term?

If something the app reported is not explained here, tell us and we will add it. That is how this page gets better.

Contact support →