What are the key elements of DMARC syntax?

When the syntax changes

A short record can be valid, but the right tags depend on what the domain needs to express.

Use sp when subdomains need a policy distinct from the organizational domain. If a visible From address uses alerts.yourdomain.com, inspect the policy discovery for that exact domain before assuming the root-domain record is the only relevant record.

Use rua when your team needs aggregate reports. The destination must be a valid reporting URI, commonly a mailto: address. A reporting address on another domain can require external reporting authorization under the DMARC specification.

Use adkim and aspf when you need to state alignment preferences:

• adkim=r or adkim=s controls relaxed or strict DKIM alignment.
• aspf=r or aspf=s controls relaxed or strict SPF alignment.

Do not move to p=quarantine or p=reject based only on a syntactically valid record. A sender can pass SPF or DKIM and still fail DMARC if the passing identifier does not align with the visible From domain.

RFC 9989 identifies the older pct tag as historic. Do not depend on it as the basis for a current policy rollout. Use aggregate-report evidence and same-path message tests to decide when a stronger policy is appropriate.

Worked DMARC syntax example

The following is illustrative only. Do not copy the reporting address into production unless your team owns and operates it.

v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s

This example has these elements:

• v=DMARC1 identifies the record.
• p=quarantine requests suspicious treatment for DMARC failures using the organizational domain.
• sp=reject requests a different policy for subdomains.
• rua=mailto:dmarc-reports@yourdomain.com requests aggregate reports.
• adkim=s requests strict DKIM alignment.
• aspf=s requests strict SPF alignment.

What to check after publishing the record

Start with the evidence you have.

If you have a domain name and need to inspect public DNS, use the DMARC checker to look up the published record. Confirm the hostname, the tag order, and whether the returned record matches the approved DNS change.

If you need other public DNS checks, review Palisade's email security tools.

If you control DNS, query the authoritative DNS service and at least one public resolver after publishing. DNS visibility confirms that the record is available. It does not show that a mailing platform signs messages correctly or uses the intended envelope sender.

If you have a delivered production message, inspect its raw headers. The Authentication-Results header can show the receiver's recorded SPF, DKIM, and DMARC evaluation for that message. Compare the visible From domain with the domains that passed SPF or DKIM.

If aggregate reports have started to arrive, use them to identify sources and failure patterns over time. That is the DMARC layer of validation. It is separate from DNS publication, a vendor's configuration screen, and a single delivered message.

Check the DMARC syntax your domain publishes

A public lookup is the right next step when you need to confirm the record currently visible in DNS. Check the actual TXT record before changing policy, then compare it with the DNS value your team approved.

Check the published DMARC record

A public-record check cannot prove that a mailing application is signing production mail, that every legitimate sender aligns, or how a specific receiver will place a future message.

When ongoing aggregate reports reveal unidentified senders or recurring alignment failures, Start with Palisade. Palisade analyzes DMARC aggregate-report data, identifies sources and alignment issues, and proposes prioritized remediation work. A human still reviews the evidence and applies any DNS or policy change.