What a DMARC rollout looks like

DMARC is a standard that helps protect your brand and your email recipients from phishing and email scams by verifying that all emails from your organization’s domain really came from you.

There’s a lot that’s been written about how to implement DMARC on a technical level (tl;dr: it’s one DNS record) but it’s harder to get a “know before you go” sense of what rolling out DMARC will look like for your organization.

Since the point of DMARC is to gain centralized control over who’s sending emails from your domain name and to prevent unauthorized emails pretending to be from you, you’ll likely need to do some prep work in order to track down where you’re sending your own mailings from. Otherwise you may inadvertently start treating your organization’s own authentic mailings as untrusted — and start landing in your members’ spam folders, if even that.

This may seem like a straightforward task, but you may have some surprises when you start tracking down all the places your mails are actually coming from. More on that below.

Technical background

To implement DMARC, your organization’s IT team needs to publish a special type of DNS record that recipients’ email platforms can then reference whenever they get a mailing from your domain. That DNS record contains a configurable policy telling platforms what to do if they receive a mailing that fails authentication (SPF and/or DKIM)

The policy can be either:

• “quarantine” (which sends all suspicious messages to the recipient’s spam folder)

• “reject” (which prevents suspicious messages from being delivered at all)

• There’s also a special “none” policy, which allows all messages to go through to the recipient’s inbox even if they are suspicious.

DMARC also allows you to tell email providers where they should send reports about the mailings they receive. Those reports include details like what IP addresses the mailings were sent from and whether they passed the authentication checks.

This allows you to collect activity in a centralized location and review what (or who) is sending email that claims to be from your domain.

Combined with the “none” policy, these DMARC reports provide a first step toward stricter enforcement. Turn on DMARC without enforcement, monitor the resulting reports, fix configuration issues as you see them, and then eventually roll out a “quarantine” or “reject” policy.

Rolling out DMARC

This is all pretty straightforward to implement technically, but you’ll want to allocate at least a few weeks to roll it out gradually, and possibly more if your organization uses a lot of email delivery platforms and/or doesn’t have highly centralized IT management.

That’s because you’ll want to be confident that all the mailings your organization sends are passing email authentication before you turn on DMARC with a “quarantine” or “reject” policy — otherwise your subscribers may suddenly stop receiving your own legitimate mailings.

If you’re sending mail with a bulk mailing platform like ActionKit, EveryAction, Action Network, Luminate, or Engaging Networks, you’re almost certainly already set up with SPF and DKIM, so you’re fully DMARC-compliant … for all your bulk mailings sent by that platform.

But you probably have other platforms that are also sending mail from your domain, and you’ll need to make sure that all of them are using SPF and/or DKIM too. You can do this pretty passively using DMARC’s monitoring features.

So, basically, the process of rolling out DMARC looks like this:

1. Sign up for a DMARC monitoring service so that you can see what messages are being sent from your domain, and which of them are passing the authentication checks. (Personally, we use & recommend DMARC Digests — it’s very user-friendly and quick to get started. It costs $10/month. Lots of people also recommend dmarcian, and here’s a comprehensive review of a bunch of DMARC monitoring services published by Postmark, the authors of DMARC Digests.)

2. Publish a DMARC policy of “none” via your DNS records, and start collecting data.

3. Log in to your DMARC monitoring service at least once per week and see what percentage of your mailings are DMARC-compliant.

4. Your monitoring service will also tell you which of your services are not DMARC-compliant. For each of those, work with your IT team and the service’s technology provider to update your DNS records and application configuration so that it becomes DMARC-compliant with valid SPF and/or DKIM signatures.

5. Repeat until all you’ve caught all your email-sending services and are confident that they are all compliant.

6. Adjust your DMARC record to a stricter “quarantine” or “reject” policy.

7. Continue to occasionally monitor DMARC activity in case someone at your organization signs up for a new service that sends email.

Tracking down your email services proactively

The catch in all this is that DMARC monitoring can only ever know about services that are actively sending email. If you have some services that are only used once every few months, but you plan to roll out DMARC in a shorter timeframe, you may not notice that you’re using tools that aren’t DMARC-compliant.

And if those sporadically-used services are very important — like a quarterly high-dollar donor newsletter sent from a dedicated marketing platform, or grassroots lobbying messages that your organization is passing on to government officials — then you’ll really want to make sure you catch them before it’s too late!

For that reason, especially if you don’t have centralized IT management, we recommend also thinking proactively about what services you use.

To get you started, consider whether you’re using any of the following in addition to your primary bulk mailing platform:

• Google Workspace // G-Suite

• Other advocacy tools that you use alongside your main bulk mailer, like Control Shift, Quorum, or New/Mode

• Press outreach tools like Meltwater

• Event or conference tools like Cvent

• Newsletter systems like Mailchimp that you use for specific audiences

• Wordpress (Do you have any contact forms that send after-action emails or notifications? Do you have a site that allows end users to register for accounts that require email confirmation? Do your admins ever forget their passwords and need a new one sent to them by email?)

• Salesforce (Does your development team you send any one-on-one emails to donors from Salesforce? Do you use Salesforce marketing tools like Pardot?)

• Shopify (Do you send email receipts to people who buy your merchandise?)

• Zapier (Do you have any automations that trigger emails to your staff and/or your supporters?)

Some email-sending services don’t try to send their emails from your domain at all, but instead just send messages from their own domains on your behalf. These are fine to leave as-is and don’t need to be adjusted for DMARC compliance.

We also recommend polling your organization to make a list of all business software that team members interact with on a daily, weekly, monthly, and quarterly basis. This can help you catch those sporadic-but-essential services.

And if you have access to your domain’s DNS records and/or monthly/annual recurring charges on your credit card statements, those can be helpful too.

As you identify these services you can work with your IT team and vendors to get valid SPF or DKIM records set up so that those emails pass your DMARC policy and get delivered going forward. It’s a lot of rinse and repeat.

Should I really bother?

On top of the security and monitoring benefits that DMARC provides and potential but ambiguous boosts to deliverability¹, a DMARC rollout also opens the door to some other engagement-boosting opportunities like BIMI and AMP. We’ll talk more about these in future posts!