Save time and feel confident you are set up for long-term success with Email Implementation. Our experts will work as an extension of your team to ensure your email program is correctly set up and delivering value for your business.
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.
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.
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.
Save time and feel confident you are set up for long-term success with Email Implementation. Our experts will work as an extension of your team to ensure your email program is correctly set up and delivering value for your business.
p=none to p=quarantine to p=reject as you gain experienceStart 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.
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.
"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.
Always start out using the p=none policy. You can move to p=quarantine or p=reject when you better understand your sending reputation.
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.
The filename is formatted as:
filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp "." extension
Example: receiver.org!sender.com!1335571200!1335657599.zip
1<?xml version="1.0" encoding="UTF-8" ?>2<feedback>3<report_metadata>4<org_name>receiver.com</org_name>5<email>noreply-dmarc-support@receiver.com</email>6<extra_contact_info>http://receiver.com/dmarc/support</extra_contact_info>7<report_id>9391651994964116463</report_id>8<date_range>9<begin>1335571200</begin>10<end>1335657599</end>11</date_range>12</report_metadata>13<policy_published>14<domain>sender.com</domain>15<adkim>r</adkim>16<aspf>r</aspf>17<p>none</p>18<sp>none</sp>19<pct>100</pct>20</policy_published>21<record>22<row>23<source_ip>72.150.241.94</source_ip>24<count>2</count>25<policy_evaluated>26<disposition>none</disposition>27<dkim>fail</dkim>28<spf>pass</spf>29</policy_evaluated>30</row>31<identifiers>32<header_from>sender.com</header_from>33</identifiers>34<auth_results>35<dkim>36<domain>sender.com</domain>37<result>fail</result>38<human_result></human_result>39</dkim>40<dkim>41<domain>sender.net</domain>42<result>pass</result>43<human_result></human_result>44</dkim>45<spf>46<domain>sender.com</domain>47<result>pass</result>48</spf>49</auth_results>50</record>51</feedback>
Aggregate reports are sent as a ZIP attachment, so be sure the address you're defining is able to accept attachments in this file type.