In this tutorial, you'll be editing your domain's DNS records to add a DMARC record. Before you start, make sure you have either SPF or DKIM set up and passing. DMARC will not work without at least one of these.
You'll also need access to your domain's DNS, which is usually provided by your registrar (like Godaddy or Google Domains).
Step 1. Add a DMARC record to your DNS
The record we usually recommend starting with has a "monitor" policy.
v=DMARC1; p=none; rua=mailto:[firstname.lastname@example.org]
This has a
p=none policy, so emails won't be rejected or sent to spam if DMARC fails. All it does is forward
rua reports to your email address. You may also find that simply adding a DMARC record achieves DMARC compliance for your emails, if either SPF or DKIM have been set up correctly.
Within your domain's DNS, add the following DNS TXT record:
Replace [email@example.com] with the email you want DMARC reports to be sent to. We recommend setting up a separate inbox for this (like firstname.lastname@example.org) so your primary email doesn't get flooded with reports.
If you're using SendForensics, replace the [email@example.com] with your SendForensics rua address.
Reports can also be sent to multiple emails with a comma separator:
Note that if the email receiving reports is on a different domain, an additional DMARC authorization record needs to be in place within that external domain's DNS.
You can also add a
ruf reporting address for individual forensic reports, but most people don't need this.
Step 2. Check your DMARC reports
It can take up to 48 hours for DNS to propagate and to start receiving aggregate reports. Reports are usually sent daily, though this varies by provider.
DMARC reports are sent as raw XML files. You can use a DMARC monitoring tool like SendForensics, or read them yourself.
<record> <row> <source_ip>203.0.113.209</source_ip> <count>2</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>mydomain.com</header_from> </identifiers> <auth_results> <dkim> <domain>mydomain.com</domain> <result>pass</result> <human_result></human_result> </dkim> <spf> <domain>mydomain.com</domain> <result>pass</result> </spf> </auth_results> </record>
Verify authentication results are
<auth_results> <dkim> <domain>mydomain.com</domain> <result>pass</result> </dkim> <spf> <domain>mydomain.com</domain> <result>pass</result> </spf> </auth_results>
Check alignment by matching the
domain with the
<identifiers> <header_from>mydomain.com</header_from> </identifiers>
DMARC will pass if either:
SPF passes and the SPF domain matches the header_from domain, or
DKIM passes and the DKIM domain matches the header_from domain
Step 3. Fix DMARC failures
DMARC fails when neither SPF nor DKIM is aligned. It doesn't matter if SPF/DKIM passed individually - one of them must also align (their domain matches with the
Only move on to the next step when you've confirmed:
- You're receiving aggregate reports on schedule
- DMARC is passing consistently across all your sending systems using that domain (marketing, business email, transactionals etc)
Step 4. Enforce DMARC
Once you're confident DMARC is passing consistently for all your sending systems using the domain, you can start enforcing a stricter policy and instructing receiving servers what to do with emails that fail.
From here, your specific policy depends on how aggressive you want to be. We usually recommend a phased approach; initially using
quarantine to minimise any accidental loss of legitimate email, monitoring again for a period, then moving to a stricter
reject policy which protects against spoofing better.
Some organizations have dedicated subdomains for specific email channels/sending-systems, like
notif.salesforce.com. If you have a dedicated subdomain like this, always send from the same provider, and the subdomain has its own DMARC record, then moving to a
reject policy is low risk.
You can also start adding the optional tags to customize DMARC enforcement. Common ones are
pct for the percentage of failed emails the policy should apply to,
aspf for stricter alignment (default is relaxed), and
ruf if you want forensic reports.
sptag, or override any inheritance completely by adding a separate DMARC record for each subdomain.