DMARC tells receivers how to handle messages that fail aligned SPF and DKIM checks and can send reports about domain use. Begin with visibility, then enforce only after legitimate senders have been checked.
IN THIS ARTICLE
Check access and requirements
Inventory your sending services, verify SPF and DKIM and choose a monitored reporting destination. SiteWorx requires its SPF and DKIM setup before its DMARC creation workflow is available.
01 Add a monitored DMARC policy through SiteWorx
- Open Administration > Mail Options > DMARC and add the intended domain.
- Choose a monitoring policy initially, normally
p=none, with an authorised aggregate-report destination. Review alignment and subdomain choices deliberately. - Save and inspect the generated TXT record at
_dmarc. If another provider hosts authoritative DNS, publish it there and avoid duplicate DMARC records. - Send representative mail through hosting, application and external sending services. Confirm at least one authenticated mechanism aligns with the visible From domain.
- Review reports over a representative period and correct legitimate failures before gradually moving to quarantine or reject. Retain a written recovery policy.
02 Example: publish a monitoring record
For a domain you control, create the aggregate-report mailbox first. An illustrative TXT value is:
v=DMARC1; p=none; rua=mailto:[email protected]Replace example.com with your domain and a reporting address you actually monitor. Publish the value at _dmarc.example.com, using either the relative label _dmarc or full name as your DNS form requires. Inspect the resulting hostname to avoid appending the domain twice, and edit an existing DMARC record instead of adding a second one.
p=none requests monitoring without a DMARC rejection/quarantine policy; receivers still apply their own filtering. Review representative reports and message headers before enforcing a stronger policy. Current DMARC protocol and aggregate-reporting references are RFC 9989 and RFC 9990; older panel documentation may still link RFC 7489.
Confirm the expected result
Public DNS should expose the intended policy, and legitimate messages should show a DMARC pass. Reports are evidence to review, not proof that every receiver applies an identical policy.
Resolve setup problems
If a legitimate service fails, fix its sender configuration or alignment. Do not remove all authentication merely to restore one route. Reporting to another organisation’s domain may require that destination’s explicit DNS authorisation.
Must both SPF and DKIM pass for DMARC?
DMARC can pass when either SPF or DKIM both passes and aligns appropriately. Configuring both improves resilience, especially where forwarding changes the SPF result.