Do you know every source of email for your domain? Are spammers trying to spoof your email domain for hacking or fraud opportunities? Are you complying with the best email practices to ensure inbox delivery? These are the questions that DMARC answers, giving you full control of email delivery for your company’s domain.
At Postmark, email authentication has been extremely important to us from day one. We believe that anyone should be able to easily send emails with proper infrastructure, tools, and email standards without having to pay enterprise prices. DMARC, and our support of it, is a big part of this mission.
We wrote everything you need to know about DMARC below—but before you get started, how about a 4-minute video about DMARC featuring a raft of very authentication-focused ducklings?
What is DMARC? #
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a standard that prevents spammers from using your domain to send email without your permission — also known as spoofing. Spammers can forge the “From” address on messages so the spam appears to come from a user in your domain. A good example of this is PayPal spoofing, where a spammer sends a fraudulent email to you pretending to be PayPal in an effort to obtain your account information. DMARC ensures these fraudulent emails get blocked before you even see them in your inbox. In addition, DMARC gives you great visibility and reports into who is sending email on behalf of your domain, ensuring only legitimate email is received.
The good news is that DMARC is open and free for anyone to use, allowing you to secure your domain’s emails and gain control of your email delivery. All you have to do is follow the implementation steps in this guide and choose an ESP who supports DMARC.
What are the benefits of implementing DMARC? #
DMARC is a key component of a brand‘s email security and deliverability strategy as it enables:
- Visibility - Monitor emails sent using your domain to ensure they are properly authenticated using SPF and/or DKIM.
- Brand Protection - Block spoofed messages that might damage your brand‘s reputation with customers.
- Security - Prevent users from falling victim to phishing scams that could compromise your organization‘s security.
Does DMARC improve deliverability? #
DMARC allows you to see whether emails sent using your domain are properly authenticated using SPF and DKIM. This allows you to identify and fix any authentication issues that can affect the deliverability of your emails.
Preventing spoofed emails from reaching users can lower spam complaints and protect your domain‘s reputation with ISPs.
How does DMARC work? #
Before you understand the DMARC protocol, you first need to understand two email authentication standards called DKIM and SPF. DMARC is built on top of these standards, so let’s go over them first. If you already know about DKIM and SPF, skip to the DMARC section.
DKIM (Domainkeys Identified Mail) #
DKIM is a method to validate the authenticity of email messages. When each email is sent, it is signed using a private key and then validated on the receiving mail server (or ISP) using a public key that is in DNS. This process verifies that the message was not altered during transit. This lets an ISP (Gmail for instance) inspect the message and make a decision if the message is still in the same state as when it was sent. In other words, it prevents someone from intercepting your email, altering it, then sending it along with new (and possibly fraudulent) information. Another little known benefit of DKIM is that ISPs use this information to build a reputation on your domain. If you have great sending practices (low spam, bounces, high engagement) this can help improve trust and reputation with the ISPs.
With DKIM, each email you send is signed with the private key stored on your mail server. Later ISPs can verify the integrity of a message by fetching a corresponding public key from a special DKIM record in your DNS. The cryptography behind this (the same used in SSL) guarantees that only messages signed with your private key will pass the public key check. This is what the public key might look like in your DNS:
pm._domainkey.domain.com IN TXT
k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOCTHqIIQhGNISLchxDvv2X8NfkW7MEHGmtawoUgVUb8V1vXhGikCwYNqFR5swP6UCxCutX81B3+5SCDJ3rMYcu3tC/E9hd1phV+cjftSFLeJ+xe+3xwK+V18kM46kBPYvcZ/38USzMBa0XqDYw7LuMGmYf3gA/yJhaexYXa/PYwIDAQABThe private key must be kept secret. If a malevolent user ever gets their hands on your secret key they will be able to forge your DKIM signatures.
If DNS is a bit over your head, don’t worry. Postmark (and other ESPs) offer step by step instructions that can be sent to a domain administrator to make this easier. What is important for now is that you understand why DKIM matters.
SPF (Sender Policy Framework) #
SPF is a way for ISPs (like Gmail, Yahoo, etc) to verify that a mail server is authorized to send email for a domain. It is a whitelist for the services who are allowed to send email on your behalf. Like DKIM, SPF also works via DNS. For instance, if you use Campaign Monitor to send marketing email and Gmail to send regular email, you can insert a DNS record that includes their mail servers as trusted sources to send email for your domain.
v=spf1 a mx include:spf.mtasv.net include:_spf.google.com include:cmail1.com ~allKeep in mind, a single sending domain should only have one SPF record. Each service you use is appended to the SPF record through “include” directives as in the example above.
SPF has become extremely important to verify who can send email on behalf of your domain and directly impacts email delivery. Not only is it needed for email marketing or your corporate email accounts, but you also need it for things like support (Zendesk, Helpscout, etc) or other providers who send email on your behalf.
When using Postmark for sending, SPF is automatically handled without having to add or modify DNS records. Postmark does require manual setup of a custom return-path to pass DMARC SPF alignment, however.
If you’re curious, you can verify if a message is properly signed with DKIM or is passing SPF by looking at the message headers. In Gmail, this can be seen using the “Show original” option. Here is an example for the postmarkapp.com domain:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.117 as permitted sender) smtp.mail=pm_bounces@pmbounces.postmarkapp.com;
dkim=pass header.i=@postmarkapp.com;
dmarc=pass (p=NONE dis=NONE) header.from=postmarkapp.comWhat do DKIM and SPF have to do with DMARC? #
Well, everything. With SPF and DKIM, it is up to the ISP to decide what to do with the results. DMARC takes it a step further and gives you full control to set a policy to reject or quarantine emails from sources you do not know or trust, all based on the results of DKIM and SPF. For instance, since PayPal is a huge target for email fraud, they publish a DMARC record that says if DKIM or SPF fails, reject the message. Participating ISPs will look at this policy and discard the emails that fail. In the 2013 holiday season, DMARC helped PayPal stop an estimated 25 million attacks according to a report by Agari.
tl;dr; DMARC lets you tell ISPs how you want them to behave if SPF and DKIM fail or are not present. Here's a diagram showing how SPF and DKIM work together with your DMARC policy.
Similar to SPF and DKIM, this policy resides in DNS. A typical DMARC record in DNS will look like this:
_dmarc.domain.com TXT v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc-reports@domain.com\;The record above sets a policy to reject (p=reject) 100% (pct=100) if the email do not pass DKIM or SPF. Additionally, you can have ISPs send aggregate reports about these decisions to an email address (rua=mailto:dmarc-reports@domain.com). There is a lot more to this record and policy that we will get into shortly.
What should you do with DMARC reports? #
ISPs who support DMARC will also generate reports on sending activity for your domain. The reports are XML files that are emailed to the email address specified in your DMARC record. The reports contain the sending source (domain/IP) along with whether the message passed or failed SPF and DKIM. This is one of the best aspects of DMARC. Not only does it allow you to control email security for your domain, it also gives you deep visibility into who is sending on your behalf AND if they are signing with DKIM or passing SPF.
The problem with the reports is that you have to sift through an XML file. Here is what a typical XML report looks like:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<extra_contact_info>http://support.google.com/a/bin/answer.py?answer=2466580</extra_contact_info>
<report_id>4744268101791687049</report_id>
<date_range>
<begin>1398643200</begin>
<end>1398729599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>50.31.170.29</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>ord-staging2.mtasv.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>50.31.156.116</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>pm.mtasv.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>50.31.156.118</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>pm.mtasv.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>How do I setup and implement DMARC on my domain? #
Hopefully at this point you’re convinced that DMARC is amazing (it really is). So what’s the next step of DMARC alignment for your domain? This is the tricky part and is a longer process because there is a risk to implementing it. If you just went ahead and published a “reject” record, you could be telling ISPs to reject legitimate email. To make this endeavor less risky, we will break it down into two categories: Observation and Implementation.
DMARC Monitoring #
- Create a DMARC record to start monitoring results.
- Analyze DMARC reports to identify passing, failing or missing sources.
- Convert all known email sources to have DMARC aligned with DKIM and SPF.
- Once ready, start to quarantine email sources that do not align with DMARC.
- End goal: publish a reject record to reject any email that is not aligned with DMARC.
Free Weekly DMARC Checker with DMARC Digests by Postmark
We’ll process reports from major ISPs about your domain's DMARC alignment and turn them into beautiful, human-readable weekly email digests, absolutely free.
DMARC Monitoring #
1. Generate a DMARC record and start monitoring.
The very first step to implementing DMARC is monitoring. You can’t set a policy to reject emails before you know all of the sources of your email. You may know which email marketing providers, support systems, inbox services, and drip email services you use, but what about alerts from your servers and administrative tools you have? It’s nearly impossible to know all of these sources off the top of your head.
Luckily, the creators of DMARC understood this and built in reporting. The very first step to implementing DMARC is monitoring your email traffic and checking whether messages are passing or failing. There is only one step needed to make this happen - just insert a DNS record for DMARC on your domain. At first, it will look something like this:
_dmarc.domain.com TXT v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-reports@domain.com\;If you remember the first DMARC record above, the main difference is that we are saying “p=none” instead of “p=reject”. The “none” definition essentially places DMARC into a test mode. ISP’s will check every message, but only send you reports instead of taking action on them. This allows you to start collecting details on your email sources before you do anything drastic.
To make this even easier, we created a free DMARC record generator. This tool will walk you through setting up a DMARC record for your domain and start collecting your reports. Just go to dmarc.postmarkapp.com and follow the simple process. You’ll start receiving reports every Monday.
2. Analyze DMARC reports to identify passing, failing or missing sources.
So now you are receiving the reports every week and maybe even using the API to dig into the details. This part can be overwhelming as you see all of the email sources for your domain. Let’s take a sample report from our tool and dig into it. Remember that scary XML report above? We turn those reports into clear and understandable email digests like this:
How DMARC helps protect your domain's email reputation
The first thing you will notice are statistics at the top. We have:
- Processed: The number of messages processed by ISPs and sent in the reports.
- Fully Aligned: The number of messages that had both SPF and DKIM passing.
- Failed: The number of messages that had neither SPF or DKIM present.
Your sources
Next on the list we have Your Sources. These are email sources (domains and IPs that send email like Postmark, Mailchimp, Google Apps, etc) and the count of messages for each. We consider these messages “trusted” because either it was signed with DKIM or it passed SPF. In other words, you updated your DNS to explicitly approve this email source. In the example above, mtasv.net is a domain from Postmarkapp.com, where most of the emails are fully aligned and passing. In some cases one of the two might not pass, so we try to differentiate that, but still consider it trusted.
The goal here is to identify each sender and make sure that both DKIM and SPF pass. This might involve contacting your ESP, setting up DKIM in Google Apps, and so on.
Other sources
Moving down, you see “Other sources” and a similar list. These email sources did not pass SPF or DKIM, so we make the assumption that you have not explicitly “approved” these senders. The “Unknown” aspect of this section is most important. In many cases, you may be sending email from legitimate sources, but not signing with DKIM or have not added the sources to your SPF record. This is where the real work begins to implement DMARC.
Forwarded sources
Below your Other sources, you will notice a section called "Forwarded email sources". In this section you will see emails sent that passed DKIM but did not pass SPF DMARC alignment. In the majority of cases where DKIM passes DMARC while SPF fails is due to email forwarding by the recipient. For more information on this, head over to our help article here.
3. Convert all known email sources to have DMARC aligned DKIM and SPF.
As you receive reports each week and dig into the data, the real work is to identify the sources that are legitimate. If you notice an IP address or Domain that you send from, you want to make sure this source is signing with DKIM and is added to your SPF record. This is a tedious process, but you can take your time and fix issues as you see them.
Identifying each source can be tricky. One way to make this easier is to create a list of each source where you know you send emails. As new sources come in the reports, you can try to match them to the known sources in your list. These sources could be email providers, ecommerce systems, marketing services, or even server notifications and alerts. Common examples include Google Apps (gmail), Salesforce, Intercom, Campaign Monitor, Mailchimp, and of course Postmark.
A useful feature in our DMARC reports is resolving the source IP address. If you click on an IP address in the report, it will link to “http://whois.domaintools.com” which shows the location of the IP and the owner. For instance, a domain of emailsrvr.com and IP of 108.166.43.128 is unknown to me, but after following the link I can see this is from Rackspace. This may help me narrow down that it is from their hosting or email services.
Once you identify the source, you’ll want to look up the service that is sending the emails so you make the appropriate changes to your SPF or DKIM records. Services like Zendesk, Campaign Monitor, Google Apps, and Rackspace have articles on what SPF or DKIM records to add to your DNS. The harder ones are sources on your own servers where DKIM and SPF might not be as simple to implement. In some cases, it might be easier to migrate that email from your own email servers to a service like Postmark that can handle the DKIM and SPF for you.
Finally, you may see some failing source domains/IPs that don’t make sense to you. This can happen on legitimate messages from email forwarding where the SPF and DKIM headers are not preserved. If these sources are in the single digits, don’t worry about them as much. You will never be able to get all sources, so you have to decide where you draw a line in terms of how much you want to research the sources.
When it comes to analyzing DMARC reports, that sums up most of the process. As you add DKIM and SPF to more sources the number of unknown/threats should be reduced. Of course, you will never reduce these completely because spammers do spoof email for your domain. The hardest part of DMARC is figuring out when to publish a reject or quarantine record. This can only happen when you are comfortable with the number of known sources you have covered with both SPF and DKIM.
Implementation #
If you are able to cover all known sources, the next step is to gradually quarantine (p=quarantine) a portion of traffic (pct=10) and increase it over time. The quarantine will place failing messages in spam/junk folders. Once comfortable, you can pull the trigger on the reject policy (p=reject). This will tell ISPs to discard the failing messages completely, essentially stopping fraud on your domain as long as you control the approved sources.
Protect your brand from email scammers
Our premium DMARC monitoring with a single dashboard to monitor all mail sources, 60 days of history, and actionable recommendations.
Alternatively, use our free tool to receive weekly DMARC reports by email.
FAQ #
- Do all email service providers support DMARC?
- Not exactly. In order to fully support DMARC on your domain, the ESP must also set a custom
Return-Pathaddress domain. TheReturn-Pathis what ESPs uses to collect bounces, which is different from the from address. According to the DMARC spec, theReturn-Pathdomain must be at the same top level domain as the from address. At Postmark, we’ve made this a priority and implemented customReturn-Pathdomains. - Why do I see failing SPF reports for some legitimate sources?
- In some cases, an email provider may forward your email to another address. For instance, you send a newsletter to a customer and they forward it from their main mailbox to their Gmail account. While most email providers will properly preserve the from address and
Return-Pathaddress, others may rewrite it, causing a failure. While this may present a problem, it is limited to a small percentage. In addition, ISPs can still consider if a message has DKIM present in this case and allow it to pass. This is why it is important to have both SPF and DKIM passing on a domain.
