How to Implement DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) was created to tell a participating receiving email server what to do with a message that fails both SPF and DKIM validation. In other words, what to do if a message claims to be from you, but isn't. If SPF, DKIM, and email validation are new concepts to you, see Everything about DMARC for a full explanation.

Why you should deploy DMARC

Deploying DMARC for your email systems is a powerful way to help prevent malicious entities from potentially spoofing or otherwise tarnishing your reputation as a trustworthy email sender. If you have ever had problems with phishing, or if you operate a finance-related business, implementing DMARC may be a good decision. Additionally major inbox providers require DMARC for larger senders. DMARC is not required by SendGrid, however all senders are encouraged to have a policy in place.

DMARC, in conjunction with a dedicated IP (included in Pro or higher accounts), is a great start to getting industry-supported peace of mind.

Reading DMARC reports

The DMARC aggregate and forensic reports are designed to be machine-readable and can be difficult for humans to make sense of. You will also need to utilize a DMARC report monitoring service such as Valimail to collect the reports and present the information in a meaningful way that leads to actionable insights.

The 5 phases of implementation:

1. Complete Domain Authentication for your SendGrid account, which will deploy DKIM and SPF for your SendGrid IP
2. Publish a DMARC record with your DNS registrar, then monitor the results
3. Analyze the feedback you receive, and adjust your mail streams as needed
4. Escalate your DMARC policy tags from p=none to p=quarantine to p=reject as you gain experience

1. Complete Domain Authentication for your SendGrid account

Start by completing Domain Authentication via the SendGrid Console. This ensures that emails sent through your SendGrid account will be properly signed using DKIM and SPF for your unique domain.

2. Publish a DMARC record with your DNS registrar, then monitor the results

Within your DNS registrar, you'll need to create a TXT resource record that receivers can use to determine your DMARC preferences. This is done within the DNS registrar of the domain host—likely the same place you created the DNS records for the authenticated domain. This record is made at the root level for the domain, not the subdomain. In the console, SendGrid will display your DMARC record if it exists or suggest setting a DMARC record of v=DMARC1; p=none; if none is identified, as this may be required by certain inbox providers. Although you might not intend to act on DMARC results, implementing this policy serves as a beneficial minimum. However, your organization may have stricter requirements.

A simple DMARC record

"v=DMARC1; p=none; pct=100; rua=mailto:dmarc_agg@vali.email"

For details about DMARC records, see the DMARC Records section of Everything about DMARC where you'll find detailed explanations of every tag in a DMARC record.

3. Analyze the feedback you receive and adjust your mail streams as needed

If unqualified mail gets sent to, and received by, recipients participating in DMARC, the recipient will generate reports for these messages and send them back to the mailto: address specified in your DMARC record. These reports will give you the information required to evaluate and tune your mail streams, helping you determine exactly what services are sending mail on behalf of your domain. SendGrid partners with Valimail to help customers get the most from DMARC. To leverage their DMARC monitoring and inbox provider alignment support, First include rua=mailto:dmarc_agg@vali.email in your DMARC record. Then visit Valimail to set up an account.

Below is a sample report with only one record, showing the results for 2 pieces of mail. Please note that the listed SPF and DKIM auth_results are raw results, regardless of the s= alignment. For help understanding all the tags in a DMARC record, see the DMARC Records section of Everything about DMARC.

Sample DMARC report

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <report_metadata>
        <org_name>receiver.com</org_name>
        <email>noreply-dmarc-support@receiver.com</email>
        <extra_contact_info>http://receiver.com/dmarc/support</extra_contact_info>
        <report_id>9391651994964116463</report_id>
        <date_range>
            <begin>1335571200</begin>
            <end>1335657599</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>sender.com</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>none</p>
        <sp>none</sp>
        <pct>100</pct>
    </policy_published>
    <record>
        <row>
            <source_ip>72.150.241.94</source_ip>
            <count>2</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>fail</dkim>
                <spf>pass</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>sender.com</header_from>
        </identifiers>
        <auth_results>
            <dkim>
                <domain>sender.com</domain>
                <result>fail</result>
                <human_result></human_result>
            </dkim>
            <dkim>
                <domain>sender.net</domain>
                <result>pass</result>
                <human_result></human_result>
            </dkim>
            <spf>
                <domain>sender.com</domain>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
</feedback>

4. Escalate your DMARC policy tags from p=none to p=quarantine to p=reject as you gain experience

Now that you’ve tested and tweaked your mail streams to determine exactly who and what is sending mail for your domain, you can adjust your policy setting.

Until now you should have been using the p=none policy to get reports of any errant behavior, and you should have a good idea of where email is coming from. The next step is to adjust the policy on your DMARC record to start controlling how receivers handle email claiming to be from your domain.

p=none - Get reports of infractions, but no action is taken by recipients as far as processing the messages themselves.

p=quarantine - Unqualified mail goes directly to spam, but can be recovered. This is useful when you’re fairly certain you know all the locations where mail is coming from but want to "softfail" any messages that are unqualified until you’re 100% sure.

p=reject - Unqualified mail is completely deleted by the recipient mail server, never to be seen again. Use this setting when you’re absolutely sure you know every server and service that is sending email for your domain, signing is in place for each of these services, and you want any service claiming otherwise to be completely denied

Additional Resources

• Valimail Align
• Everything about DMARC
• DMARC.org
• DMARC.org Frequently Asked Questions
• DMARC specification
• Returnpath quickstart download
• Agari
• SPF record validator
• DMARC record validator