DNS and Domain Validation Checklist: MX, SPF, DKIM, DMARC, SSL, and WHOIS

Overview

Domain validation is not one test. A domain can resolve correctly in a browser while having broken mail records, an expired certificate, unclear ownership data, or an authentication policy that does not match the systems sending email. Treat each layer separately and evaluate the result against the intended use.

A practical validation record should include the domain or subdomain tested, the resolver or validation service used, the timestamp, the record values observed, and the expected outcome. This makes it easier to distinguish a configuration problem from a caching or propagation delay.

• Ownership: Confirm that the organization controls the domain and can make the required DNS or registrar changes.
• DNS resolution: Check that the relevant A, AAAA, CNAME, MX, TXT, and other records resolve as intended.
• Email authentication: Validate SPF, DKIM, and DMARC alignment for every authorized sending path.
• TLS: Confirm that certificates are valid for the hostname, trusted by expected clients, and renewed before expiry.
• Registration data: Use WHOIS or RDAP data as a supporting ownership and lifecycle signal, not as the only proof of control.

A DNS validation tool or domain validation API can make these checks repeatable across many domains and subdomains. Automation should report the underlying observation, not only a pass or fail label, so an engineer can investigate the result.

Checklist by scenario

1. Validating domain ownership

1. Confirm the exact domain and hostname involved. The apex domain, www, a mail subdomain, and an application subdomain may have different records and owners.
2. Check the registrar or RDAP record for the domain name, registrar status, expiration information where available, and relevant nameservers.
3. Use a verification method that requires control of the domain, such as adding a specified DNS TXT record or serving a file from the requested hostname.
4. Query the authoritative nameservers to confirm that the verification value is published in the correct zone.
5. Remove temporary verification records when the responsible platform no longer needs them, while retaining an internal record of what was changed.

Registration data can be incomplete, redacted, or affected by privacy services. For a deeper treatment of ownership evidence, see WHOIS, RDAP, and Domain Ownership Validation.

2. Checking DNS resolution and delegation

1. Confirm that the domain uses the intended authoritative nameservers at the registrar.
2. Query the authoritative server directly, then compare the answer with results from one or more recursive resolvers.
3. Check the record type required by the service. An A record points to an IPv4 address, an AAAA record to IPv6, and a CNAME aliases a hostname rather than an IP address.
4. Look for conflicting records, unexpected wildcards, stale endpoints, and CNAME chains that lead to retired infrastructure.
5. For delegated subdomains, verify the NS records and glue or delegation details at the parent zone.
6. Review DNSSEC status when it is enabled. A stale or incorrect chain of trust can make otherwise correct records fail validation for validating resolvers.

Expected result: the authoritative answer matches the intended service, and recursive answers converge after the relevant TTL and caching period. If answers differ, record which resolver produced each result before changing the zone.

3. Validating mail delivery with an MX record checker

1. Query MX records for the exact sending or receiving domain.
2. Confirm that each listed mail exchanger is an intentional destination and resolves to reachable A or AAAA records.
3. Check priority values and remove entries that point to decommissioned systems.
4. Verify that the receiving service accepts mail for the domain and that its hostname certificate and reverse-DNS expectations are configured where required.
5. Do not assume that an absent MX record has the same meaning as a working mail configuration. Document the intended behavior for the domain.

An MX record checker identifies DNS routing; it does not prove mailbox existence or successful delivery. For broader deliverability checks, pair this review with the guidance in Email Verification Metrics That Actually Matter.

4. Checking SPF, DKIM, and DMARC

1. SPF checker: Find the TXT record beginning with v=spf1. Confirm that every legitimate sender is represented through the appropriate mechanism or included service.
2. Check for multiple SPF records. A domain should publish one coherent SPF policy rather than several separate records.
3. Review nested includes and DNS lookups. Remove obsolete providers and keep the policy understandable enough to maintain.
4. DKIM checker: Obtain the selector used by the sending system and query the corresponding selector TXT record, such as selector._domainkey.example.com.
5. Confirm that the published key is complete and that the sending system signs with the same selector and domain expected by the recipient.
6. DMARC checker: Query _dmarc.example.com and confirm that the policy reflects the organization’s intended monitoring or enforcement stage.
7. Review alignment between the visible From domain and the domains authenticated by SPF or DKIM.

Expected result: authorized senders pass the intended authentication checks, unauthorized paths are visible through reporting or policy behavior, and changes are documented before a stricter policy is introduced.

5. Validating SSL and TLS certificates

1. Test every public hostname, not only the apex domain. A certificate for example.com does not automatically cover every subdomain.
2. Confirm that the certificate is within its validity period and that the hostname appears in the certificate’s names.
3. Check the complete certificate chain from the server to a trusted root as seen by the clients that matter to the service.
4. Verify that the server presents the expected certificate when multiple sites share an IP address and rely on SNI.
5. Check redirects and mixed-content dependencies if the site loads resources from other hostnames.
6. Confirm that renewal is automated or assigned to an owner with a tested reminder and deployment process.

Certificate validation should be performed against the actual production hostname and from a client or service representative of the intended users. A certificate can be valid while the application remains unavailable because of DNS, routing, firewall, or server configuration.

What to double-check

Before marking a domain as validated, review the boundaries of each result:

• Propagation versus failure: A resolver may return cached data after a change. Compare authoritative and recursive answers instead of repeatedly refreshing one tool.
• Apex versus subdomain: Policies and certificates are hostname-specific. Validate the names used by applications, email, APIs, and redirects.
• TXT record purpose: A zone may contain records for SPF, DKIM, DMARC, ownership verification, and other services. Preserve unrelated values when editing.
• Third-party dependencies: An included SPF provider, CNAME target, certificate issuer, or hosted application can change independently. Track those dependencies.
• DNS as a security boundary: Remove abandoned records that point to old cloud resources. The Subdomain Takeover Prevention Checklist can help with this review.
• Evidence and privacy: Store only the validation data needed for operations, especially when logs include domain ownership contacts, user addresses, or verification tokens. See GDPR and CCPA Considerations for Validation APIs for related planning questions.
• Automation behavior: If a domain validation API powers an onboarding or deployment workflow, define whether a timeout, SERVFAIL, missing record, or policy mismatch should block the action or send it to manual review.

For repeatable checks, return structured fields such as status, record_type, observed_value, expected_condition, checked_at, and error_category. This is more useful than a single Boolean result when a team needs to troubleshoot or audit a decision.

Common mistakes

• Editing DNS at the wrong provider because the registrar and authoritative DNS host are different.
• Adding a second SPF TXT record instead of merging authorized sending mechanisms.
• Testing only the website while overlooking MX, DKIM selectors, DMARC, or application subdomains.
• Assuming a successful DNS lookup proves that the destination service is healthy.
• Replacing a DNS record without preserving verification tokens used by another service.
• Using WHOIS or RDAP alone to prove operational control of a domain.
• Deploying a certificate for the wrong hostname or omitting an intermediate certificate.
• Making several changes at once, which makes the eventual cause of improvement or failure difficult to identify.
• Failing to record the previous value, change owner, intended TTL, and rollback plan.

When to revisit

Run the relevant parts of this checklist before a domain launch, mail-provider migration, certificate renewal, DNS-host migration, or major application release. Repeat it before seasonal planning cycles when traffic, sending volume, or support coverage may change. Recheck after changing hosting, cloud load balancers, email vendors, identity providers, or any service represented by a CNAME, MX, TXT, or DKIM record.

Set a recurring review for domains that support important customer, authentication, or transaction workflows. The interval should reflect operational risk and the frequency of infrastructure changes rather than a universal calendar rule. Trigger an additional review when monitoring reports SERVFAIL responses, certificate warnings, unexpected mail failures, new DNS records, or an ownership change.

To make the process actionable, assign an owner for each domain, keep an inventory of authoritative nameservers and critical records, and save the last successful validation result. When a check fails, first identify whether the problem is delegation, record content, caching, service health, certificate deployment, or authorization. Then change one layer at a time, verify from the authoritative source and an independent resolver, and document the final state.

For teams exposing validation checks through an API, protect the endpoint with clear rate limits and predictable error handling. The guide to API Rate Limiting and Validation covers the operational considerations that help verification workflows remain dependable as usage grows.