Domain-based Message Authentication, Reporting, and Conformance (DMARC) records standardize email authentication methods for SPF and DKIM. DMARC is designed to protect a domain from being used maliciously or without consent in third-party mailings.
When a recipient's email server evaluates for a DMARC pass/fail, it checks for alignment between SPF or DKIM domains and the domain in the "From" address. The goal is to provide an added level of security and trust that (1) you are who you say you are as an email sender, and (2) that whoever is sending email from your domain is authorized to send email from that domain. DMARC policies then decide what to do with mail based on passing or failing.
To configure DMARC for use with Act-On, you must have either:
- DKIM set up for your "From" domain in Act-On
- An SPF record on your “Envelope” domain to include all mail servers sending email on your behalf, with your Envelope domain using the same top-level domain as your From domain
Both of these are DNS requirements in Act-On and industry-wide email best practices. Once completed, your IT team can add a DMARC record to your email domain's DNS. DKIM and SPF must be completed first - DMARC authentication will continue to fail until these records are set properly.
To learn more about DMARC and understand the email authentication process, see DMARC.org.
As of February 2024, a DMARC policy will become a requirement to deliver email to Gmail and Yahoo/AOL email addresses. Strict enforcement will be in place with Google & Yahoo as of June 2024.
DMARC Record Instructions
Below are 3 different scenarios for building or editing your DMARC records. Starting with a basic DMARC record, and moving into records that add additional levels of insight and reporting.
Basic, minimum requirement DMARC record
To add DMARC to your DNS, create a TXT record such as:
- Name: _dmarc or _dmarc.yourdomain.com (depending on your DNS provider)
- Type: TXT
- Value: v=DMARC1; p=none
This is a simplified version of what most DMARC policy records can look like. The record above indicates to receiving servers that SPF or DKIM should be valid for all messages using the client's domain in the "From" address but does not tell the receiving server to take any specific action if DMARC evaluation fails.
A DMARC “:p=quarantine” policy instructs the receiver server to isolate the message if it fails the DMARC authentication (this would be sending mail to either the spam folder or quarantine folder). A more stringent record for example might use “p=reject” to tell receiving servers to reject all messages that fail DMARC.
DMARC record with reporting
More advanced DMARC policies can include an email address to send reports of failures with a custom email address for receiving reports included in the “value” section. These can be valuable in finding where DMARC may be failing.
- rua=mailto:postmaster@example.com
This email address will likely receive a large number of emails, and it is worth setting this up for an email address not already in use by any other person or service.
DMARC reporting with a 3rd party reporting aggregator
If you’re looking to receive reporting it is always advisable, if not necessary, to have somewhere receiving reports for aggregation. Act-On recommends using a 3rd party service to receive these reports (as there can be an overwhelming amount of them), to provide aggregate summaries of where and with what emails DMARC may be failing. There are a large number of both free and paid services available that provide different levels of visibility and frequency into the DMARC records you receive.
A few recommended services and tools that can do this: