Direct Answer
A valid DMARC record needs v=DMARC1 and a clear p policy
A DMARC checker validates the TXT record that tells receiving mail servers how to treat messages that fail domain alignment. The minimum useful record contains v=DMARC1 and a policy tag such as p=none, p=quarantine, or p=reject. A monitoring record often looks like v=DMARC1; p=none; rua=mailto:dmarc@example.com. An enforcement record may use p=quarantine or p=reject, usually after SPF and DKIM are confirmed for legitimate senders.
The safest DMARC rollout is gradual. Start with p=none so reports can show who is sending mail for the domain. Fix or remove unauthorized senders, confirm SPF or DKIM alignment for legitimate systems, then test p=quarantine with a limited pct value. Move to p=reject only when reports show that real mail is aligned and no critical sender is failing. A record can pass basic syntax while still being operationally dangerous if it blocks mail before sender inventory is complete.
Workflow Guide
How to review a DMARC record before publishing
First, confirm the record is being added to the correct DNS host. DMARC records are published as TXT records at _dmarc.example.com, not at the root domain unless the DNS provider's interface automatically appends the host name. A common mistake is creating a TXT record at the wrong label, which makes the policy invisible to receivers even when the text itself looks correct.
Second, read the policy as an operational instruction. p=none asks receivers to send reports but not change delivery because of DMARC. p=quarantine asks receivers to treat failing mail as suspicious, often by placing it in spam or junk. p=reject asks receivers to reject failing mail. This is why a syntax checker is not enough. The record must also match the domain's sender inventory and tolerance for delivery risk.
Third, verify reporting and alignment. Aggregate reports are usually the most useful early signal because they reveal which services send mail for the domain and whether those messages pass SPF or DKIM alignment. Strict alignment can be valuable for security, but it should be tested carefully with third-party senders. Many SaaS tools, support desks, invoicing systems, and newsletter platforms need their own DKIM setup before strict alignment is safe.
Finally, keep the DMARC change tied to a rollback plan. Save the previous record, record the new policy, and define who will watch reports after the DNS change. If deliverability drops, the fastest mitigation may be reducing pct, returning to p=none, or fixing a sender's SPF/DKIM configuration. The best DMARC process is boring: validate the record, publish gradually, monitor reports, and increase enforcement only when the evidence supports it.
