DMARC (Domain-based Message Authentication, Reporting & Conformance) is a standard designed to prevent spammers from using your domain to send unauthorized emails, also known as spoofing. Spammers often manipulate the "From" address in their messages to make it appear that the email is from someone within your domain.

For example, they may send a fake email to deceive the recipient into revealing their account information. DMARC works by blocking these fraudulent emails before they reach the inbox, giving you greater control and visibility over who can send emails on behalf of your domain. By implementing DMARC, you can secure your domain's emails and ensure that only legitimate emails are received.

The good news is that DMARC is open and free for anyone to use. As of February 1, 2024, some major ISPs (like Gmail) will require that your domain have DMARC setup if you send promotional emails in large volumes. Not having a DMARC policy may lead to your emails being rejected or marked as spam.

To understand DMARC, you first need to understand two email authentication standards: DKIM and SPF. DMARC is an addition to these standards, so let's review them first.

DKIM is a method used to verify the authenticity of email messages. When sent, each email is signed with a private key and then validated on the receiving mail server using a public key stored in a DNS record. This process ensures that the message was not tampered with during the transmission. It allows an ISP, such as Gmail, to examine the message and determine if it is still in the same condition as when it was sent. In other words, it prevents someone from intercepting your email, changing it, and sending it again with new and possibly fraudulent information.

A little-known advantage of DKIM is that ISPs use this information to create a reputation for your domain. If you have good sending practices, such as low spam complaint rate, few bounces, and high engagement, this can help increase trust and reputation with ISPs.

If this sounds very technical, don't worry! When you connect your domain to MarketHype, all this is handled.

SPF is a method used by email providers, like Gmail, to verify whether a mail server can send emails on behalf of a specific domain. Like DKIM, SPF also operates through DNS. For example, if you use MarketHype to send your marketing emails and Gmail to send your regular emails, you can add a DNS record that includes both mail servers as trusted sources for sending emails from your domain.

When you connect your domain to MarketHype, this is also taken care of. We verify that your DNS records are set up so that all emails you send through MarketHype will pass DKIM and SPF validation.

With DKIM and SPF in place, the ISP can verify that the email has not been tampered with and is sent by someone you trust. If the email fails either DKIM or SPF validation, this is an indication that something might be fishy, but it is up to the ISP (like Gmail) to decide what to do with the message.

This is where DMARC comes in. With your DMARC policy, you can tell the ISP what you want them to do with emails from sources you don't know or trust. You can tell them to reject those emails altogether, or you can tell them to quarantine them (essentially mark them as spam).

Like SPF and DKIM, the DMARC policy is set up through DNS. A typical DMARC record in DNS will look like this:

The record above sets a policy to reject p=reject 100% pct=100 of the emails that do not pass DKIM or SPF validation. More about this is coming right up!

Setting up DMARC for your sending domain may take some time and effort to get to a point where you can reject all messages that do not pass the test. You'll need to create a DMARC record for your domain, observe and analyze the DMARC reports sent to you, and finally implement changes to your DMARC record's policy to make sure that only messages that pass DMARC reach your recipient's inboxes.

The first step to implementing DMARC is creating a DMARC record to add to your domain's DNS provider.

There is a great free DMARC tool from Postmark that can help you get started. The tool can help you generate a DMARC record, but it also lets you monitor who is sending emails from your domain and whether they pass DKIM/SPF validation. This can be a great starting point for you and be the first step in moving towards a stricter DMARC policy in the long run.

You can also generate and use your own DMARC record. Here is an example of a DMARC record that you can use as a starting point:

The DMARC record consists of multiple parts, some of which include:

In the example above, the p=none policy will let you test and monitor the email traffic for a while. ISPs will check every message but only send you reports without taking action on them. This lets you start collecting information on who is sending emails on your behalf and if they pass the DKIM/SPF check. Sources that do not pass the check will be affected when you start to enforce a stricter DMARC policy. We recommend using the "p=none "policy as you start with DMARC.

If you use the above DMARC record example as a starting point, you'll want to replace the "yourdomain.com "value with your own domain. You will also need to update the rua= tag value to an email address you manage where you would like to receive the DMARC reports that recipient mail servers will send you. However, we recommend that you use a tool for this so you don't have to sift through all those reports manually on your own.

With your DMARC DNS record in place, you will start to receive DMARC reports from receiving mail servers. These reports will give you a better understanding of which services are being used to send emails using your domain and whether those messages are passing DKIM/SPF checks or not.

The DMARC reports you'll receive are in XML format and a bit ugly and complicated to look at. That is why we recommend using a free tool to parse and summarize the reports instead of sifting through all those reports yourself.

As you receive reports and analyze the data, the main task is identifying the legitimate sources and determining if the messages are DMARC compliant using SPF and/or DKIM. If you come across an IP address or domain you send from, it is important to ensure that this source is signed with DKIM and added to your SPF record. While this process can be time-consuming, you can take your time to take care of any issues that you have.

Identifying each source can be challenging. One way to simplify this task is by creating a list of known sources from which you send emails. When new sources appear in the reports, you can match them with the sources in your list. These sources might include email providers (Gmail, Outlook), ticketing- or booking systems that send order confirmations, marketing services like MarketHype, etc.

Once you identify the source, you'll want to verify that the source passes the DKIM/SPF validation and make the appropriate changes to your SPF or DKIM records if it isn't so that their email deliverability is not affected when you enforce a stricter DMARC policy in the future.

Finally, you may come across some failing source domains/IPs you are unfamiliar with. This can occur in legitimate messages when email forwarding doesn't preserve the SPF and DKIM headers. If these sources are only a few and send very few emails, you don't need to worry about them too much. Identifying all sources is impossible, so you need to decide where to draw the line regarding how much you want to investigate them.

Of course, you will never completely eliminate these unknown sources because spammers do spoof emails from your domain. One of the more challenging aspects of DMARC is determining when to publish a reject or quarantine record. This decision can only be made once you are confident that you have covered a sufficient number of known sources with both SPF and DKIM.

Once you've been receiving and keeping an eye on your domain's DMARC reports for a while (at least a few months), you should have been able to add all of your legitimate sending sources to your domain's DNS so that those messages are passing DMARC. Only after you've done this, you should think about updating your domain's DMARC policy to "quarantine".

The p=quarantine DMARC policy tells the ISPs that if they receive messages sent using your domain that are not DMARC compliant, then they should move those messages to the recipient's spam folder.

This ensures that genuine messages sent from your domain and through sources that pass DMARC will be delivered to the inbox. On the other hand, messages sent by spammers or phishers that fail DMARC will not reach the inbox. Instead, they will be directed to the spam folder, which helps maintain a good sending reputation.

Note that you can also specify a percentage (pct) value to avoid immediately quarantining all emails that fail DMARC. If you've copied the default DMARC DNS record in the example above, you'll find a variable of pct=100.

This determines the proportion of emails that will be affected by the DMARC policy. It is advisable to initially set your DMARC policy to quarantine for a small percentage of emails and gradually increase it over time.

For instance, you can update your domain's DMARC policy on a weekly basis to quarantine only a portion of the messages.

This gradual increase helps reduce the risk of missing a valid sender while also beginning to filter and protect your domain and email delivery. Make sure to inform your support or customer service team about these changes in case they start receiving reports of lost emails. This will create a communication chain that can ensure problems are identified if you've missed a valid email source in your SPF record.

Like above, once you've monitored your domain's sending and are sure that your legitimate messages are passing DMARC, and after you've implemented and monitored the p=quarantine policy for some time, you can then update your domain's DMARC policy to "reject".

Once you update your domain's DMARC record to use the p=reject policy, any message sent from your domain that fails DMARC will be dropped by the receiving mail server. This means that the message will not be delivered to the recipient's inbox or even their spam folder.

We recommend not implementing the "reject" policy until you have thoroughly monitored your messages to make sure that all legitimate messages sent from your known sources are successfully passing DMARC.

You may think that after updating your domain's DMARC policy to p=reject you are finished with DMARC monitoring. This is not quite the case, unfortunately.

It is crucial to continuously monitor the DMARC reports you receive to verify that all sending sources (both old and new) are still successfully passing DMARC. There might be changes in your sending configuration or your domain's DNS settings that could unexpectedly result in your messages failing to pass DMARC. Since your domain's DMARC policy is set to "reject," these messages will be discarded and will not be delivered to your recipients.

DMARC monitoring is essential for maintaining a strong domain reputation and ensuring that only your legitimate messages reach recipient inboxes. It is a powerful tool that helps prevent spammers and phishers from using your domain to send spam.

If you have questions about DMARC and how to properly set it up for your email domains, don't hesitate to contact us - success@markethype.io