Authenticating Email with DMARC, SPF, and DKIM – A Quick Start Guide

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a technology that makes it easier for email senders and receivers to determine whether or not a message is legitimately from a sender, and what to do if it is not. In the most basic of terms, DMARC is akin to checking the credentials of your email.

DMARC is a relatively new advance in email authentication. It was created in 2011 and has since been adopted by senders and mailbox providers alike to prevent phishing and spoofing. Return Path was a founding contributor of the DMARC framework and we’re proud to have been involved from the very beginning.

Having a DMARC record for your email marketing efforts ensures that legitimate email is properly authenticating against established set standards, and that fraudulent activity appearing to come from domains under the organization’s control (your active sending domains, non-sending domains, and defensively registered domains) is blocked. Two key values of DMARC are domain alignment and reporting.

The alignment feature prevents spoofing of the “header from” address by:

1. Matching the “header from” domain name with the “envelope from” domain name used during an SPF check, and
2. Matching the “header from” domain name with the “d= domain name” in the DKIM signature.

While the implementation process can get tricky, building your record doesn’t have to be. Follow the steps below to build your DMARC record—hopefully it will take you 15 minutes or less.

1. Implement DKIM
Contact any email related third parties that you work with (thus delegate signing to), to make sure that they support DKIM signing. Some organizations would keep separate keys (selectors) for different organizational units. You will probably also have to work with your IT and security departments to go through the following checklist:

• Identify all domains that you send as, including subdomains
• Generate DKIM keys and create signing profiles for each domain
• Deliver relevant private keys to any third parties
• Publish all public keys in relevant DNS zones
• Verify third parties are ready to begin signing
• Turn on DKIM signing in RELAYED Mail Flow Policy
• Notify third parties to begin signing

2. Implement SPF
Properly implementing SPF will probably be the most time consuming and cumbersome part of any email authentication infrastructure implementation. Because email was historically very simple to use and manage, and completely open from a security and access point of view, organizations didn’t enforce strict policies around who can use it and how. This resulted in most organizations today not having a complete view of all the different sources of email, both internally and externally. The single biggest problem when implementing SPF is attempting to discover who is currently legitimately sending email on your behalf.

Things to look for:

• Obvious targets—exchange or other groupware servers or outgoing mail gateways
• Any DLP solutions or other email processing systems that may generate external notifications
• CRM systems sending information interacting with customers
• Various third party applications that may send email
• Lab, test, or other servers that may send email
• Personal computers and devices configured to send external email directly

The above list is not complete, as organizations have different environments, but should be used as a general guideline. Once your email sources have been identified, you may want to take a step back and clean up the list. Ideally, all of your outgoing email should be delivered through your outgoing mail gateways with a few justified exceptions.

If you use a proprietary or third party marketing mail solution, the infrastructure should be  separate from production email gateways. If your mail delivery network is exceptionally complicated, you may proceed with documenting the current state in your SPF, but do take time to clean up the situation promptly. If you serve multiple domains over the same infrastructure, you may want to create a single universal SPF record and reference it in individual domains using “include” mechanism.

3. Verify domain alignment
Begin by opening the email headers from the emails you send. Identify the domain or subdomain listed in the following places:

• The Envelope From (i.e., Return Path or Mail-From)
• The “Friendly” From (i.e., “Header” From)
• The d=domain in the DKIM-Signature’

If your domain names are aligned, you will be able to instruct mailbox providers to reject any malicious emails purporting to be sent by your brand.

If your domain names are not aligned, you can still proceed to create your DMARC record. Work with your IT department, security team, and marketing decision makers to decide on a strategy for fixing the issues.

4. Identify email accounts to receive DMARC reports
Through DMARC, you will receive aggregate and forensic (message level) reports daily. Designate the email account(s) where you want to receive these reports. You may want to use two separate accounts, as you could get inundated with the data!

Your DNS administrator should be equipped to assist you with this change. Reaching out to your IT department, security team, or even your ESP should work. Making updates like this go beyond a simple login. If you want to see what your current setup is, use a DMARC lookup tool. We like this one from Proofpoint,  which doesn’t require a login and provides a key to what your tags mean—but more on that later.

Reporting can be difficult to parse because reports are provided in a raw format. If you’re having issues, you might have to engage an outside company to help. We can provide a reference—simply contact us here. If you’re a Return Path client, you can reach out to your Technical Account Manager or Account Coordinator.

5. Learn what DMARC tags mean
DMARC tags are the language of the DMARC standard. They tell the email receiver (1) to check for DMARC and (2) what to do with messages that fail DMARC authentication.

There are many DMARC tags available, but you don’t have to use them all. In fact, you probably want to keep it simple! Using Proofpoint’s lookup tool, you can see what tags your record currently has, as well as learning what others mean. Again, no login or account creation is necessary.

6. Generate your DMARC record (if needed)
If you need to change something on your record, you will probably either rely on your DNS administrator to make a quick update, or generate a new text record to copy and paste into each of your sending domains. Because of the complexity of the process (and the potential issues that can arise), we like this tool from Proofpoint. There are a good number of DMARC record generators out there—just be sure to select one you trust.

7. Implement your DMARC record (if needed)
Work with your DNS administrator to add your DMARC record to DNS and start monitoring your chosen domain. After you copy and paste your text record into each sending domain, you’ll start receiving daily updates on your entire email ecosystem, including who is sending email on behalf of your brand, which emails are getting delivered, and which emails are falling short.

Again, the reporting is complex. If you’re struggling to make sense of your data, we can help. Simply contact us here or, if you’re a Return Path client, reach out to your Technical Account Manager or Account Coordinator. Although we do not directly provide email fraud services, we can certainly recommend companies that do.