> For the complete documentation index, see [llms.txt](https://shellzerox.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shellzerox.gitbook.io/docs/security-scanning/dns-and-email-security.md). # DNS & Email Security Understand how DNS configuration and email authentication checks help identify potential domain security weaknesses. *** ### Overview Domain Name System (DNS) records help direct internet traffic and define how domain-related services operate. Email authentication records help receiving mail servers evaluate whether messages claiming to originate from a domain are legitimate. SHELLZERO X examines selected publicly observable DNS and email security configurations to help identify potential weaknesses and misconfigurations. ### DNS Security DNS security checks provide insight into how a domain is configured and whether certain protective mechanisms are present. | Check | Purpose | Potential Concern | | ----------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | DNS Records | Review publicly available domain configuration. | Incorrect or inconsistent records may disrupt services. | | DNSSEC | Check for DNSSEC-related configuration indicators. | Missing DNSSEC may leave DNS responses without this additional validation mechanism. | | CAA Records | Review Certificate Authority Authorization records. | Missing or overly broad restrictions may provide less control over certificate issuance. | | Subdomain Records | Examine discovered subdomains and associated information. | Unmaintained or misconfigured subdomains may introduce exposure. | The checks available for a domain depend on the records that can be discovered and the platform's current scanning capabilities. ### Email Authentication Email authentication helps protect domains against spoofing and supports receiving mail servers in evaluating message legitimacy. | Mechanism | Purpose | Recommended Review | | --------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | SPF | Specifies which mail servers are authorized to send email for a domain. | Check the record for accuracy, permitted senders, and unnecessary authorization. | | DKIM | Uses cryptographic signatures to help verify message integrity and domain association. | Confirm that the required public keys and signing configuration are published correctly. | | DMARC | Defines how receiving systems should handle messages that fail SPF and DKIM alignment checks and can enable reporting. | Review policy, alignment, and reporting configuration. | A record's presence does not automatically mean that the overall email configuration is correct or effective. ### Understanding Common Findings **Missing or invalid SPF record** A missing or incorrectly configured SPF record may make it harder for receiving systems to identify authorized senders. Review the domain's legitimate sending services before changing the record. **Missing DKIM configuration** If DKIM is not configured for a sending service, messages from that service may lack DKIM signatures. Confirm the provider's requirements and publish the appropriate public key. **Weak DMARC policy** A monitoring-only DMARC policy can help gather information about email authentication but does not itself request rejection or quarantine of failing messages. Any policy change should account for legitimate sending services to avoid disrupting email delivery. **Missing DNSSEC** Without DNSSEC validation, a domain may not benefit from DNSSEC's additional protection against certain forms of DNS data manipulation. Whether to deploy DNSSEC depends on registrar, DNS provider, and infrastructure support. **Missing CAA records** CAA records can restrict which certificate authorities may issue certificates for a domain. Review the certificate authorities used by the organization before adding restrictions. ### Recommended Review Process 1. Run the available DNS and email security checks. 2. Review the records and findings reported for the domain. 3. Confirm the current configuration with the authoritative DNS provider. 4. Identify all legitimate email senders before changing SPF, DKIM, or DMARC. 5. Test proposed changes where possible before deploying them. 6. Recheck the configuration after changes have propagated. DNS and email configuration changes can affect website availability, certificate issuance, and mail delivery. Make changes carefully and retain a record of the original configuration. ### Limitations * DNS records can change, and scan results may not reflect every recent update. * Some email authentication configurations require provider-specific verification. * The presence of a record does not prove that the corresponding security mechanism is functioning correctly. * DNS and email checks do not guarantee protection against phishing, spoofing, or other email-related attacks. Use SHELLZERO X findings as an initial assessment and verify important configuration changes with your DNS and email service providers. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://shellzerox.gitbook.io/docs/security-scanning/dns-and-email-security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.