Phishing sucks. It’s a persistent nuisance at best and potentially catastrophic at worst. While technology isn’t able to catch all of it 100% of the time, DMARC can help to dramatically minimize the amount of phishing emails that get through to our inboxes.
DMARC is also good for helping keep domains off of email blacklists, which is added value for protecting brands and reputations.
DMARC is complex though and has a lot of parts.
This guide is written in a linear manner to try and help you understand DMARC, its independent components, and friendly, step-by-step instructions for how to set up each part so that we might bring this technology to more people in a consistent and predictable way.
Thanks for making time to learn about DMARC. Education and awareness help others understand how tools like DMARC can minimize or even eliminate preventable risks to their organization.
DMARC is a set of 3 DNS records that work together to ensure email is sent only from authorized origins (mail servers) thereby helping block fraudulent messages that might appear to be from domains under our control.
Email is easy to spoof. Criminals love it because it’s easy to exploit and e4asy to get us to click on phishing emails when they appear to come from senders we trust, especially from well-known brands. Simply inserting the logo of a well known brand into an email makes it appear more legitimate, exponentially increasing the likelihood that someone will click on something they shouldn’t.
Since it’s getting harder and harder to tell a legitimate message from a forged or malicious one, and because we can’t always trust our email provider (GSuite, Office365, etc) to catch and filter these messages before they reach our inbox, we have technologies like DMARC that can help.
DMARC helps prevent criminals from spoofing the “header from” or “reply-to” address by making it possible for senders and receivers to determine whether or not a message has been sent from an authorized sender. DMARC sets a clear policy for what to do if a message hasn’t been sent from an authorized source, such as sending it to the spam folder or rejecting the message altogether. Think of DMARC as an additional layer of defense to help protect us against phishing and spear-phishing.
If an email account is compromised, meaning a criminal has obtained direct access to the account and password via nefarious means and has full control, they can effectively send legitimate messages that will pass all DMARC checks. In these cases, DMARC is not an effective tool to prevent further social engineering attacks using a person’s legitimate email address.
There are 3 components to DMARC that make it work, all TXT records we need to set up in the specific domain’s DNS:
DMARC helps prevent criminals from spoofing the “header from” or “reply-to” address using the following process:
One might imagine how these check can vastly reduce the number of spoofed messages that get to our inboxes. Here’s a real world example of how effective it can be:
Let’s take a step-by-step walk through the process of setting up DMARC, steps we can use both as a learning tool for building our own awareness and also for guiding others through the process.
Be sure to think before making any changes and if you need help, please ask for it.
Before we get to actually setting up and configuring DMARC, we need to ask a few important questions first.
Once we have all the answers, we can move to actually doing stuff.
Let’s start with the most straightforward part first: the SPF record.
SPF stands for Sender Policy Framework.
SPF is set up as a new TXT record in the domain’s DNS.
An SPF record tells the world what email servers are authentic and permitted to send email on behalf of a specific domain.
SPF works by publishing what’s called a “reverse MX” record to tell the Internet what servers can legitimately send mail on behalf of the domain. When receiving a message, a receiver’s mail server can check those records to make sure mail is coming from a legit point of origin.
Publishing a “reverse MX” or SPF record is pretty easy: one line in DNS is all it takes to enable a SPF record for the domain.
Here’s a generic SPF record for Office 365 that works for almost everyone:
v=spf1 include:spf.protection.outlook.com -all
The hard fail variable above (-all) is recommended for fully-hosted Office 365 clients.
And here’s a generic one for GSuite:
v=spf1 include:_spf.google.com ~all
The soft fail variable above (~all) is recommended to ensure all mail is delivered.
But wait – there might be more.
If we have servers that send email from locations outside of GSuite or Office 365, we’ll need to includ that information in our SPF record.
Once we have all the information, domains, services/IP addresses, etc. that we need to ensure delivery of email from all sources, we might try using this handy tool to create an SPF record and check it against our proposed design: https://www.spfwizard.net/
SPF records don’t like it when we have strings in them that exceed 255 characters, which means we need to focus on keeping our SPF records as concise as we can.
This is due in part to the IETF’s RFC 1035, which means DNS entries in general don’t like to exceed 512 octets or about 455 characters.
So, for example, if we have many ip4 and ip6 addresses to add, let’s make sure they’re not redundant. We can merge them using CIDR notation.
Here’s an example of IP address ranges that can be merged in this way:
v=spf1 a mx ip4:192.168.0.0/24 ip4:192.168.1.0/24 -all
What that means is:
ip4:192.168.0.0/24 = 256 IP addresses; including 192.168.0.0 – 192.168.0.255
ip4:192.168.1.0/24 = 256 IP addresses; including 192.168.1.0 – 192.168.1.255
So, if we need to, we can replace the above example with shorter and better CIDR notation:
v=spf1 a mx ip4:192.168.0.4/23 -all
Because what the above notation means is:
ip4:192.168.0.0/23= 512 IP addresses; including 192.168.0.0 – 192.168.1.255
An effective way for larger organizations to reduce the number of characters in an SPF record is to create an SPF specific subdomain represented as: _spf.test_domain.com. Using “_spf” as the subdomain tells a mail server to treat the subdomain as a storage container, which is only used for listing additional SPF information.
If we need to create more than one SPF specific subdomain, we can use _spf, _spf1, _spf2, etc.
Here’s a good example: Google is HUGE and has massive amounts of IP addresses represented in different netblocks due to the size and scope of their organization. Attempting to place all this information into one SPF record would easily exceed standardized limits.
To resolve this, they created smaller “storage containers” of SPF records with IP addresses that are shorter and combined them together using include statements.
Here’s a list of netblocks they use and the corresponding SPF records:
In order to keep the SPF record short for google.com, Google created an SPF specific subdomain of _spf.google.com and references each netblock using an include statement in the SPF record. The include statement instructs a mail provider to search for additional SPF information for the domain listed.
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all
Google then adds their SPF specific subdomain _spf.google.com with an include statement to the google.com SPF record.
The end result is a simple SPF record for google.com that’s short and sweet.
v=spf1 include:_spf.google.com ~all
Before we create SPF specific subdomains, though, let’s try to use better CIDR notation for IP ranges in order to reduce the length of our SPF records. That’s the more straightforward way.
There are many online tools to check and verify SPF records out there. One of the friendliest and most useful may be https://www.dmarcanalyzer.com/spf/checker/
Once your SPF record passes muster, congratulations! You’re ready to take the next step, but not before we DOCUMENT all of our work so far in ITG : )
DKIM stands for DomainKeys Identified Mail.
DKIM is set up as a new TXT record in the domain’s DNS.
DKIM is an encryption tool that allows senders to “digitally sign” email messages to help keep them private. Most people who use DKIM don’t have to do anything special and probably don’t even know they’re using it, which makes it a friendly tool for better security.
Honestly, DKIM is the most complicated email authentication protocol out there. Even if we do extensive research, it’s hard to find one place that describes how it all works.
For our purposes here, we can say it uses a public key or asymmetric-key encryption, a commonly used but effective method, where the private key is kept secret and the public key is published and made freely available for verifying authenticity.
To help keep things simple, let’s think of DKIM as a “digital signature.” This signature is generated by the sending email server and inserted into the message’s header before it’s sent.
The public key the mail server used to generate the signature is stored at the DNS server (in the TXT record) so it can be used on the receiving end, too. After receiving the email, the receiving mail server can verify the DKIM signature by checking it against the public key on the DNS server.
The receiving mail server then uses the key to decrypt the message’s header and also do some other calculations to ensure the message is legit.
If all of these activities and calculations pass muster, the mail server can presume with pretty good certainty that the message originated from a legitimate and authorized mail server, hasn’t been altered, and is safe for delivery.
Depending on the type of mail service the primary domain is using (i.e. GSuite, Office 365, etc.) there are specific and unique steps for each.
For any custom or self-hosted email platform and/or level of complexity, more manual and sophisticated configuration may be required, which means you can ask for more personal guidance.
In any case, it’s important to note that domain keys include a text string called the selector prefix, which we can modify when we generate the key. Make sure to write this down or know what it is because we’ll need it to test the DKIM configuration later. (Also – make sure we’re DOCUMENTING all of our work in ITG).
For GSuite, the comprehensive steps are linked to here: https://support.google.com/a/answer/174124?hl=en
Here’s Google’s general, step-by-step instructions:
For Office 365, the comprehensive steps are linked to here: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email
Here’s the part of their general step-by-step instructions that might matter most:
For each domain for which you want to add a DKIM signature in DNS, you need to publish two CNAME records. A CNAME record is used by DNS to specify that the canonical name of a domain is an alias for another domain name.
Office 365 performs automatic key rotation using the two records that you establish. If you have provisioned custom domains in addition to the initial domain in Office 365, you must publish two CNAME records for each additional domain. So, if you have two domains, you must publish two additional CNAME records, and so on.
Use the following format for the CNAME records.
Important
If you are one of our GCC High customers, we calculate domainGuid differently! Instead of looking up the MX record for your initialDomain to calculate domainGuid, instead we calculate it directly from the customized domain. For example, if your customized domain is “contoso.com” your domainGuid becomes “contoso-com”, any periods are replaced with a dash. So, regardless of what MX record your initialDomain points to, you’ll always use the above method to calculate the domainGuid to use in your CNAME records. Copy
Host name: selector1._domainkey
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
Host name: selector2._domainkey
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
Where:
contoso.com. 3600 IN MX 5 contoso-com.mail.protection.outlook.comFor example, if you have an initial domain of cohovineyardandwinery.onmicrosoft.com, and two custom domains cohovineyard.com and cohowinery.com, you would need to set up two CNAME records for each additional domain, for a total of four CNAME records. Copy
Host name: selector1._domainkey
Points to address or value: **selector1-cohovineyard-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600
Host name: selector2._domainkey
Points to address or value: **selector2-cohovineyard-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600
Host name: selector1._domainkey
Points to address or value: **selector1-cohowinery-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600
Host name: selector2._domainkey
Points to address or value: **selector2-cohowinery-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600
Once you have published the CNAME records in DNS, you are ready to enable DKIM signing through Office 365. You can do this either through the Office 365 admin center or by using PowerShell.
There are also many online tools out there for testing DKIM configurations. Again, here’s one of the more friendly and useful ones: https://www.dmarcanalyzer.com/dkim/dkim-checker/
For domains using GSuite, we can also use Google’s internal tool*: https://toolbox.googleapps.com/apps/checkmx/
*Note that Google’s internal tool does not work for domains using other mail services.
Now that we’ve set up and tested SPF and DKIM, our next step is to create a DMARC record for the domain to get them all working together.
A good, generic DMARC record to start with might look like this:
v=DMARC1; p=none; rua=mailto:dmarc@test_domain.comLet’s look at the distinct parts of it, each called a ‘tag”:
The example above includes the 3 most commonly used DMARC tags: v, p, and rua.
| Tag Name | Required? | Purpose | Sample Values |
| v | Yes | Protocol Version | v=DMARC1 |
| p | Yes | Policy setting | p=none, p=quarantine, or p=reject |
| pct | Nope. Optional | % of messages filtered | pct=20 |
| rua | Nope. Optional | Email address where aggregate reports are sent (forensics) | rua=mailto:dmarc@test_domain.com |
| sp | Nope. Optional | Policy for subdomains (if needed) | sp=r |
| aspf | Nope. Optional | Alignment mode for SPF | aspf=r |
The first two tags, v and p, are required in order to create a valid DMARC record. All other tags are optional (though we insist on setting an email address for rua below).
“v” stands for version and is always set to DMARC1 as this is the current version of DMARC in use.
“p” is for policy and can be set to one of three values:
“rua” stands for Reporting Uniform Resource Identifier (URI) for Aggregate reports.
It’s not required for a valid record but it probably should be. It’s where we set the email address where DMARC reports are sent. We will use these reports later to understand more about how DMARC is working, what sorts of messages are being blocked, why, etc. They are sent according to how many messages are passing through, being blocked, etc.
If you choose to set a unique address for receiving these reports (like dmarc@test_domain.com) REMEMBER TO CREATE or ALIAS IT SO IT EXISTS OR REPORTS WON’T BE DELIVERED
These are useful for situations where a message might be sent from a different domain or subdomain that the primary domain. For example, a message sent from spongebog@spongbob_test_domain.com to beyonce@test_domain.com
The authentication will accept this in relaxed mode but not in strict mode.
This can be defined using aspf alignment mode tags and can be set to relaxed or strict, with relaxed being the default if no tag is present. Otherwise, this tag can be set in two ways:
DMARC TXT Record Examples
Here’s a handy 3-Phased process to introduce DMARC to our DNS configuration that progressively gets more restrictive over a period of weeks (8 or more) as we gain confidence that things are working well.
Included are some example DMARC TXT records using the most common tags that we can modify as our process progresses, starting with introducing an initial DMARC configuration that uses a policy setting of “none” (START HERE), then moving to a more restrictive policy setting of ‘quarantine’ (MIDDLE PHASE), and then onto the goal of a policy set to ‘reject’ all illegitimate messages (FINAL PHASE).
For demonstration purposes, we’ll set each of these DMARC TXT records to send aggregate reports to dmarc@test_domain.com
START HERE (WEEK 1 to 3): This policy setting implements no action. It’s used for testing only.
To begin, we just want to test and learn without interrupting the flow of legitimate email. This is important because it’s easy to prevent legitimate messages from arriving in inboxes with these configurations and we don’t want to have to explain to our mail recipients what happened.
With that in mind, we recommend starting with a policy that is least restrictive, meaning it won’t interfere with normal mail delivery (that’s important). This is a good choice for the first two or three weeks (don’t rush this process – take your time and do this right) and get a feel for how this all fits together and ensure legitimate email is flowing and being delivered as it should.
This record will take no action on messages that appear to be from our test_domain.com but don’t pass DMARC checks.
v=DMARC1; p=none; rua=mailto:dmarc@test_domain.comMIDDLE PHASE (WEEK 4 or 5): This policy introduces the “quarantine” setting to send illegitimate messages to spam/junk folders in recipients’ inboxes. After our least restrictive configuration is in place for a couple of weeks, we’ll take the next step and make the policy a bit more restrictive. To set our p tag’s value to “quarantine” and introduce the pct tag, which stands for percentage, that allows us to set a value that tells DMARC to sample that much of the total flagged traffic (messages that fail SPF and/or DKIM checks) for analysis. Typically, a good percentage to set is 1, to start.
v=DMARC1; p=quarantine; pct=1; rua=mailto:dmarc@test_domain.comThe pct tag can be set from 1 to 100 and we’ll experiment with his more for a few weeks as we get closer and closer to being able to try this final step below, but it’s still a few weeks away at this point. As the weeks progress, we’ll begin gradually increasing the pct value, incrementally sampling more and more traffic each week until we get to 100%.
FINAL PHASE (WEEK 8): This policy setting will introduce “reject” to block illegitimate messages.
<<WARNING – this may prevent mail delivery of legitimate messages – use caution>> We’ll start with setting the pct tag at 1 and gradually increase it as we go. Once we’re 100% certain we’ve got things humming pretty well (after a few weeks of running the middle step’s configuration and seeing good things in the aggregate reports), we’ll then use this type of record and reject 100% of the messages that don’t pass DMARC checks.
v=DMARC1; p=reject pct=1; rua=mailto:dmarc@test_domain.comHow to add a DMARC record to DNS
Next, we want to enter our DMARC configuration into DNS.
Now, this part is a bit tricky to build a step-by-step guide for because it depends on the registrar where DNS resides for the domain being configured with DMARC. Each one has subtle differences so, depending on where the DNS resides, we’ll create a new TXT record based on the steps for the specific DNS provider.
In any case, there are some values that will always be consistent.
Make sure we’re entering these into the appropriate domain and zone:
Don’t forget to save the configuration in order to complete adding the TXT record.
How to test DMARC records
DMARC is a DNS record and may take a bit of time to propagate across the Internet before it’s testable.
Once it’s live, there are a lot of online tools for testing DMARC records but this may arguably be one of the friendliest:
https://mxtoolbox.com/dmarc.aspx
We’ll use the feedback we get from tests to correct or refine our configuration.
Then, we wait. Gradually, the aggregate reports will begin to roll in to the inbox of the address we set up to receive them.
What are DMARC Aggregate Reports for?
These reports are crucial for helping us understand if our DMARC configuration is set up well or not. We use these report to:
What format do reports arrive in?
Reports arrive via email to the address set in the DMARC record’s rua tag. They are attached to these messages as compressed .zip files and unzip into .xml format.
The subject line of reports when they arrive in our inbox is standard and consistent (and long). Here’s an example of one:
Report domain: test_domain.com Submitter: google.com Report-ID: 11758684929384756971
Once unzipped, the xml reports can be viewed in browsers, text editors (gui or cli). Use whatever works best for you.
What does a report look like?
Here’s an example report from Google using our test domain for demonstration purposes:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
<report_id>14948423697488147001</report_id>
<date_range>
<begin>1548892800</begin>
<end>1548979199</end>
</date_range>
</report_metadata>
<policy_published>
<domain>test_domain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp>quarantine</sp>
<pct>20</pct>
</policy_published>
<record>
<row>
<source_ip>123.456.789.012</source_ip>
<count>18</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>test_domain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>test_domain.com</domain>
<result>pass</result>
<selector>google</selector>
</dkim>
<spf>
<domain>test_domain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>123.456.789.011</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>test_domain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>google.com</domain>
<result>pass</result>
<selector>20161025</selector>
</dkim>
<dkim>
<domain>test_domain.com</domain>
<result>pass</result>
<selector>google</selector>
</dkim>
<spf>
<domain>calendar-server.bounces.google.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
What are we looking for?
At first, we’re interested to search for the word fail. If we find it, that means something in our SPF record or DKIM configuration need to change for these checks to pass.
In the example report, we can find one here:
<record>
<row>
<source_ip>123.456.789.011</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
If we’re still in testing mode, that fail in between the <spf> tags tells us that our SPF record is not yet complete. There may be something missing.
We need to verify what this IP address points to and whether or not this is something that should be included in the SPF record, and how to do that while being mindful of good security practices, too.
That gives us some work to do. We need to verify who owns that IP and, if it’s legit, we will add this IP to our SPF record to ensure it passes an SPF check next time (or not). It can get rather complicated in some cases. Ask for help if you get stuck.
For the sake of continuing our learning here, let’s presume this is a legit IP of a legit email server.
If this is our current SPF record:
v=spf1 include:_spf.google.com ~all
We can add its IPv4 address to our SPF record like so:
v=spf1 ip4:123.456.789.011 include:_spf.google.com ~all
We can add IPv6 addresses like this, when needed:
ip6:2607:f0d0:1002:0051:0000:0000:0000:0004
Keep in mind that strings within SPF records shouldn’t exceed 255 characters. If we run into a situation where this happens, have no fear, there’s a solution for that and we addressed it in the section above on creating SPF records.
If DKIM is failing, that’s a dog of a different color. Any number of things could be happening. It usually requires going back and resetting the key. Each platform has it’s own process so refer to the documentation above or ask someone on staff for guidance.
What’s else is in a DMARC Aggregate Report?
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
<report_id>14948423697488147001</report_id>
<date_range>
<begin>1548892800</begin>
<end>1548979199</end>
</date_range>
</report_metadata>
<policy_published>
<domain>test_domain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp>quarantine</sp>
<pct>20</pct>
</policy_published>
<record>
<row>
<source_ip>123.456.789.012</source_ip>
<count>18</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>test_domain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>test_domain.com</domain>
<result>pass</result>
<selector>google</selector>
</dkim>
<spf>
<domain>test_domain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
What’s NOT in an Aggregate Report?
Trends across ISPs
Identifying trends on IP addresses reporting across different ISPs is a great way to troubleshoot authentication issues and help ensure legitimate email is getting delivered. However, aggregate reports do not contain trends.
Sender Score (reputation data)
If an authentication failure is due to an IP address not within our infrastructure (e.g. belongs to a third-party sending email on their behalf), we’ll have to do additional research on that IP address to determine whether or not it’s a legitimate sender.
Message samples
Aggregate reports don’t contain message-level data. Forensic reports do. If we identify a dubious IP address within an aggregate report and need to find message-level data to troubleshoot it, we’d have to search both the aggregate and forensic information we have to make those connections.
Alerting capabilities
Once we move our policy setting (p tag) to reject, we want to ensure legitimate mail is not negatively impacted. Since aggregate reports don’t contain trend data, there’s no way to tell if legitimate messages are getting blocked in bulk due to the reject policy. We have to test, test, test.
As time goes by and mail is flowing and being delivered as expected, we can begin to tighten up our configuration to make it more restrictive toward the goal of full-on ‘reject’ and ‘100’ in our policy (p) and percentage (pct) tags. This is the goal.
We don’t get there overnight, however.
So, every week or so, as we learn more about a specific DMARC implementation, we will slightly increase the strictness.
Here’s another way to think about how to roll out the implementation gradually:
Using the policy (p) tag
We can set and change the policy option using the p tag value in the TXT record. Start with a quarantine policy so you can inspect suspicious messages. Then gradually modify the policy based on what you learn from quarantined messages and daily reports.
Use the percent (pct) tag
The percent option specifies what percentage of suspicious messages have the DMARC policy applied. Suspicious messages are messages that fail DMARC checks. The default when there is no pct tag is 100% (all suspicious messages).
We can set this tag to fewer messages at first, increasing the percentage every few days as we refine our DMARC policy. For example, at first, we should set the percent option to 20 to filter 20% of rejected or quarantined messages to start with.
The following week, we can change the value from 20 to 50 to filter 50% of the messages.
Example deployment
Here’s an example of how to use the p and pct tags to gradually deploy a DMARC policy. Update the DMARC policy over time with these values:
Week 1
p=none pct=100
Week 2
p=quarantine pct=1
Week 3
p=quarantine pct=5
Week 4
p=quarantine pct=10
Week 5
p=quarantine pct=25
Week 6
p=quarantine pct=50
Week 7
p=quarantine pct=100
Week 8
p=reject pct=1
Week 9
p=reject pct=5
Week 10
p=reject pct=10
Week 11
p=reject pct=25
Week 12
p=reject pct=50
Week 13
p=reject pct=100
As time goes on, DKIM should be fine, as is, without any effort on our part. Some recommend updating the key from time-to-time and that can be easily done.
We’ll want to continue to refine the DMARC and SPF records, however, but be cautious.
While there are many opinions on how strict these need to be, it’s important to balance that against ensuring legitimate mail keeps flowing. It’s easy to interrupt the flow of authentic mail with any of these components.
Research, test, research, and test some more before doing anything you might regret.
For example, there is an ongoing debate about using soft (~all) vs. hard (-all) fail in SPF records (and also in SPF alignment tags).
~all evaluates all messages as neutral, while -all will fail if a message isn’t using strict SMTP servers and relays. This may make sense for some more than others. It would require a larger discussion with the whole team.
This is worth a discussion of our threat model. If there is a case where such a configuration provides essential value, then it should be considered. Otherwise, it is most likely outside of their real threat model and likely just adds needless complexity.
In the case of Google, they recommend SPF records use ~all because otherwise legitimate mail delivery will be impacted. This isn’t true for every email platform so pay close attention to this in your testing, especially if you need to set this to hard fail.
This is a case-by-case sort-of-thing. Each DMARC implementation can be unique. In any case, maintaining them well relies on keeping good documentation.
As external IP addresses for mail servers change and/or are added, for example, the SPF record will need to be updated. If a Web server that sends email responses from Web forms is migrated to a new host or platform, the configuration, including even DKIM, may need to be reset or reconfigured. There are many possible scenarios but in each one good documentation is the best way to ensure a reliable strategy for good maintenance and sustainability of DMARC.
Be sure to document DMARC values, as well as SPF and DKIM values, as you refine them, in your documentation and be sure it can make sense to someone else, too, who might need to read it.
There are a number of free tools for monitoring DMARC, such as PostmarkApp, but keep in mind free means you are the product. Don’t use free services if you can do better. Free services create their own risks.
It’s pretty quick to open an aggregate report from time-to-time, do a quick search, and make adjustments as needed. Adding complexity to the process should have value to save time and make things easier. If it does, then use it. If it doesn’t, then don’t.
If you made it all the way to the end, some gratitude is in order.
Thanks for reading! Happy smart and productive DMARCing.