How to Implement DMARC (Step-by-step Guide)

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:[reportingemail@yourdomain.com]

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 [reportingemail@yourdomain.com] with the email you want DMARC reports to be sent to. We recommend setting up a separate inbox for this (like dmarc@yourdomain.com) so your primary email doesn't get flooded with reports.

Reports can also be sent to multiple emails with a comma separator:

rua=mailto:rua-import-xxx@sendforensics.com,mailto:hey@mydomain.com

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 pass:

<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 header_from.

<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 header_from).

Only move on to the next step when you've confirmed:

1. You're receiving aggregate reports on schedule
2. 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 e.economist.com or 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, adkim and aspf for stricter alignment (default is relaxed), and ruf if you want forensic reports.