Get Started with DMARC and SendGrid

Twilio Copy of Getting Started with DMARC and SendGrid

If you're communicating with customers by email– for transactional communications, marketing campaigns, or customer service follow-ups – then you know that deliverability is incredibly important. Deliverability is closely tied to your sender reputation. When your emails don’t reach customers because they’ve been flagged as spam or rejected as possibly fraudulent, it presents a challenge.

Email spoofing is used by attackers who try to disguise their emails as originating from a different address or domain. Imagine an attacker spoofing an address from your business’s domain to pitch a cryptocurrency scheme or discount pharmaceuticals. Your business reputation suffers, and your sender reputation will likely suffer too.

Enter Domain-based Message Authentication, Reporting, and Conformance , or DMARC. DMARC is a protocol that mail servers use to verify the authenticity of incoming email before they route it to the intended recipient’s inbox.

In this post, we’ll walk through how to get up and running with DMARC using SendGrid. We’ll provide suggestions and ways to implement them. As you follow along, you’ll learn how to protect your own domain from spoofing attempts while improving your sender reputation and email deliverability.

How DMARC Works

After this section, I’ll show you SendGrid can support your DMARC policy. But if you’d like some background on how DMARC works first, here’s a quick overview:

• The DMARC protocol also relies on Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
• SPF is a domain owner’s specification of which SMTP servers are verified senders of email from that domain. The domain owner specifies this in a special TXT record among the domain’s DNS records. Receiving mail servers check incoming email (and the server that sent it) against the SPF record to make sure the mail is actually coming from who it says it comes from.
• DKIM adds a digital signature to outgoing emails, which is then validated against a public key, which is published as CNAME records for the domain. Receiving mail servers use DKIM to verify that the contents of emails have not been tampered with.
• DMARC specifies what a receiving mail server should do in the case of SPF or DKIM failing authentication. That action (or policy) can be to take no action, quarantine the email by sending it to spam, or reject the email altogether. Just like SPF and DKIM, DMARC is specified through a DNS record.

In this post, we’ll start with a policy of no action, then test quarantining or rejecting email. In general, SendGrid suggests you start with p=none as a policy, but move to p=quarantine or p=reject over time.

And you’ll want to move, eventually. Brand Indicators for Message Identification (oft-shortened to BIMI ), adds a verified brand logo next to the email in the recipient’s inbox. BIMI also requires a policy of p=quarantine or p=reject.

For a more detailed breakdown of what DMARC is and how it works, check out “ What is DMARC?”

Prerequisites

Before you begin the tutorial, you’ll need a few things:

• A SendGrid account (you can sign up for free, here).
• A domain you own where you can edit the DNS settings.

And with that, we can begin the tutorial.

Initial Setup

In this demo, we are owners of a domain, codingplus.coffee. We want to use the SendGrid SMTP server to send emails from this domain, but we also want to implement DMARC to protect our domain from email spoofing attempts.

Step 1: Add a SPF record

As mentioned above, the SPF record for your domain specifies the list of permitted mail servers from which your emails will come. When incoming servers receive an email, they can check the SPF record for the domain to verify that the email came from a permitted mail server.

Implement SPF by adding a TXT record to the DNS records (instructions vary by DNS provider, see here for more) for your domain. For our demo, since our emails are only allowed to be sent by sendgrid.net, our TXT record looks like this:

Step 2: Authenticate domain and add DKIM records

To send emails through SendGrid’s SMTP server, we need to authenticate our codingplus.coffee domain. Authenticating our domain with SendGrid also improves our deliverability.

First, we sign into SendGrid. Then, we navigate to Settings > Sender Authentication.

We click Authenticate Your Domain.

We need to select our DNS host, or specify it if it’s not in the list. Then, we click Next.

Next, we provide the domain from which we’ll send emails. Click Next.

SendGrid provides us with several DNS records we need to add to our domain.

• The first CNAME record in the list associates our domain with our SendGrid account, and SendGrid uses it to help track email engagement (clicks and opens) for our account.
• The next two CNAME records (with _domainkey in the HOST) are DKIM records.
• The final TXT record is related to DMARC.

When authenticating your domain with SendGrid, you’re only required to add the three CNAME records. For now, we’ll set aside the TXT record for DMARC, since we’ll look at it in more detail below.

Below, you can see how we use MX Toolbox to verify the CNAME record for associating our SendGrid account:

After adding our three CNAME records, we check the box in SendGrid and click Verify.

Our DNS records are properly updated, which completes the domain authentication process.

You can read this page for more detailed information on domain authentication with SendGrid.

Step 3: Verify a sender

Next, we want to verify that we own the email address from which we’ll send our emails. Eventually, to test our DMARC settings, we’ll try to send spoofed emails with this email address. Back on the Sender Authentication page, we click Verify a Single Sender.

We complete the form with contact information for the email address that we want to verify. Then, we click Create.

After completing this step, SendGrid will run its verification process and add the email address to the list of verified senders.

Step 4: Configure DMARC

With everything set up in SendGrid, let’s see how different DMARC settings affect our deliverability.

Most permissive, least secure policy: p=none

The data value for the DMARC TXT record must always begin with v=DMARC1. For our first go-around, we’ll set p=none, which means “take no action, even if DKIM or SPF fails.” Our TXT record will look like this:

To test this, we send an email from sender@codingplus.coffee, but we use a different SMTP server. Since we are using the most permissive DMARC policy, our test recipient receives the email. When we inspect the raw headers for the email, we see some interesting things:

Our receiving email server performed authentication checks on the inbound email. We see dkim=pass, which means the outgoing server properly signed the email; the content hasn’t been tampered with. However, we see spf=fail because we are sending email from an SMTP server that is not in the list of permitted servers (which only includes sendgrid.net) in our SPF record.

Because SPF failed, we have dmarc=fail. However, the email was still delivered because our policy was to take no action on failures.

Add reporting emails

Let’s modify our settings to see DMARC reporting emails when failures occur. There are three segments we can add to our DMARC TXT record:

• rua=mailto:recipient@example.com sets the email address that should receive aggregate reports of DMARC failures.
• ruf=mailto:recipient@example.com sets the email address that should receive a forensic report on every DMARC failure.
• Optional: ri=<integer> is the report interval (in seconds) for aggregate emails. When not specified, the report interval defaults to 86400, which is the equivalent of daily reporting. For example, adjusting this value to 259200 would result in aggregate reporting every 72 hours.

We’ve adjusted our TXT record to look like this:

We send another test email using our non-SendGrid SMTP server. Our policy (p=none) has not changed, so we still expect the email to be delivered despite the SPF failure. However, we would expect to receive a DMARC forensic report on the DMARC failure.

Quarantine on failures

Next, we’ll adjust our DMARC policy to quarantine emails that fail. To do this, we change p=none to p=quarantine. When using a policy other than p=none, it’s recommended to include the pct segment. This specifies what percentage of DMARC-failing emails should have the policy (in this case, quarantining) applied. When not specified, pct defaults to 100.

Let’s adjust our TXT record value. The data value now looks like this:

Notice that the quarantine policy was applied.

What happens if we adjust pct to 50? We would expect that roughly half of the DMARC-failing emails would be quarantined. After adjusting our DMARC record, we sent two test emails. One of the emails went to the spam folder, while the other one was delivered to the inbox.

Reject on failures

Finally, let’s set the DMARC failure policy to p=reject. We’ll also set pct=100. Our updated TXT record looks like this:

Our spoof email was rejected and blocked! It looks like our p=reject policy is in effect.

DMARC Monitoring

However you set your DMARC policy, monitoring those email reports is important—from today until you stop sending emails from your domain. That means checking those forensic reports for surprises: Are other members of your organization sending mail? Are bad actors trying to spoof your domain? Are valid emails failing SPF, DKIM, or DMARC checks?

Once you get the hang of DMARC on your domain, moving your policy from p=none to p=quarantine or p=reject is a worthy upgrade – and a mandatory prerequisite before you can add BIMI. But parsing through XML files to figure out everything going on with email sends from your domain can get old.

One way to streamline your DMARC monitoring is with a DMARC service that helps you implement, manage, enforce, and monitor your DMARC policies. SendGrid is partnered with Valimail for DMARC monitoring – their DMARC Monitor tool is free for Twilio SendGrid customers.

You can learn more about DMARC monitoring in this post.

Conclusion

Protecting your domain’s sender reputation is essential to email deliverability. Implementing DMARC (alongside SPF and DKIM) improves your sender reputation, and it helps protect your domain from attackers who might try to spoof emails to look like they’re coming from your business. 

As we’ve seen, implementing DMARC is straightforward. You might start with a p=none policy to slowly get accustomed to DMARC and understand how reporting works. With time and careful monitoring, you can tighten things up by transitioning to p=quarantine or even p=reject, perhaps with a gradually increasing value for pct. And as I’ve mentioned, there’s a bonus waiting for you – to add BIMI and a verified brand logo next to email in your recipients’ inboxes, you will need a policy to quarantine or reject emails that fail validation.

But before tightening your policy too quickly, you need  to allow for the possibility of legitimate emails from your domain that don’t pass DKIM or SPF. For example, if a sender used a different SMTP server but you haven’t updated SPF to include that server. Eventually, you’ll arrive at a policy and an enforcement percentage that matches your business’s unique needs and quirks.