A properly configured email authentication system is necessary for getting the best email deliverability rates and maximizing your email ROI. However, SPF and DKIM authentication may not be enough to protect your domain and IP address from spoofing, while still ensuring that all your emails hit the inbox.
The Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) authentication protocols were developed nearly two decades ago. They’ve been effective in protecting email users from spam, phishing, and other email attacks.
However, using two email authentication protocols complicate the already complex email environment. Senders often use multiple domains for sending emails, and work with third party email providers. There are a lot of hands in the pot. Emails can originate from a lot of sources. Hence, securing every email with SPF and DKIM is challenging.
Some legitimate emails get sent without proper authentication in place. So, email receivers are forced to separate legitimate emails that don’t authenticate and fraudulent emails that also don’t authenticate.
People complain more about legitimate emails that fail to reach their inbox. This pushes receiving domains to err on the side of delivering emails. In the end, bad emails sometimes make their way to the inbox.
It’s also tough to get feedback about email deliverability. So, deliverability issues can go undiscovered for weeks or months. This makes it even harder to sort legitimate emails from fraudulent emails.
All this makes receiving ISPs and ESPs hesitant to reject unauthenticated emails from senders that have very good reputations. A sender with a good reputation usually has their email authentication locked down.
Often, receiving domains will send an unauthenticated email from a quality sender to the inbox to avoid rejecting a legitimate email that was simply missed by the email authentication infrastructure.
To sum all this up, email authentication is complex. So, setting rules about what to do with unauthenticated emails clears the waters a bit and improves your deliverability rates. This is especially true if you have a complex sending infrastructure.
That’s where DMARC comes in. Adding DMARC records to your DNS records improves your email deliverability and gives the domain owner more control over email authentication.
We’ll explain exactly what a DMARC record is. We’ll also walk through what a record does, and how to create one. This will help you get your entire email authentication system under control, and get the most from your investment in your email program.
What is a DMARC Record?
There’s only one way to solve misunderstandings between sending and receiving mail servers. They must share information about their authentication infrastructures and what to do with unauthenticated emails.
Domain-Based Message Authentication, Reporting and Conformance (DMARC) records and authentication were pioneered by PayPal. PayPal used early DMARC technology to improve SMTP protocol security and email correspondence with popular email providers like Gmail, Yahoo!, and Microsoft.
Since then, DMARC authentication has become a standardized protocol available to all domain owners. There’s even a DMARC organization—DMARC.org.
Your DMARC record is a record your sending email server, or servers, uses to securely communicate with receiving email servers. DMARC records enable receiving email servers to confidently reject or quarantine unauthenticated emails from your sending domains without negatively impacting your email program.
DMARC records are stored in your DNS records. So, DMARC authentication easily integrates into your email authentication system. Your DMARC record outlines which authentication protocols should be present in each of your emails. It also tells receiving mail servers what to do if an email fails an authentication check.
DMARC checks benefit your email program in several ways:
- Reduce false positives.
- Offers thorough authentication reporting.
- Enforce sender policies.
- Minimizes phishing deliveries.
- Functions at internet scale.
- Reduces authentication process complexity.
In short, implementing DMARC checks makes your emails more trustworthy. It also improves email handling for both sending and receiving domains.
How to Create a DMARC Record
Your DMARC record is a string of text that’s published in your DNS records. Your DMARC record is created as a TXT record, then added to your DNS records.
These are the steps for creating and implementing DMARC records:
1. Check your SPF and DKIM authentication to make sure they’re working.
DMARC records improve the function of your SPF and DKIM records. DMARC records won’t work without SPF records and DKIM records in place.
At this stage, you should also check to see if you already have a published DMARC record in your DNS records. Check your DMARC records using simple online tools:
2. Create your DMARC TXT record.
A DMARC generator will build DMARC records for your domain. These are some good DMARC record creators:
- MXToolbox DMARC Record Generator
- Agari Data DMARC Record Generator
- Global Cyber Alliance DMARC Record Creator
DMARC uses tags to identify each part of your DMARC policy. Here’s what each tag means:
_dmarc.mydomain.com is the name of your DMARC TXT record. Replace “mydomain.com” with your domain name.
v=DMARC1 specifies the version of DMARC you’re using.
p=none tells email receivers your DMARC policy for handling emails that don’t meet your email authentication standards. There are three options for this:
- p=none. Emails that fail DMARC validation checks will will be treated the same as an email without DMARC validation. So, only SPF and DKIM authentication are used.
- p=quarantine. Emails that fail DMARC authentication are placed in a quarantine folder. This is usually the spam folder.
- p=reject. Emails that fail DMARC validation are blocked.
rua=mailto:email@example.com specifies where aggregate reports should be sent.
Aggregate reports contain information about the email originator. This includes:
- Sending domain.
- Sending IP address.
- Number of messages sent by date.
- DKIM signature and SPF records for the sending domain.
- Email authentication results.
ruf=mailto:firstname.lastname@example.org is the email that forensic reports should be sent to.
Forensic reports contain:
- Subject line and header information (header_from, etc.).
- Included URLs.
- Information about attachments.
pct=100 determines the percentage of emails that the DMARC policies should be applied to.
Only the “v=DMARC1” and “p=none” values are required to make a valid DMARC record. The pct, ruf, and rua tags are optional.
However, adding the optional tags will improve your email security and help you gather insights about your email deliverability.
There are other optional tags in a DMARC record that you may need. This depends on your email infrastructure and authentication needs.
aspf identifies the alignment mode for SPF authentication.
dkimoptional sets the alignment mode for DKIM authentication.
Check with your development team to find out which optional DMARC tags you need.
3. Work with your domain administrator or development team to publish your DMARC record in your domain DNS records.
Some email service providers have a workflow for publishing DMARC records yourself. But, it’s still a good idea to check with your technical team if you’re unfamiliar with the process.
4. Check your DMARC records to ensure that they’re properly configured. There are a couple ways to validate your DMARC record. First, you can use one of the DMARC checkers we mentioned earlier:
Or, you can send an email to one of these DMARC reporting services:
- email@example.com (put “test” in the subject line).
These services will check the DMARC record for the email address you send the email from. Then, they’ll respond with an emailed DMARC report that tells you if your DMARC record is working.
If the report shows that your DMARC record is functioning, you’re good to go.
Typically, a solid email service provider will handle DMARC implementation for you. Rejoiner audits every client’s authentication system to identify weak points. Then, we help implement authentication protocols and best practices to ensure that you’re getting the best email deliverability rates and return on your investment in your email program.
Once you have your DMARC records in place and supported by SPF and DKIM authentication, your email authentication infrastructure is complete. Your emails will reliably land in the inbox, where they’ll get results.
Did this post help you solve your email authentication problems? Subscribe for more articles just like this.
Or request a demo to see firsthand how Rejoiner helps you set up your email authentication and improves your deliverability rates.