SPF and DMARC are excellent public context when they lead to the right question, not when they are used to manufacture an urgent security problem.
Read what DNS actually publishes
SPF is usually a TXT record beginning v=spf1 at the domain being evaluated. DMARC is a TXT record under _dmarc. You can inspect both without sending email or accessing a target system.
dig +short TXT example.com
dig +short TXT _dmarc.example.com
A domain may publish several TXT records unrelated to SPF. Parse the mechanism list and modifiers instead of declaring any TXT value "SPF". For DMARC, validate the syntax and interpret policy tags, subdomain policy, percentage and reporting destinations where present.
Avoid reading p=none as a breach
A p=none policy asks receivers for monitoring behavior rather than enforcement. It can be a deliberate step in a staged rollout. The commercial opening is a question about monitoring ownership, aggregate reports and the move toward enforcement, not a claim that the company is compromised.
A p=reject policy indicates a stricter published receiver instruction, but it does not prove all legitimate senders are aligned or that someone reviews reports. DNS records do not provide operational guarantees.
Translate records into responsible openers
| Observed record | Better discovery question |
|---|---|
| Missing valid DMARC after reliable query | Have you prioritized a DMARC rollout for this domain? |
p=none |
Who owns aggregate reporting and the enforcement plan? |
| Many SPF includes | Who maintains authorized sending services when tools change? |
p=reject |
Is ongoing alignment and reporting managed internally? |
Use the message in a sequence only when the company matches your actual service scope. Some businesses intentionally do not send mail from a given domain. Their DNS configuration may not justify an outreach campaign.
Add workspace and gateway context
Microsoft 365 evidence and an inbound gateway can help your team tailor a question. However, an SPF Microsoft include does not alone establish mailbox hosting, and absence of a recognized MX gateway does not rule out API-based security. Label inference separately from observation.
Run a small qualification test
Scan known prospects using Scan Prospects or research available segments through Find Leads. Verify unusual policies manually and send a limited set of service-specific messages. Track substantive conversations rather than raw replies. If the opener annoys prospects, change the outreach hypothesis, not just the subject line.
Pre-send verification checklist
Before personalizing a message from a policy clue, confirm that the lookup succeeded, the record is syntactically interpretable and the domain belongs to the business you intend to contact. For a domain with multiple TXT records, make sure you extracted the DMARC record from _dmarc rather than an unrelated verification string. If the result is absent, distinguish an authoritative negative answer from a resolver timeout.
Keep the outbound language at the same confidence level as the technical observation. "Your public policy currently indicates monitoring" can be acceptable when it is verified. "Your company is unprotected" is not justified by that record. The difference is what makes signal-based prospecting useful rather than another source of false security alarms.
Turn infrastructure signals into a qualified prospect list.
Analyze domains you already know, or find new companies that match the technologies you target. Public DNS observations support discovery, not proof of an internal security weakness.