DMARC with a Startup, Few Mail Source

The smaller business deployment scenario

You’re a small business that is growing in your market. Sending out emails regular about new offerings, reminders for current customers, billing information and staff communications too. How do you roll out DMARC without disrupting any of this?

There are 3 steps in the process: Recon, Implement, Enforce

Recon

The very first thing we're going to do, is publish a DMARC record. You're probably thinking, "Wait! I haven't done any preparation for this at all!?" and that's because you don't need to. A DMARC record with a p=none; policy will have no impact at all on your current email delivery. The one thing it will do, is help you gain information about what is currently going on in your email system. Part of the specification allows you to set an email address that will receive daily aggregate activity reports from email servers that receive email claiming to be from your domain. These can come to you personally or you can have them sent to a service that can help visualize the reports for you.

When I started this back in 2012, there weren't any tools to help read these reports so I just read them directly. If you don't have a lot of email sources then this approach should be fine because the reports aren't very hard to read. Let's take a look at one of the reports now.

<record>  
  <row>  
    <source_ip>207.126.144.129</source_ip>  
    <count>237</count>  
    <policy_evaluated>  
      <disposition>none</disposition>  
    </policy_evaluated>  
  </row>  
  <identities>  
    <header_from>slimmeryetimbers.com</header_from>  
  </identities>  
  <auth_results>  
    <dkim>  
      <domain>slimmeryetimbers.com</domain>  
      <result>pass</result>  
      <human_result/>  
    </dkim>  
    <spf>  
      <domain>slimmeryetimbers.com</domain>  
      <result>pass</result>  
    </spf>  
  </auth_results>  
</record>

Every IP address in the report will produce a <record> entry for the <source_ip> of the mail server that delivered the email claiming to be from you. You can see the <count> field indicating how many emails were received from that particular IP address as well. This is why it doesn't matter how much email you're sending. If that number is 10 or 20,000,000 the size of the report doesn't change for you.

Next you'll see the <policy_evaluated> which gives a short summary of the state of your DMARC record at the time these entries were processed. We can see here that our <disposition> was none reflecting the p=none; policy in our DMARC record.

Next, you'll see the <header_from> which indicates the domain name found in the email that triggered this action.

Lastly, we'll see the <auth_results> which tell us whether our mail from this IP address passed the DMARC <dkim> and <spf> checks. We can see the <result> is pass for both here.

So, select the email address where you want to send reports, such as dmarc_rua@slimmeryetimbers.com and publish the following DMARC record (with your chosen email address instead). You'll publish it to your DNS as a TXT record on the _dmarc subdomain of your domain, so _dmarc.slimmeryetimbers.com in our example. RUA indicates where to send the "aggregate" reports, which summarize daily activity.

"v=DMARC1; p=none; rua=mailto:dmarc_rua@slimmeryetimbers.com;"

Keep in mind, you will not get a report from every mail server that gets email claiming to be from your domain. More and more companies will provide DMARC reports. Some other enterprise providers, like Proofpoint, have the capability of producing reports but it's turned off by default.

Implement

Our goal with these reports is to discover all of the email sending sources that belong to us and work towards ensuring that both SPF and DKIM are passing for all of them. Now that we are collecting daily reports, we need to identify our various email sources. Let's look at our hypothetical email sources for Slimmer Ye Timbers.

• Class schedules and reminders - Assume something like Sendgrid or Postmark

• Newsletters - Usually Mailchimp or Constant Contact

• Billing information - Probably Square or Clover

• Company Email - Let's assume Google Workspace

Now, the first thing we want to do before we even bother trying to isolate each of these in our reports is to check with each provider to see if they have instructions for setting up SPF & DKIM. These technologies have been around for a while and DMARC is going on 10 years. Any business that provides an email service is going to be well aware of them, should have instructions somewhere and very likely already made you set it up without you even knowing about it.

Let's try to find the pages for all of the above providers by Googling "setup spf and dkim with ..."

• Sendgrid - Explanation of SPF & DKIM which they automate

• Postmark - DKIM | SPF takes some additional steps, which they explain here

• Mailchimp - DKIM & SPF are handled through the authenticate domain process

• Constant Contact - DKIM | SPF

• Square - Couldn't find anything.

• Clover - Couldn't find anything.

• Google Workspace - SPF | DKIM

After some quick Googling, we found instructions for almost all of them. If no instructions are present, it's entirely possible that setup may not be necessary. For example, Square and Clover may opt to send payment receipts directly from their own system rather than from your domain. After a quick look in my email, I can verify that is the case as well by finding a receipt from a company using Square from invoicing@messaging.squareup.com. We only need to setup SPF/DKIM/DMARC for mail that is sent from our domain.

Some services will make this optional as well. Constant Contact, for example, will send using their domain by default but encourages their customers to setup their own domain in order to build up their email reputation over time. If given the option, always set up your own domain.

Now, as we go and follow the instructions for these companies you will notice that you are creating both SPF and DKIM records.

In most cases, there will be multiple DKIM records and each record will have it's own unique subdomain. Usually something like em1234._domainkey.slimmeryetimbers.com as a CNAME record or a TXT record. If you're provided with a CNAME record, it's because the provider will automatically handle DKIM key rotation for you. If you're provided with a TXT record, it's a key that you'll need to make a note to rotate periodically. If you can find an alternative provider that gives you a CNAME option, I would strongly recommend it so that you never have to think about this again.

For SPF, you may see records that appear to overlap by creating TXT records. Usually it will appear to be a complete SPF record that has some form of include:_spf.google.com indicating the provider domain name. The include record here is actually just like a CNAME and you can combine SPF records by just putting everything in the middle together. For example, if you were using both Protonmail and Google each one would have told you to create an SPF record like this:

# Protonmail
v=spf1 include:_spf.protonmail.ch ~all

# Google Workspace
v=spf1 include:_spf.google.com ~all

We don't want to create two SPF records on the same subdomain or it will cause an error when mail servers try to check. Your root domain slimmeryetimbers.com can only have one SPF record, so we need to combine these to use both services. To do that, we just combine the parts between the v=spf1 and the ~all, like so...

v=spf1 include:_spf.protonmail.ch include:_spf.google.com ~all

Each include record let's that provider update the associated IP addresses for the service just like the CNAME on our DKIM keys. If we keep adding too many includes to this record, it could also become invalid because there is a 10 lookup limit. Ideally, each service we're sending email from should be on its own subdomain except for our primary corporate email. We saw our Square email earlier came from messaging.squareup.com and this is the right idea. Some transactional email providers (like Sendgrid, Mailgun, etc) will force this by only allowing you to use a subdomain. We'll talk about that more in our Enterprise section.

One thing to remember when you're setting up your SPF record is what the [+,~,-]all at the end means. This is an indicator of how strictly to enforce the record itself and there are 3 options.

• +all allows any IP address to pass your SPF check. You should never use this. Ever.

• ~all will softfail an IP address that doesn't match, which will flag the IP address as not passing but defer any suggestion of what to do

• -all will strictly fail an IP address that doesn't match and tell the mail server to discard it

Out of all of these, you should only be using the ~all to softfail mismatches. As we've discussed, SPF doesn't survive forwarding because it changes the IP address. Strictly enforcing this rule with -all could result in legitimate messages not being delivered. With the softfail, the final decision will fall to our DMARC policy.

After making all of these changes, we're going to wait a couple of days for new DMARC reports and then review them to try to see if we can figure out whether everything that's supposed to be passing is actually passing. This is the point in the process where we hit a loop. No matter how many potential email sources you have, you're going to gather reports, make adjustments, then wait for new reports to see if they worked. Rinse and repeat this process until you feel confident that everything that should be passing is passing.

If you don't want to review the reports yourself and you would prefer to use some type of tool to help with the job then you have come to the right place, because we will be launching ours soon!

It's possible that by reviewing reports, you'll find things that you didn't know about. It's also entirely possible that you'll find a lot of mail that isn't yours at all! Most people do. Sometimes as much as 80% of the traffic claiming to be from your domain isn't real at all.

If you discover IP addresses sending legitimate email traffic, usually a web server, you have a couple of options. You can either add the IP address to your SPF record and configure it with it's own DKIM key or you can configure the server to send email through an email provider that you've already configured, like Sendgrid or Postmark. I'd strongly recommend the latter option, because it reduces your overall email footprint and gives you one less thing to keep up with. Most providers will have guides to configure server tools like Sendmail to deliver through their email servers. Websites built with Content Management Systems like WordPress usually have plugins available to allow you to deliver email through these services as well.

With the state of email today, it's generally a best practice to avoid having individual servers sending email unless you're committed to maintaining them. Each IP address that sends will be tracked an given its own reputation score overtime that is used by spam filters.

Enforce

Once you are confident that everything which should be passing in the reports is actually passing, it's time to enforce our rules. We also want to apply this enforcement very carefully, just in case despite all of our efforts, there was an unexpected problem. As it turns out, DMARC even makes this easy.

First, you're going to let your support staff know that you're going to begin enforcing the DMARC policy. Let them know that you don't expect anything to happen, but if they start hearing from customers that people aren't seeing an email they expect to see then ask them to check their spam folder. Then tell you immediately.

Next, we're going to enforce our policy by switching to the p=quarantine; setting...but only for a small percentage of our email. That's right, there's an optional DMARC argument that will let you request the policy only be enforced on a specific percentage of email which allows you to slowly ramp up the enforcement so that you can back off if you start hearing about problems. We'll start with 10%.

"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc_rua@slimmeryetimbers.com;"

And now we wait. Let it run this way for a day or two, see if anything is missing. Touch base with support to see if they have any reports of missing email that ended up in "Spam".

If there are no problems, we increase the percentage to 20%.

"v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarc_rua@slimmeryetimbers.com;"

And wait again. Still no problems? Move to 30%. Then 40%. Then 50%.

At the point you hit 50% and you're still not experiencing any issues we should feel comfortable that everything is working as expected. From here you can either keep slowly increasing the percentage per day or go ahead and jump straight to 100% by removing the pct entirely.

"v=DMARC1; p=quarantine; rua=mailto:dmarc_rua@slimmeryetimbers.com;"

Now every message that doesn't pass our DMARC checks should be going directly to the spam folder. Let this simmer for a week or two. Check in with everybody you know to be sending email from different email tools just to make absolutely sure things are working as they should.

At this point, it's time to move to the final phase: p=reject;

"v=DMARC1; p=reject; rua=mailto:dmarc_rua@slimmeryetimbers.com;"

Now, any mail that doesn't pass our checks but claims to be from us won't be delivered at all. This is where we want to be.

p=quarantine; is Not Enough

Even more, with the reject policy in place no new tools that we setup to send email on our behalf will work until we've set them up properly with SPF and DKIM. That will help us make sure that nothing sneaks in unexpectedly.

How could that happen? Let's say you're growing so much that you hire someone to handle marketing. Without telling you, they might sign up for an email service that they've used at a previous job. If you have a p=quarantine; policy setup this tool will still deliver successfully, while your new marketing person may just wonder why the messages are going to spam. They could even start asking customers to "add us to your contact list to get our emails!" and this is all bad advice. If the messages don't get through at all, they know something isn't setup right and must ask for help to get it setup correctly.

In a much larger enterprise this problem gets multiplied into what's called Shadow IT, where 3rd party services are setup without the knowledge or approval of your IT team. But with your p=reject; policy now in place, the long term maintenance of your email rules becomes a virtually automatic process. Because it has to...otherwise it won't work.

That was easy

All of that may seem like a lot of detail, but let's think about what was really involved?

• Recon: We setup p=none; record so we could collect reports

• Implement: We reviewed the reports while we made sure everything we found was setup with aligned SPF and DKIM

• Enforce: We slowly turned on our DMARC policy after we knew everything was setup correctly, just to make sure we didn't miss anything. Eventually, we reached full p=reject; enforcement!

Not bad.

This article was originally published on as part of a 3 part DMARC Guide at Brightball.