Before a call, a reviewer often runs quick public checks on your domain: whether your email is authenticated, whether your site uses modern TLS settings, whether a security contact file exists, and whether you publish a clear security page. These take minutes and shape first impressions.
Why these checks happen
A reviewer facing a long list of vendors has little time. Public signals work as a cheap first filter. They also hint at operational discipline: a company that cannot keep its own email authenticated may struggle with larger controls. That inference is not always fair, but it is common, so it is worth ten minutes of your time.
The five checks, and how to pass them
- Email authentication. SPF, DKIM and DMARC records on your sending domains. RFC 7489 describes DMARC as a mechanism by which a mail originating organization can express domain level policies for message validation, disposition and reporting. A published policy, with reporting turned on, tells reviewers you control who sends as you. See add a SaaS sender to your domain without breaking DMARC before changing records.
- TLS configuration. Valid certificate, no expired chain, modern protocol versions, and redirect from plain HTTP.
- Security contact file. RFC 9116 defines the security.txt file, served from the well known path
/.well-known/security.txt, so researchers know how to report a vulnerability. Include a contact, an expiry date and a link to your policy. See what is a security.txt file and why should a software vendor have one. - A findable security page. One URL with your practices, subprocessor list, contact path and any attestation status stated accurately. The post on what security reviewers check first on your trust page lists what they look for.
- Disclosure policy. A short statement on how to report issues and what researchers can expect. See why do enterprise buyers ask for a vulnerability disclosure policy.
A ten minute self audit
- Send a test message from each domain that sends mail for you and read the authentication results in the headers.
- Open your site in a private window and check the certificate details.
- Fetch your security.txt URL and check the expiry date is in the future.
- Search for your own company name plus "security" and read the first results as a stranger would.
- Check your status page and your security page agree about what you offer.
What to avoid
Do not copy badges or claims you cannot support. If a page says certified and the buyer asks for the certificate, a gap hurts more than silence would. State what you hold in exact words, such as "SOC 2 Type 1 report available under NDA" only if true, and "audit in progress" only if it is.
Keep it current
Public signals decay. Certificates expire, security.txt expiry dates pass, and a marketing tool gets added that sends mail without DKIM. Put the checks on a quarterly calendar, owned by one named person.
A warning on scoring services: some buyers use outside in rating services that grade a domain automatically. These can be wrong. If a rating contains an error, ask the buyer how to dispute it and give them evidence, instead of arguing.
Quick check
Do we need DMARC at enforcement to pass a review?
Not always, but a published policy with reporting is a good start. Move toward enforcement once you have confirmed all legitimate senders are aligned.
Is security.txt mandatory?
No. It is a published standard that helps researchers reach you. Many reviewers treat its presence as a small positive sign.
Safeguard's asset discovery can help you list the domains and services you operate, so checks like these cover everything you own.
Sources
Last reviewed: 19 October 2026.
