DMARC Untrusted Sources

Now that you’re receiving DMARC reports, you might be wondering about those “Untrusted” sources. Should you be worried? Is there anything you should do? And, of course, it depends. So we’ll explore what exactly an untrusted source is and what you can do about it.

Each of these rows represents sources for which all messages failed both SPF and DKIM and therefore failed DMARC. Any source that appears here is either a legitimate sender that needs to be configured in your DNS or not a legitimate sender and should not be sending on your behalf. With the former, you’ll want to either configure their SPF or DKIM records or, if they’re already configured, verify that they’re configured correctly. With the latter, you can generally ignore them unless you see a large quantity of messages.

The hardest part of this process is knowing whether the source is legitimate or not. If the volume is low, then you can generally ignore a given source and not worry about it. However, if there’s an untrusted source sending a high volume of emails, you’ll probably want to at least look into it.

Researching sources

More often than not, the domain and IP addresses don’t directly correlate to a service you use. Instead, they’ll likely be associated with the hosting companies used by the services you use. This can make it incredibly difficult to deduce the correlation for a source that’s sending. A better approach is to create a list of all of the services that you use and then narrow the list down to services that need to send email on your behalf.

Once you have a list of services that need to send email on your behalf, review each service’s configuration requirements for SPF and DKIM to ensure that they’re correctly configured. Hopefully you’ll be able to quickly identify a service that isn’t configured correctly and solve the problem. In some cases, however, it’s possible that an untrusted source is malicious. Again, if the volume is low, it’s not worth worrying about. For a high volume untrusted source that you can’t trace back to a service that you use, you may want take some action to protect your domain.

Taking Action

In general, we don’t advise using “quarantine” or “reject” DMARC policies unless you either see a large quantity of messages from a given source or run a service that’s particularly attractive to phishing scams or other spoofing exploits. In most cases, the risk of blocking legitimate emails is higher than the risk of letting a small number of illegitimate emails through.

Once you’ve been running the DMARC report for a while (a few months at least) you should have been able to add all of your legitimate sending sources to your DNS. Only once you are happy that you’ve got everything included should you consider starting to restrict deliveries.

There are three different p values that you can set depending on how you want the inbound mail server to handle non-legitimate email:

• p=none → Deliver message and log for reporting
• p=quarantine → Mark affected messages as spam
• p=reject → Delete the message before it reaches the inbox

In addition to the policy, you can also specify a percentage (pct) value so that you don’t have to commit fully to quarantining / rejecting all failing emails. If you’ve copied the default DMARC entry we suggest, you’ll see a variable of pct=100. This governs the percentage of emails that will get effected by the DMARC policy. It’s recommended that when you first set your DMARC policy to quarantine or reject emails that you start off only doing it to a small percentage and then increase over time. An example path might be as follows, upped each week when you receive your DMARC report:

• Monitor all (p=none; pct=100;)
• Quarantine 25% (p=quarantine; pct=25)
• Quarantine 50% (p=quarantine; pct=50)
• Quarantine all (p=quarantine; pct=100)
• Reject 25% (p=reject; pct=25)
• Reject 50% (p=reject; pct=50)
• Reject all (p=reject; pct=100)

This gradual increase helps minimize the chances of missing a legitimate sender whilst also starting to provide a level of filtering to protect your domain and email delivery. You’ll want to communicate these kinds of aggressive tactics with your support team in case you begin receiving reports of lost email. This way, you’ll have a chain of communicate that can ensure problems are escalated and properly attributed to a more aggressive policy.