I feel very strongly about the goals, approach and possibilities of this project but ultimately right now it is a project that I’m working on between a number of other responsibilities, including my primary consulting work at Brightball, running the Carolina Code Conference and family responsibilities. In short, I just haven’t been able to make the time to get this project to a point where I’m ready to open it up just yet.

Subscribe now

There are some big changes coming for my family in 2025 which I’m optimistic could free up as much as 2-3 hours a day. I hope to be able to invest that time to get dmarcSTAR to the standard that I’m comfortable releasing with the tooling needed to effectively maintain and support it afterwards. As you can probably imagine, with this being my first solo launch I’m holding it to a high standard.

But it is coming.

Happy New Year!

I’ve worked heavily with DMARC since 2012, directly on implementations, as a speaker and advocate fully immersed in the industry. During that time I have seen a number of different approaches to the technology, but never a platform that approached the problem in the way that I would.

So I’m building it and it’s almost ready.

The goals

1. Significantly Faster DMARC Deployment Projects

2. No long term dependence on a service (SPF Flatteners, DNS Delegation, etc)

3. Clear plan and process for long term maintance

4. You should be able to show up, get to p=reject and then close your account if you want. If you choose to hang around after p=reject, the value proposition will be clear and your costs will be reduced.

If you want to take it for a test drive during the private beta or you just want to keep track of progress as we get closer to launch, subscribe here!

Subscribe now

If you’re not familiar with DMARC, you can read more about it right here!

Where does the name come from?

I’ve been obsessed with the SR-71 Blackbird for most of my life. I have made trips to see it in a museum, had posters in my room growing up, I’ve read stories from former pilots and strongly recommend the book Skunk Works for any other enthusiasts.

That plane is one of the most incredible innovations of our time and it’s a technological inspiration. It’s also really fast, able to maintains speeds over Mach 3.5 at an altitude of 85,000 feet.

When Top Gun: Maverick was released in theaters it included a test flight of a fictional plane (as far as we know), which is the spiritual successor of the SR-71, to maintain hypersonic speeds of Mach 10. The Lockheed Martin Skunk Works even designed it!

The name of that plane is, the Darkstar. So when it was time for a tool to deploy DMARC at hypersonic speeds, dmarcSTAR was born.

Taking flight soon. Hope to see you on board.

If you visit dmarcian's public DMARC Data Providers report, you can inspect the volume of reports sent by different email providers. You'll notice the absence both Microsoft and Proofpoint if you search the results. The fact that these two companies play such a huge role in the global email space while refusing to participate in one of the most important aspects of its security needs to be called out more often.

Sean Whalen, a consultant, wrote about both of these issues in detail, including workaround guides. Proofpoint initially tried to force customers to pay for their Email Fraud Defense service just to get aggregate reports from their own email gateway, but have since rolled the option into Proofpoint Essentials as a setting for an administrator to turn on. Microsoft claims to support sending reports as a Public Preview feature, but none were visible in dmarcian's public report. DMARC is a decade old and widely adopted at this point. There's really no excuse for the actions of these two.

But there are consequences. If your company is using an email system that doesn't provide reports and you have an email system that only sends emails internally, it won't show up on the reports at all. So it's invisible.

Sean came up with a way to work around this situation with Proofpoint in his above article:

Ulrich Baum, a DMARC consultant from RedSift shared a client story on LinkedIn about this exact situation.

The good news is that a situation like this is only likely to happen with internal projects as described above. Email sent to customers will likely be delivered to a variety of mail servers, some of which will provide proper reports. Sean's workaround is a great way to expose this problem on your own email gateways.

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

Scale does come with it's own implementation challenges, so let's start with the most well known.

Overcome the SPF 10 Lookup Limit

When a mail server tries to verify that a message passes SPF, it contacts the domain DNS to look for the SPF record and checks to see if the IP address of the server that sent the message exists within the record. This could mean directly listed IP addresses, ranges of IP address or include: entries which list another domain name that contains another list of IPs.

Every time another DNS query must be performed, it adds to the "lookup count". If you're using Google Workspace and included _spf.google.com in your top level SPF record you may think that's only 1 lookup. By querying that record though, we will see that it contains 3 additional lookups.

"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

These all consist of IP address ranges without any additional look ups. Here's _netblocks3.google.com as an example.

_netblocks3.google.com.    300    IN    TXT    "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

That means that by including _spf.google.com we've added 4 lookups to our SPF record and that's only for our corporate email account! What happens when we start adding all of those other services?

Exactly. You'll quickly go over the 10 lookup limit if everything gets added to a single SPF record. Which is why you aren't supposed to have a single SPF record. Each subdomain can and should have it's own SPF record. If a record isn't present at the subdomain then the lookup will bubble up to the root domain.

The easiest way to think about this problem is in terms of what services are being performed. Let's use our pirate gym, Slimmer Ye Timbers as an example.

• newsletter.slimmeryetimbers.com - Marketing newsletters

• invoice.slimmeryetimbers.com - Invoicing systems

• classes.slimmeryetimbers.com - Class schedules and reminders

• receipt.slimmeryetimbers.com - Transaction receipts

• it.slimmeryetimbers.com - IT department systems

• hr.slimmeryetimbers.com - HR department and tooling systems

• sales.slimmeryetimbers.com - Sales tools like CRM systems

• mail.slimmeryetimbers.com - General website emails

Any of these could be further broken down if needed. The point is that there's no need to try to cram everything into a single top level SPF record. As a bonus, you gain a number of benefits by using subdomains.

SPF Isolation and Error Containment

One thing many people don't realize is that a broken SPF record will invalidate your entire DMARC policy. If mail servers see you have an enforced DMARC policy setup, but also see that your SPF record is broken the error will force them to act as if you have no DMARC policy at all.

By isolating each SPF record on its own subdomain, you contain the damage from a broken record to only that subdomain.

You may be wondering how an SPF record could break after it's been setup correctly? One of the dangers of include: is the potential for change by the vendor.

Just as an example from 2012, we were using a vendor to manage sales channel communications. Not knowing any better, we added their include: record to our top level SPF and everything was working great. We had a fully implemented p=reject; policy and our phishing complaints had basically stopped at that point.

One day, all the phishing complaints started back again suddenly. And worse yet, the phishing emails were using our domain again. We hadn't touched anything with the email system so we couldn't understand what happened.

After inspecting all of our records, the Kitterman SPF Testing Tool helped us discover that our SPF record was broken. The sales channel communication company switched which domain they were using for include records and the old domain was no longer valid! This change invalidated our entire SPF record and the rest of our email policy along with it.

If the CRM tool had been on its own subdomain, only that tool would have been affected by a change outside of our control. We didn't know about the change because the email notification about the change only went to the person at the company who signed up for it in the first place. And they didn't pass it along.

The above scenario also underscores the benefit of long term monitoring for changes in your SPF records.

You don't need "SPF Flattening"

There are tools out there which provide a service called "SPF Flattening", which monitors your SPF record for changes and compresses it into the minimum possible number of SPF lookups. You have to pay for the service and it can still outgrow the 10 SPF lookup limit.

You don't need these services. You need subdomains.

No single service can function if it alone would outgrow the SPF lookup limit. By simply isolating each service on its own subdomain, you have "limit proofed" it against this problem.

The only potential benefit to an SPF flattening service is error insulation from 3rd party changes. If the flattening service does error detection against changes in the SPF record and refuses to publish any change that would cause an error, your tooling would be insulated against those 3rd party errors. That's a good thing.

However, it's only a short lived protection. Eventually the error has to be resolved or the flattened records may no longer be valid. A decent flattening service should notify you of these types of errors so that you can correct them.

If an error preventing cache buffer sounds worth the cost to you, then maybe it's worth it. Don't depend on the SPF flattener to prevent your longer term lookup limit issues. You're still better off with subdomains even when using a flattening service.

Return-Path and Subdomains

Both SPF and DKIM have an option in your DMARC configuration to allow both "strict" and "relaxed" (default) mode. In relaxed mode, the Return-Path used to send email bounces can use a subdomain while still showing the visible From: domain as only the primary root domain. There are examples included in the DMARC specification.

Most servers will configure themselves in the Return-Path by default, so if you have 1,000 servers like web1.slimmeryetimbers.com or api3. or mail7. or staging3. they can also still send DMARC aligned emails for the root domain, @slimmeryetimbers.com while using subdomains. An SPF entry referencing that server IP on the web1. subdomain will allow messages from that domain to pass an aligned SPF check without actually having to send email From:name@web1.slimmeryetimbers.com which might not be visibly appealing.

This illustrates why, no matter how big your organization may be, no matter how many servers you have, subdomains will scale with you without growing your total lookup limit.

You could certainly reorganize the above example for simpler management by publishing them under a grouped subdomain, like web1.it.slimmeryetimbers.com. Then an SPF record could be posted on it.slimmeryetimbers.com with an IP range including the scope of the servers underneath it rather than adding and removing individual IP addresses.

Subdomains for Project Scope

One thing that people often forget is that subdomains themselves are just like the primary domain. Each subdomain can have it's own _dmarc. entry if you want. It can have it's own set of DKIM keys under _domainkey. as well.

Which means you can have a different email address to collect aggregate reports from DMARC report providers on each subdomain, just as if another domain entirely was being used.

And that means that your organization can have multiple DMARC deployment projects if needed. You can let HR roll out DMARC on it's own schedule while the rest of the company gets setup for p=reject; on the main project, for example.

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

Differences in priorities will color a great deal of the perspective on DMARC within an organization. A lot of experienced people will tell you that security comes last in many organizations. In some cases this is by necessity rather than negligence, as there's often only so much budget to go around and a lot of competition to capture market share. To get DMARC setup, just getting the project approved in the first place will take some doing. Here's a few things to know that will help.

Government Requirements for Legal

The Department of Homeland Security (DHS) 18-01 Binding Operational Directive required all federal agencies to have a DMARC policy of p=reject by October 16, 2018. 74% of agencies did it in time according to a report from Agari. Similar requirements happened in the UK in 2016. The Dutch government went so far as to add DMARC to their email standards checklist that's part of the "Comply or Explain" list for business operations in the country. Businesses can depart from the compliance requirements, but they must provide a written explanation to justify the course of action. More an more it's becoming a baseline expectation of doing business, particularly with government agencies. Adoption is being pushed heavily across the US, EU, Japan and more.

It's probably only a matter of time before DMARC is folded into security standards like SOC2 Type II and ISO 27001.

Business Email Compromise (BEC) for Executives

The executive team will probably respond to BEC, also known as Spear Phishing or Whale Phishing. BEC scams target financial departments at companies by having those companies issue checks and vendor payment through social engineering. These scams work because the criminals are able to successfully impersonate company executives. Often times an entire fake email chain will be created that appears to be a multi-day conversation between an executive and a fictional vendor wondering why they haven't been paid. The executive will then forward the entire email chain to the finance department to get these people paid promptly. It's believable because, via email, these executives can be impersonated if the protections aren't in place.

You read something like that and your first thought it, "that could never happen" but these scams are responsible for $12.5 billion in losses from 2013-2018 according to the Global Cyber Alliance. How accessible is your CEO for a verification phone call if you were to receive an email like that, particularly from their company email address? It's easy to do without DMARC in place. Even with DMARC in place it can and does still happen, but perpetrators have to convince you they are the same executive but on a personal email account with Gmail or some other provider. It's much easier to spot. Many email and service providers like Greathorn and Google provide tools to help warn people about them...but those tools can't do anything about messages that come from the corporate email domain.

BIMI is a Carrot for the Marketing Department

Is it probably necessary at a large company to get the marketing department on board? Yes. Because marketing might fight you on setting it up. I've spoken about DMARC during an email marketing conference and had the conversations first hand. This will sound harsh, but your marketing department probably does not care at all about email security. What they care about are delivery, inbox placement, open rates and clicks. A DMARC project will likely scare the marketing folks more than anything as they wonder and speculate about a potential negative impact to these metrics. DMARC won't hurt these at all. If anything, it helps protect the brand by making it more difficult to impersonate.

And many will go as far as fighting against the DMARC deployment because of it. After all, what's in it for them? Well, now there's something for them too.

Once DMARC has been rolled out successfully you're eligible to setup Brand Indicators for Message Identification (BIMI), which will allow a trademarked logo to appear next to your emails right in the customer inbox. So far, it's supported by Gmail, Yahoo, AOL and Fastmail.

As a person try to improve security for your company and your users, you may be wondering if this has any positive impact on security by providing some type of reassuring trust indicator next to the email. This, unfortunately is a resounding, "No." Users do not respond to trust indicators because there are so many messages and websites they come across that do not have them. Because of that, users simply ignore missing indicators.

As a parallel you may remember Extended Validation Certificates security certificates. Companies paid a lot of money to go through a validation process that would turn the address bar in the browser green if they'd been validated. These were completely ineffective. The same certificate authorities who validated EV certificates are the Mark Verifying Authorities (MVA) doing the validation for BIMI to get you a Verified Mark Certificate (VMC). A 2018 study presented at M3AAWG also revealed no impact (positive or negative), aside from more email senders contacting email providers asking how they could get the indicators too.

BIMI is the Make My Logo Bigger Cream of email. It's a dangling carrot, but if it gets marketing on board with the project and it does no harm it is probably worth it for the overall security improvement. You still have to fully deploy DMARC first.

Reigning in Shadow IT for Security

One of the biggest struggles that IT and Security teams deal with at large companies is Shadow IT. Shadow IT happens when employees start using devices, tools and services that have not been approved by the company to meet with various internal standards and compliance.

Now, it's important to remember that Shadow IT rarely comes from malicious intent. The cause is traditionally an expected very high barrier to approval, numerous hoops to jump through or long timelines from IT itself which encourage people to go around IT to get their jobs done. Shadow IT is often a symptom of a process problem.

All that said, DMARC reports provide real insight on the scope of this problem within your organization. If you start collecting reports with dozens of legitimate 3rd party services that haven't been approved...you have a problem.

Does private data exist within these tools? Employee data? Customer data? Is PII collected? How are logins managed? Is access being removed during employee turnover? Are their legal or audit implications?

By knowing the tools exist, you gain the ability to get their usage documented, approved, secured properly and rolled into more polished company process. If you're unable to find out who's responsible you can always use the time honored IT sleuthing process of unplugging it until somebody complains. Enforcing your DMARC policy will have the same effect.

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

Previously, we talked about DMARC deployment in a startup or smaller organization where you probably know all of the different places you're sending email. Now put yourself in the shoes of an enterprise that's 40+ years old, has hundreds or thousands of servers.

Many servers could be sending email directly. Some departments could have built their own tools while others are using 3rd party services. The company could even have many different domain names in use for all of these different tools. Has the company grown through mergers or acquisition?

There's no telling what the scope of your project could be in a larger company. Luckily, DMARC is built to help with this problem. You start with the Recon step, setting a DMARC p=none; policy on each known domain so that we can gather reports.

Maybe as the project goes on, you discover new domains. Just add that record and start collecting reports. You'll probably want some type of service or tool to collect these for you to help make sense of what is in them...but the deployment process is exactly the same.

We discover services and IP addresses being used by our domains and we work on our implementation to make them both SPF and DKIM compliant. We make them compliant by finding out who has access to these tools, look up the relevant implementation steps for SPF and DKIM, then apply them. Or we consolidate delivery by routing multiple servers through a more centralized and compliant company email service.

Rinse and repeat, until everything is compliant and then we enforce our policy. In an enterprise there will be more communication, more people involved and a bigger project to manage...but it's all achievable.

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

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.

Go and and setup a simple SPF and DMARC record to disable all email for the domain until you're ready to use it. That way, you can ensure nobody else is using it for you in the mean time. This is the "Only you can prevent forest fires" of the email world. Listen to Smokey Mail.

Go to your DNS and add these two TXT records. Take a look at dig TXT slimmeryetimbers.com and dig TXT _dmarc.slimmeryetimbers.com as an example.

slimmeryetimbers.com.        100 IN TXT "v=spf1 -all"
_dmarc.slimmeryetimbers.com. 300 IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s;"

The first sets an empty SPF record with strict enforcement, meaning no IP addresses are authorized to send email on behalf of this domain. The second sets a DMARC record with a reject policy that tells receiving mail servers to not even bother sending failing messages to spam and drop them entirely instead. The aspf and adkim settings put both into "strict" mode.

Do that on all your unused domains and you're doing your part to make the internet less spammy while protecting your own domain reputation.

There are three policy types, referenced by the p= attribute of a DMARC record.

• p=none;
  We have a DMARC record, but we don't want the rules to be enforced at all.

• p=quarantine;
  Anything that doesn't pass DMARC should be sent to the user's spam folder. This is the lowest "enforced" setting and gives your support staff the ability to have customers check their spam folders if an email they're expecting is missing after turning it on. By the time we get here, you won't need it.

• p=reject;
  Don't even deliver messages that fail DMARC checks. They aren't from us.

The goal is to get to a p=reject; policy for every domain. A lot of people like the idea of sticking with p=quarantine; but this is still a dangerous place to be. Users can set email filter rules that move messages saying they are from you to specific folders and these rules will bypass the DMARC check if it's allowed to be delivered to the spam folder.

If this sounds farfetched, keep in mind that this is standard operating procedure for Business Email Compromise (BEC) scams, also known as spear phishing or whale phishing. These attacks have cost businesses $43 billion since 2016. An attacker will prentend to be a vendor, contacting your financial team frantically asking why an invoice hasn’t been paid. They’ll send an email pretending to be the irrate CEO insisting that this vendor be paid immediately.

In many cases, they’ll direct their victim to the spam folder to find the fake invoice or the fake CEO communication, “Bob told me he was going to contact you last week! Are you sure it’s not in spam or something?” Just sending messages to the spam folder isn’t enough.

Additionally, once you get to p=reject; you'll find that it's easier to keep all of your email rules up to date because nothing new will work until it's been properly configured. This helps prevent Shadow IT too.

The goal is always to get to p=reject;.

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

Let's say you have a great business idea, so you go and buy a domain name. I've always dreamed of opening a pirate themed gym called "Slimmer Ye Timbers!" where people can work on their Arrrms and walk the Planks. The marketing kinda writes itself and be honest, you're a little curious right now.

Anyway, say I go out and buy the domain slimmeryetimbers.com for my website. Then I have to get a hosting company and setup a DNS record to point slimmeryetimbers.com to that web host to so people go to the right place when they visit the domain.

Email doesn't work like that. If I setup a mail server and point to it with an MX DNS record so that people can send messages to my new arrrgh@slimmeryetimbers.com address, it works great. Exactly like running a website and pointing the domain to the right place.

The difference is that anyone, anywhere can send an email to somebody else claiming to be from my fancy new domain. This is why we have spam. This is why we have phishing. By default, anyone can send email claiming to be from any domain that exists.

Arrgh...

DMARC lets you turn it off and control exactly what's allowed to get through, so the only email saying it's from your domain is actually from your domain.

SPF & DKIM

DMARC isn't the first specification to try to fix the spam problem. Multiple others have come along in the past with differing degrees of adoption. DMARC builds on two of them, called SPF and DKIM. Both of these protocols have gaps that are addressed by the other. With DMARC setup, you're telling any mail server that get an email claiming to be from your domain "If this email doesn't pass either SPF or DKIM for my domain, it's not from me and you can discard it (or send it to spam)."

It's important to keep this in mind too. Without DMARC, every email server that gets a message claiming to be from your domain has to make it's own rules to figure out if the message is legit or not. That means running blacklists, IP reputation scores, spam algorithms, machine learning, checking the age of the domain, doing reverse DNS look ups on the IP address where it came from, among other things. Ever been asked to add a business to your contact list? That's why.

Even if you do have SPF and DKIM setup, receiving mail servers have no way of knowing if you have it everywhere so they still have to guess. With DMARC, you're removing the guesswork for them and telling them exactly what to do.

SPF - Sender Policy Framework

The Sender Policy Framework works by publishing a DNS record(s) that lists the IP addresses or domains that are allowed to send email from your domain. All that you need to publish or modify an SPF record is access to your domain's DNS, so it's fairly straightforward to setup. The biggest challenge is identifying everywhere that you're sending email, which DMARC will make easier for you.

Here's an example of an SPF record for your domain, which is just a simple TXT record.

v=spf1 mx ip4:64.18.0.0/20 include:_spf.google.com ~all

This simple record says these IP addresses are allowed to send email from our domain...

• mx allows the servers referenced by our DNS MX records, which points to the email servers that receive email since many will also send email.

• ip4:64.18.0.0/20 allows any IP address in the 64.18.0.0/20 range to send email. We can also specify individual IP addresses. ip6 can be used as well.

• include:_spf.google.com allows us to delegate management of some of our IP addresses to Google, who can update this record whenever things change without us having to worry about it.

The v=spf1 indicates that this is an SPF record since DNS TXT records can be a lot of different things. The ~all at the end covers how strictly to enforce the rule, which we'll talk about in deployment.

When a mail server receives an email from us it will be able to see the IP address of the server that sent it and the domain name it claims to be sent from. That mail server will then check to see if there is a corresponding SPF record and verify that the sending IP addresses exists in this approved range.

SPF has flaws

It's so simple that it makes you wonder why anything else is even necessary, but email is a big world and SPF doesn't cover all of the use cases. If you send an email to a mailing list like a LISTSERV, your email is sent to the server of the list serve itself and then the list serve forwards the message from you out to every address on the list. In this case, the email will come from you but be sent from a server that you have no control over at all which will fail an SPF check.

Another situation is if you send an email to someone who is using a forwarding address, like a collegiate @alumni.university.edu address. The SPF check will fail after forwarding and if you're enforcing SPF too strictly legitimate messages will be entirely lost.

Lastly, an email server which is used by multiple domain names may allow other people to send on your behalf if the owner of the server hasn't taken steps to prevent it.

DKIM - DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) Signatures works by attaching an encrypted email signature to each outgoing message. A private key on an outgoing mail server will reference a public key published in your domain's DNS that can be used by the receiving mail server to verify the signature. Because the signature is based on the body of the message, a failing DKIM check can also indicate that they message may have been modified in transit.

It's more complicated to implement since it has to be setup individually for each sending mail source, but it's more reliable because the signature survives forwarding which fills the gap in SPF. Most 3rd party email senders today will require you to setup DKIM before even allowing you to send an email, but go out of their way to make this process easy for you.

DKIM has flaws too

The biggest flaw with DKIM is that if a mail server receives a message that doesn't include a DKIM signature, it has no way of knowing that there was supposed to be one present. This will lead to treating DKIM as a trust modifier if it's present, but not a dis-qualifier if it's not.

You can see this if you look at the scoring system for a tool like SpamAssassin, which is a popular open source library used to help filter potential spam messages. It uses a scoring system to judge messages based on a lot of different criteria. If a message scores higher than a certain score threshold, it will be classified as spam. Valid DKIM signatures will lower your score, but lack of a DKIM signature doesn't really hurt you.

Sometimes modified emails are good

There are a number of corporate email systems and vendors who provide services that will inspect incoming emails. Sometimes these just scan for viruses in attachments, but others will wrap the links in an email message with a new URL that will inspect the contents and warn you of hazards when you try to click them. These link replacements will invalidate the DKIM signature since the message was modified. Luckily, these systems are usually setup by the entity with the receiving mail server itself so steps can be taken to verify the DKIM signature before the message is modified.

Key Strength Matters

When we talk about using public/private key encryption there's always an associated bit strength to the encryption. 256, 512, 1024, 2048 or even 4096 are what's commonly circulated as of this article. The lower the strength, the easier it will be to crack the private key. This is important because if anybody finds out the private key, email can be sent impersonating the domain and fully pass the authentication checks.

The most famous DKIM cracking incident actually happened at Google thanks to Zachary Harris, Math Pirate. He received a headhunters email coming from Google and thought that the message might have been spoofed, so he looked at the DKIM signature and realized it had a weak 512-bit key. The DKIM standard calls for 1024-bit minimum. He didn't believe that Google would be so careless, so he thought it was a recruiting test and proceeded to crack the key before sending an email to Larry Page from Sergey Brin, Google's founders. 2 days later Google's DKIM key was using a 2048-bit key, but Zachary never got a response.

Key Rotation Matters

When you setup a secure certificate on a website, it comes with an expiration date that will require it to be renewed. DKIM keys have the same need, but it's not required so it's often neglected. Protecting your DKIM private keys is extremely important, otherwise none of this matters. If a DKIM key is cracked in the wild and you don't know about it, the cracked key will keep working until you rotate yours. That means periodically rotating your keys on every outgoing email server that you have, which is going to be tedious if it's not automated.

Luckily, more and more email providers are automating this process for you by providing you with two CNAME DNS records that they can manage for you. This will allow them to change the key on one record while the other is still in use to avoid any disruption to recently sent mail. I know that several already do this, but I'm not aware of a comprehensive list of providers who offer automatic DKIM rotation. Personally, I would go out of my way to avoid providers who don't.

Even if you have a very high strength key, the knowledge of how many years it would take to crack doesn't protect you from everything. A departing employee with privileged access could take the key or leak it. A compromised or unpatched server could allow the key to be stolen. And let's be honest here, if you have IT staff who aren't willing to take the time to rotate those keys how likely is it that the mail server is being properly secured anyway?

DMARC fills the gaps

DMARC builds on both SPF and DKIM, providing clearer rules about their usage while filling their weak spots. Here's how it accomplishes it.

First, the requirement for a message to pass a DMARC check is that it must pass a domain-aligned SPF or DKIM check, not both. What does that mean?

• We've established that SPF doesn't survive forwarding, so receiving mail servers know that if a message doesn't pass SPF for the domain it must pass DKIM...which does survive forwarding.

• We've established that mail servers have no way of knowing if DKIM should be present when they receive a message without it, DMARC indicates it must be there unless the message passes SPF.

DMARC also introduces domain alignment to both SPF and DKIM, because it's possible for SPF and DKIM validation to both pass using domains that are not visible to the user at all which have nothing to do with the From address that you see in your email client. In order for SPF or DKIM to pass with DMARC, these checks must match up with the domain name in the From address so users can see it too. That's alignment. There are several simple examples present at the end of the DMARC specification to help alignment make more sense.

Here's an example of aligned DKIM...

DKIM-Signature: v=1; ...; d=example.com; ...

From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample

The best part though, is that DMARC is extremely simple to setup to provide all of those benefits. It's just a single DNS TXT record. Most of the work comes from trying to figure out all the places you're sending email...but DMARC even helps with that.

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