DMARC guide – Ometria Help Centre

Be aware: As of February 2024 Gmail and Yahoo will require all bulk senders to have a DMARC record in place. Read all about it in the Deliverability team's blog post: Everything you need to know about the changes to Gmail and Yahoo's standards in 2024.

DMARC (domain-based message authentication, reporting and conformance) is an email authentication protocol designed to help email domain owners protect their domain from 'spoofing', or unauthorised use - e.g. a sender using your domain to send unauthorised email for phishing and other purposes.

Ometria doesn't provide DMARC services, but we can provide some guidance on the implementation.

You'll need to set up the DNS record and have a way to manage the reports.

See also:

How does it work?

A DMARC policy allows a sender to indicate that their messages are protected by SPF and/or DKIM, and tells the recipient what to do if neither of those authentication methods passes – e.g. junk or reject the message.

DMARC removes guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent and harmful messages.

DMARC also provides a way for the email receiver to report back to the sender about messages that pass and/or fail DMARC evaluation.

Your DMARC record is published as a TXT record in your DNS records.

Not all receiving servers will perform a DMARC check before accepting a message, but all the major ISPs do and implementation is growing.

DMARC policies

There are three levels of DMARC policy:

Policy	Description
p=none	Tell the recipient to perform no actions against unqualified mail, but still send email reports to the mailto: in the DMARC record for any infractions.
p=quarantine	Tell the recipient to quarantine unqualified mail, which generally means “send this directly to the spam folder.”
p=reject	Tell the recipient to completely deny any unqualified mail for the domain. With this enabled, only mail that is verified as 100% being signed by your domain will even have a chance at the inbox. Any mail that does not pass is denied (not bounced) so there’s no way to catch false positives.

DMARC requirements

As of February 2024 Gmail and Yahoo require the following:

Your DNS must have a DMARC record in place
Your DMARC record must include:
- the policy tag, e.g. p=none, p=quarantine or p=reject
- the reporting tag - this is an email address where you send the DMARC reports to, e.g. rua=mailto:postmaster@example.com

Implementing DMARC

We recommend using a specialist DMARC service for implementation.

Get in touch with your Customer Success Representative and Ometria's Deliverability Team, who can recommend providers.

Here is a rough guide to the steps you'll need to take to implement DMARC.

Note: Ometria set up SPF and DKIM as part of your onboarding, so there is nothing you need to do for either of these.

1. Choose a reporting tool

Your IT team will need to closely monitor your sending for DMARC failures throughout the implementation via a DMARC reporting tool.

Note: Yahoo strongly recommends senders use the RUA reporting, and this will be a requirement of theirs in the future.

Ometria doesn't have a partnership with any DMARC services, but we know that the following providers have a good reputation:

2. Implement a p=none policy

Implement a DMARC record on your domain with p=none and a reporting value from your DMARC reporting tool.

3. Monitor your sending

Using your DMARC reporting tool, monitor your sending for a week to make sure that no legitimate mail is failing DKIM or SPF.

Once you're confident, move on to the next step.

4. Implement a p=quarantine policy

This should move all messages that fail DKIM and SPF into the spam folder.

Note: Once you've reached p=quarantine, you can implement BIMI.

5. Monitor your sending

Use your DMARC reporting tool and spot-check messages to your testing address to continue monitoring sends.

Make sure no legitimate mail is being moved to the spam folder as a result of a DMARC failure.

6. Implement a p=reject policy

Once you're absolutely certain that no genuine mail is failing DMARC, implement p=reject.

7. Monitor your sending

Continue to monitor DMARC failure.

Whenever you start sending emails from your domain via another ESP (e.g. your transactional sends), make sure that DKIM and SPF both pass, otherwise the messages will fail DMARC and be rejected by the inbox provider.