A site can load perfectly while its email configuration leaves room for impersonation or breaks password-reset delivery. These problems live in domain records and sending services, so a visual website check will not reveal them. The practical goal is to protect the domain without rejecting legitimate business mail.
Sitelemetry's email DNS module queries MX, TXT, DMARC, CAA and the MTA-STS discovery record for the target hostname. It reports observed policy signals and retains lookup errors. Use the result to investigate the mail domain you actually send from; an audit of www.example.com is not automatically a complete assessment of example.com's email configuration.
What this audit covers
What can be measured
- Observed MX, SPF TXT, _dmarc TXT, CAA and _mta-sts discovery records for the queried hostname.
- SPF permissive or neutral endings, a direct count of DNS-querying mechanisms, and DMARC monitoring policy.
- Supported successful policy checks and DNS lookup errors recorded as evidence.
What it cannot prove
- The native module does not send test messages, inspect inbox placement or verify every DKIM selector.
- Its direct SPF mechanism count does not recursively expand all includes; a low count is not proof of compliance with the lookup limit.
- Seeing an MTA-STS discovery TXT record does not prove the HTTPS policy file or mail-server TLS works.
Scan an authorized, verified target and inspect the modules actually enabled for your plan and profile. These checks examine public configuration; connecting a mail provider or proving delivery requires separate work.
Build the sender inventory before changing DNS
List every legitimate sender: employee mail, support desk, transactional email, invoicing, marketing and any legacy service still active. Record the visible From domain, envelope sender, DKIM signing domain and responsible owner. Ask each provider for its current required DNS records; do not reuse a guessed include value from another company's configuration.
Keep the audit hostname, query result and observation time in your ticket. A DNS timeout is not the same as an authoritative statement that a record is absent. Recheck unexpected results with your DNS provider and allow for caching. MX describes mail reception; a domain can send mail without publishing MX, so missing-MX silence is not proof of secure sending.
Interpret policy findings proportionately
| Observation | Typical priority | Why it matters |
|---|---|---|
| SPF ends in +all | High | The policy authorizes any sender |
| No SPF or DMARC observed for a mail domain | Usually medium; verify lookup and domain context | Important anti-impersonation policy is absent |
| SPF lookup-limit warning | Medium | Evaluation can fail instead of authenticating senders |
| DMARC p=none | Low; may be intentional during rollout | Monitoring without requested quarantine or rejection |
| No CAA or MTA-STS discovery record | Usually low | Additional policy hardening to investigate |
A policy weakness is not evidence that forged mail reached an inbox. Likewise, a passing record-presence check is not a delivery guarantee. Prioritize domains used for login links, invoices and customer support because misuse can directly damage trust.
Fix SPF without losing valid senders
SPF evaluates the connecting sender against the envelope domain's policy; it does not directly authenticate the visible From address. Publish one coherent SPF policy for a domain, with only the providers that genuinely send on its behalf. Avoid +all. Choose the final policy after testing legitimate sources.
The protocol limits DNS-querying terms during evaluation to ten, including work caused by nested includes and redirects. Sitelemetry's direct-text count is an early warning, not a recursive evaluation. Check the full chain with provider guidance. Remove retired senders and unnecessary mechanisms first. Blindly replacing provider includes with fixed IP addresses can create a maintenance problem when the provider changes its infrastructure.
Move DMARC from observation to enforcement safely
DMARC connects the visible From domain to aligned SPF or DKIM authentication. A message can pass DMARC through either aligned mechanism; both are not universally required. DKIM uses provider-specific selectors, so a public scan cannot safely guess that every signing key is configured.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comThis is an illustrative monitoring policy. Replace the mailbox with an address you control and can process; an external reporting destination may need DNS authorization. Examine reports and test every legitimate stream, including forwarding effects. Fix alignment before moving to quarantine or reject. A staged rollout is better than enforcing rejection on an incomplete sender inventory and losing password resets or invoices.
CAA and MTA-STS answer different questions
CAA expresses which certificate authorities may issue for a domain. Match any restriction to the actual certificate providers, including CDN-managed certificates and wildcard requirements. A careless restriction can disrupt renewal. Missing CAA is a hardening opportunity, not proof that an attacker already has a certificate.
MTA-STS lets participating senders apply a published TLS policy to inbound mail delivery. The discovery TXT record is only one part: the HTTPS policy file, its MX patterns and the mail servers' certificates must agree. Test the complete setup before enforcement. This mechanism is not the same as website HTTPS, and absence of its TXT record does not prove every mail connection is unencrypted.
Validate records and real delivery
- Save existing DNS values and document the owner of each sending service.
- Publish the reviewed change through the authoritative DNS provider and confirm the queried hostname.
- Recheck the records after relevant cache lifetimes; rerun the same audit scope.
- Send controlled messages through each legitimate service to test accounts you own.
- Inspect recipient authentication results and DMARC reports, then confirm password resets, invoices and support replies arrive.
Keep policy checks separate from deliverability monitoring. Reputation, recipient filtering and message content can still affect delivery when authentication succeeds. Document any DNS errors, selectors not evaluated and mail services not tested so a green summary does not erase those gaps.
Common questions
Does Sitelemetry verify that all of our email reaches the inbox?
No. Public DNS checks assess configuration signals. Real delivery requires controlled messages, recipient-side authentication results and provider or mailbox data.
Is DMARC p=none a broken configuration?
It can be an intentional monitoring stage. It does not request enforcement, so review reports and complete alignment before tightening the policy.
Can a passing SPF check still exceed the lookup limit?
Yes. The native check counts visible mechanisms rather than recursively evaluating every include. Validate nested provider policies before claiming the full SPF evaluation fits the limit.
Sources & further reading
- RFC 7208: Sender Policy Frameworkwww.rfc-editor.org
- RFC 9989: DMARCwww.rfc-editor.org
- RFC 8659: DNS Certification Authority Authorizationwww.rfc-editor.org
- RFC 8461: SMTP MTA Strict Transport Securitywww.rfc-editor.org
- RFC 9990: DMARC aggregate reportingwww.rfc-editor.org
Written by the Sitelemetry team, checked against the product’s audit scope and linked primary sources. Examples are illustrative unless an observed case is explicitly identified.
