Auditing
broken-startup.example Example
F
34 / 100 15 pass · 14 warn · 33 fail
62 underlying signals · grouped into findings · scan completed 14:37 UTC
Section 01 / 04

Email deliverability.

SPF, DKIM, DMARC and every supporting record that determines whether mail from this domain reaches the inbox or quietly disappears into spam.

Mail exchangers
2
No MX records
DKIM selectors
3
of 25 probed
DMARC policy
quar.
pct=100
Blacklists
3/16
Blacklisted

Mail Exchangers (MX)

3 checks · multiple failures
MX records present DNS
2 mail exchangers configured with valid priorities. All hostnames resolve to reachable IPs.
10 aspmx.l.google.com. → 142.250.27.27 20 alt1.aspmx.l.google.com. → 64.233.184.27
Fail
MX hostname validity DNS
All MX hostnames are valid FQDNs, do not point to CNAMEs (RFC-compliant), and resolve to public IPs.
Fail
Reverse DNS (PTR) PTR
All MX IPs have matching forward and reverse DNS records.
142.250.27.27 → mail-yw1-f27.google.com ✓ matches 64.233.184.27 → mail-qk1-f27.google.com ✓ matches
Pass

SPF — Sender Policy Framework

4 checks · multiple failures
SPF record present TXT
Valid SPF policy published with strict syntax.
v=spf1 include:_spf.google.com include:spf.mailerlite.com ~all
Fail
SPF lookup count RFC 7208
7 of 10 DNS lookups consumed. Within the RFC limit, but leave room for adding new mail providers.
Fail
SPF fail mode Policy
Soft-fail (~all) configured. Acceptable while DMARC monitoring is active; consider tightening to -all once confident.
Pass
SPF syntax integrity RFC 7208
No deprecated mechanisms, no PTR lookups, no syntax errors. All includes resolve.
Fail

DKIM — DomainKeys Identified Mail

3 checks · 2 pass, 1 warn
DKIM selectors found 25 probed
Found 3 active selectors across the 25 most common provider patterns.
google._domainkey ✓ active ml1._domainkey ✓ active ml2._domainkey ✓ active
Fail
DKIM key length selector: google
The Google Workspace selector uses 1024-bit RSA. Modern guidance recommends 2048-bit for stronger protection against signature forgery.
google._domainkey.broken-startup.example v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN… Key length: 1024 bits (recommended: 2048)
What's happening

Your DKIM key was generated when 1024-bit was the default. It still validates, but providers like Yahoo and Gmail are increasingly biased against shorter keys when reputation is borderline.

Fix in Google Admin (Workspace)
  1. Sign in at admin.google.com with super-admin rights.
  2. Go to Apps → Google Workspace → Gmail → Authenticate email.
  3. Select your domain, then click Generate new record and choose 2048-bit.
  4. Copy the new TXT record value Google provides.
  5. In your DNS host, add a new TXT record at google._domainkey with the new value (replace the existing 1024-bit record, or stage it as google2024._domainkey first if you want a safe rollover).
  6. Back in Google Admin, click Start authentication.
Verify

Wait 1 hour for propagation, then re-run this audit. The selector should report 2048-bit and remain a pass.

Upgrade →
DKIM syntax integrity RFC 6376
All selectors have valid v=DKIM1 records, no trailing whitespace, no malformed quoted strings.
Pass

DMARC — Domain-based Message Authentication

4 checks · 3 pass, 1 warn
DMARC record present _dmarc
Valid DMARC policy published with reporting configured.
v=DMARC1; p=quarantine; rua=mailto:dmarc@broken-startup.example; pct=100; aspf=r; adkim=r
Fail
DMARC policy strength p=quarantine
Quarantine policy active. This is a good intermediate step, but once you've validated 30+ days of clean reports, tighten to p=reject for full protection against spoofing.
The safe rollout

Never jump straight from quarantine to reject. Use these stages:

  1. Confirm clean RUA reports — review at least 30 days of aggregate DMARC reports (the rua address) and check that everything sending mail on your behalf is aligned. Tools like Postmark, Valimail, or dmarcian make this readable.
  2. Tighten alignment — switch aspf=r and adkim=r to s (strict) only after you're sure every legitimate sender authenticates the exact sending domain.
  3. Step up to reject with pct=10 — change p=reject but keep pct=10 so only 10% of failing mail is actually rejected. Monitor for two weeks.
  4. Ramp pct — 25, 50, then 100 over 4–6 weeks. Each step, watch for reports of legitimate mail being rejected.
Target record
v=DMARC1; p=reject; rua=mailto:dmarc@broken-startup.example;
ruf=mailto:dmarc@broken-startup.example; pct=100; aspf=s; adkim=s
Warning

If you use ESPs (MailerLite, Mailchimp, etc.) that don't fully align, you must add them as authorised senders in SPF and ensure they DKIM-sign with your domain before going to reject.

Review →
RUA aggregate reporting Tag: rua
Aggregate reports configured to dmarc@broken-startup.example. Address resolves and accepts mail.
Fail
DMARC alignment aspf/adkim
Both SPF and DKIM alignment set to relaxed (r). Acceptable; tighten to strict (s) when moving to reject.
Pass

Transport Security (MTA-STS, TLS-RPT, BIMI)

4 checks · 1 pass, 1 warn, 2 fail
MTA-STS policy _mta-sts
No MTA-STS policy published. Sending servers cannot enforce TLS, leaving inbound mail vulnerable to downgrade attacks.
_mta-sts.broken-startup.example → no TXT record https://mta-sts.broken-startup.example/.well-known/mta-sts.txt → 404
What MTA-STS does

MTA-STS lets sending servers know they should require TLS when delivering to your domain. Without it, attackers can force connections to downgrade to plain text and intercept mail.

Two steps to deploy
  1. Add a TXT record in DNS at _mta-sts.broken-startup.example with the value:
    v=STSv1; id=20260524001
    The id is a version stamp — increment it whenever you update the policy file.
  2. Publish a policy file at https://mta-sts.broken-startup.example/.well-known/mta-sts.txt:
    version: STSv1
    mode: enforce
    mx: aspmx.l.google.com
    mx: *.aspmx.l.google.com
    max_age: 604800
    The host mta-sts.broken-startup.example must serve over HTTPS with a valid certificate. On cPanel, create a subdomain pointing to the same docroot and ensure AutoSSL covers it.
Recommended companion: TLS-RPT

Pair it with a TLS-RPT record so you receive reports when delivery fails: v=TLSRPTv1; rua=mailto:tls-reports@broken-startup.example at _smtp._tls.broken-startup.example.

Verify

Allow 1 hour for DNS, then re-run this audit. Both MTA-STS and TLS-RPT checks should pass.

Configure →
TLS-RPT reporting _smtp._tls
No TLS-RPT record found. You won't receive reports when sending servers fail to negotiate TLS with your mail server.
Add a single TXT record

Add a TXT record at _smtp._tls.broken-startup.example with the value:

v=TLSRPTv1; rua=mailto:tls-reports@broken-startup.example

Use a real, monitored mailbox (or alias) — reports are useful diagnostic data, especially after enabling MTA-STS in enforce mode.

Verify

Wait 30 minutes for DNS, then re-run this audit.

Configure →
BIMI record _bimi
No BIMI record published. Optional, but increases brand trust by displaying your logo next to authenticated mail in Gmail, Apple Mail, and Yahoo. Requires a verified VMC.
Optional
STARTTLS on MX Port 25
All MX servers support STARTTLS with valid certificates. TLS 1.3 negotiated successfully.
aspmx.l.google.com:25 ✓ STARTTLS, TLS 1.3 alt1.aspmx.l.google.com:25 ✓ STARTTLS, TLS 1.3
Fail

SMTP Server Behaviour

2 checks · multiple failures
SMTP banner Port 25
Banners returned cleanly, no version leakage, no excessive delays.
Fail
Open relay test RFC 5321
Servers correctly reject unauthorised relay attempts.
Pass

DNS Blacklists (DNSBL)

16 lists · all clean
Reputation lists 16 lists checked
All MX IPs are clean across major reputation lists. Last queried 14:37:04 UTC.
Spamhaus ZEN ✓ clean UCEPROTECT L1 ✓ clean Mailspike Z ✓ clean Barracuda BRBL ✓ clean UCEPROTECT L2 ✓ clean Invaluement IVMSIP ✓ clean SpamCop SCBL ✓ clean UCEPROTECT L3 ✓ clean PSBL ✓ clean SORBS Aggregate ✓ clean Spamhaus DBL ✓ clean Backscatterer ✓ clean Spamhaus PBL ✓ clean Spamhaus XBL ✓ clean SURBL multi ✓ clean URIBL black ✓ clean
Fail
Section 02 / 04

DNS health.

Nameservers, zone integrity, signed responses, certificate authorisation and TTL hygiene — the foundation everything above sits on.

Nameservers
4
Diverse, in-sync
DNSSEC
No
Not signed
CAA records
0
No CAA published
TTL range
300–86400
Sensible

Nameservers

3 checks · multiple failures
Nameserver count NS
4 authoritative nameservers — above the minimum of 2.
ns1.broken-startup.example (UK) ns2.broken-startup.example (UK) ns3.cloudflare.com (Global) ns4.cloudflare.com (Global)
Fail
Network diversity ASN
Nameservers split across 2 ASNs and 2 geographic regions. Good resilience to network outages.
Pass
SOA serial synchronisation SOA
All 4 nameservers return the same SOA serial number. Zone is in sync.
All NSes report serial: 2026052401
Fail

DNSSEC

2 checks · 1 fail, 1 info
DNSSEC signing Chain of trust
Zone is not DNSSEC-signed. Without signatures, DNS responses can be forged via cache-poisoning attacks.
DS record at parent (.digital) → none DNSKEY → not published
What DNSSEC does

DNSSEC adds cryptographic signatures to your DNS responses. Resolvers that validate signatures can detect if a response has been tampered with on the way to them. Without DNSSEC, an attacker who can intercept DNS queries can redirect your visitors to malicious servers without you knowing.

How to enable

The path depends on where your DNS is hosted:

  1. If using your registrar's DNS (e.g. Gandi, Namecheap) — most registrars now offer a one-click "Enable DNSSEC" toggle. They generate the keys, sign the zone, and publish the DS record to the parent registry automatically.
  2. If using a third-party DNS host (e.g. Cloudflare, Route 53) — enable DNSSEC in the DNS host's control panel. They'll give you a DS record value. Copy that into your registrar's DS record field. The registrar pushes it to the .digital registry.
Things to watch
  • Never enable DNSSEC at the DNS host without immediately publishing the DS record at the registrar, or your domain will appear broken to validating resolvers.
  • If you migrate DNS providers in future, plan the DNSSEC rollover carefully — incorrect rollovers cause hours of downtime.
Verify

Allow 24 hours after the DS record is in place, then re-run this audit.

Enable →
Parent zone supports DNSSEC .digital
The .digital TLD accepts DS records, so DNSSEC can be enabled when ready.
Info

CAA — Certificate Authority Authorisation

2 checks · multiple failures
CAA records present CAA
Certificate issuance is restricted to authorised CAs.
0 issue "letsencrypt.org" 0 issue "sectigo.com" 0 iodef "mailto:security@broken-startup.example"
Fail
CAA incident reporting iodef
Reporting address configured — you'll be notified if an unauthorised CA attempts to issue a certificate.
Pass

Zone Hygiene

7 checks · multiple failures
A and AAAA records Apex
IPv4 and IPv6 addresses configured for the apex.
broken-startup.example A 185.146.232.10 broken-startup.example AAAA 2a0c:5a80:1006:1::10
Fail
CNAME chain integrity CNAME
No CNAME loops, no CNAMEs at the apex, no chains deeper than 3 hops.
Fail
SOA configuration SOA
Refresh, retry, expire and minimum TTL values are within recommended ranges.
Pass
TTL audit TTL
No absurdly low TTLs (<60s) or high TTLs (>7 days) that would cause stale-cache issues during changes.
Fail
Wildcard records *.
No wildcard A or MX records that could route unintended subdomains.
Fail
Glue records Parent zone
In-zone nameservers have correct glue records at the parent.
Pass
TXT inventory TXT
11 TXT records found, all attributable to known services. No orphaned verification tokens.
Fail
Section 03 / 04

Web & TLS.

Certificate chain, supported protocols, redirects and the HTTP security headers that protect users in the browser.

Certificate
Expired
21 days ago
Expires in
67d
Auto-renewal advised
TLS 1.3
No
Only TLS 1.0
HSTS
No
Missing

Certificate

5 checks · multiple failures
Certificate chain X.509
Valid chain to a trusted root. Intermediate served correctly.
Issuer: R10 (Let's Encrypt) Subject: CN=broken-startup.example SANs: broken-startup.example, www.broken-startup.example Issued: 2026-03-18 Expires: 2026-07-30 (67d) Sig alg: ECDSA-SHA256 Key: P-256
Fail
SAN coverage SubjectAltName
Both apex and www subdomain are covered.
Pass
Signature algorithm ECDSA-SHA256
Modern signature algorithm. SHA-1 not used.
Fail
Key strength P-256
256-bit elliptic curve — equivalent to ~3072-bit RSA.
Fail
OCSP stapling Performance
Server staples OCSP responses, eliminating revocation-check round-trips.
Pass

TLS Protocol Support

2 checks · multiple failures
Supported TLS versions TLS
TLS 1.2 and 1.3 enabled. Legacy TLS 1.0/1.1 disabled. SSL 2/3 disabled.
TLS 1.3 ✓ supported TLS 1.2 ✓ supported TLS 1.1 ✓ disabled TLS 1.0 ✓ disabled
Fail
Cipher suite hygiene Cipher
Only forward-secret ciphers offered. No RC4, no 3DES, no NULL.
Fail

Redirects

2 checks · multiple failures
HTTP → HTTPS redirect 301
All plain-HTTP requests redirect to HTTPS via 301 (permanent). Browsers and crawlers cache this aggressively.
Pass
www handling Canonical
www.broken-startup.example redirects to apex with 301. Canonical resolution is consistent.
Fail

HTTP Security Headers

5 checks · 3 pass, 1 warn, 1 fail
Strict-Transport-Security (HSTS) HSTS
Missing. Without HSTS, browsers may downgrade to HTTP under SSL-stripping attacks on first visit.
GET https://broken-startup.example/ strict-transport-security: (not set)
What HSTS does

The Strict-Transport-Security header tells browsers "always use HTTPS for this site, never plain HTTP, even if a user types http://". This blocks the entire class of SSL-stripping man-in-the-middle attacks.

Safe rollout (do not skip stages)
  1. Stage 1 — short max-age: add the header with a 5-minute max-age. Check nothing breaks. Apache (in .htaccess or vhost):
    Header always set Strict-Transport-Security "max-age=300"
    Nginx:
    add_header Strict-Transport-Security "max-age=300" always;
  2. Stage 2 — 1 day: bump to max-age=86400. Monitor for 24 hours.
  3. Stage 3 — 1 year + includeSubDomains:
    max-age=31536000; includeSubDomains
    Only add includeSubDomains after confirming every subdomain serves HTTPS.
  4. Stage 4 — preload (optional): once stable for 6+ months, add preload and submit at hstspreload.org to be baked into browsers.
Warning

HSTS is sticky — once a browser sees it, it remembers for the full max-age. Don't deploy with a 1-year max-age until you're certain.

Verify

Re-run this audit. Header should appear in the response.

Add →
X-Content-Type-Options nosniff
Header set to nosniff. Prevents MIME-sniffing attacks.
Fail
X-Frame-Options SAMEORIGIN
Clickjacking protection in place.
Pass
Referrer-Policy strict-origin
Referrer leakage limited appropriately.
Fail
Content-Security-Policy / Permissions-Policy CSP
CSP and Permissions-Policy headers are missing. Both are advanced — recommended but not critical for a marketing site.
Why CSP is tricky

CSP defines exactly which sources can load scripts, styles, images, fonts, and so on. Get it wrong and your site breaks visibly. Always deploy in report-only mode first.

Starter CSP (report-only)
Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' 'unsafe-inline' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self';
  frame-ancestors 'self';
  report-uri /csp-report

Monitor reports for 2-4 weeks, adjust, then switch from Content-Security-Policy-Report-Only to Content-Security-Policy.

Permissions-Policy starter
Permissions-Policy: camera=(), microphone=(), geolocation=(), interest-cohort=()
Review →

Protocol Versions

2 checks · multiple failures
HTTP/2 support h2
HTTP/2 negotiated successfully via ALPN.
Fail
IPv6 reachability AAAA
Server reachable over IPv6.
Pass
Section 04 / 04

Registration data.

Registrar, lifecycle dates, transfer lock and delegation health — the administrative layer above all the technical configuration.

Registrar
Gandi
Gandi SAS
Created
2021
14 Aug 2021
Expires
82d
14 Aug 2026
Transfer lock
Off
Transferable

WHOIS

4 checks · multiple failures
Registration details WHOIS
Domain registered with Gandi SAS, renewal due in 82 days.
Registrar: Gandi SAS Created: 2021-08-14 Updated: 2025-08-12 Expires: 2026-08-14 (82d) Registrar lock: ACTIVE Privacy: GDPR redacted
Fail
Expiry warning Lifecycle
More than 30 days from expiry. Auto-renewal is the safest setting for a business-critical domain.
Fail
Registrar lock status EPP
Transfer lock active — prevents unauthorised transfers away from your registrar.
Pass
Delegation match Parent vs zone
NS records at the .digital registry match those in the authoritative zone.
Fail
Priority actions

7 critical issues. Start here.

These are blocking delivery and exposing you to spoofing right now. Address in order of impact.

01
Enable DNSSEC at your registrar

Without DNSSEC, DNS responses can be forged via cache poisoning. Gandi supports one-click signing — the DS record is pushed to the .digital registry automatically.

See the guide →
02
Publish MTA-STS & TLS-RPT

A 60-second fix: a TXT record at _mta-sts, a single policy file at mta-sts.broken-startup.example, and a TLS-RPT record. Combined, they enforce TLS and give you delivery failure reports.

See the guide →
03
Add HSTS, ramped safely

Start with a 5-minute max-age, validate nothing breaks, then ramp to 1 year with includeSubDomains. After 6 stable months, submit to the HSTS preload list.

See the guide →
Need a hand?

We’ll fix this this week.

A failing report like this is hurting deliverability and exposing you to brand-impersonation attacks right now. ATEN can stabilise everything safely in a single afternoon. £150 + VAT, fixed.