Set up DMARC and review your domain's policy

DMARC links the message's authentication to the domain the recipient sees in From. To pass, it is enough for SPF to pass with alignment or DKIM to pass with alignment. An SPF record or a DKIM key existing does not prove on its own that a message passes DMARC.

The domain publishes in DNS how it asks for failures to be handled. The receiver keeps the final say on delivery.

Before creating the policy

Inventory all legitimate sources: everyday email, forms, shop, CRM, invoicing and campaigns. Check the authentication of each one. If you already have a DMARC policy, review why it is there before replacing it: do not weaken it to add a provider.

Edit the authoritative DNS zone, even if the website or email is hosted with another company.

Create the record

1. In cPanel > Zone Editor, click Manage for the domain. You can also use your DNS provider's editor.
2. Check whether a TXT record already exists at _dmarc and edit it if appropriate. Do not publish two policies for the same name.
3. Use the Add DMARC Record wizard, if it appears, or create a TXT record directly.
4. Check the final name: _dmarc.ejemplo.com, without duplicating the domain.

For an initial monitoring policy, an example is:

v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com

Replace the domain and create the report mailbox or receiver first. p=none does not request rejection or quarantine through DMARC; it is for monitoring, but it does not stop other filters from classifying the message as spam.

Choose the policy

Do not move to reject until you have checked every legitimate sender. A provider that authenticates with its own domain may need a signature or return-path domain aligned with yours.

sp lets you specify the policy for subdomains; check its effect before adding it. The adkim and aspf modes control whether alignment requires an exact match (strict) or accepts the same organisational domain (relaxed). Do not turn on strict mode to "improve the score" without checking the subdomains your senders use.

Reports and the wizard's old fields

rua requests aggregate reports. ruf requests failure reports, which are less widely supported and may include sensitive content. You do not need to enable ruf to get started.

Some wizards still have legacy fields such as pct, rf or ri. The May 2026 DMARC specification removes them; do not rely on them to guarantee an enforcement percentage or a report frequency. How quickly each receiver updates may vary.

If reports are sent to another organisational domain, its receiver must authorise this in DNS. Follow the DMARC reports guide and the instructions of the service that receives them.

Check the result

Look up the public TXT record, send tests through each real system and check the DMARC result of the messages. Then analyse the reports over several activity cycles before tightening the policy. Reports do not necessarily cover every recipient, nor do they arrive at a guaranteed frequency.

To look up the published TXT record you can use our DMARC checker: it shows the _dmarc record, explains each tag and suggests the next step for the policy. It confirms which policy is published, not that messages pass DMARC; for that, send a real message to our email test, which checks SPF and DKIM alignment with the sender.

If a problem appears, identify the sender and its alignment before deleting DMARC or relaxing the policy for the whole domain. For several domains, prepare an inventory per domain and ask support about the scope of the changes; do not automatically apply a restrictive policy to all of them.