Basics


You may be getting the impression that we have a lot of documentation that you need to read... to some extent this is correct. If you're a seasoned IT person then you don't need most of it, but many of us do need refreshers since the ins-and-outs of DMARC/SPF/DKIM are not front of mind topics unless we live down in that mire. If you're less of a 'seasoned IT person', there are a few topics that you will really need to learn about in order to understand what's going on. Watch those videos and read the documentation. You might even consider working through one of our partners or MSPs for your DMARC project. We also have deployment and support packages for sale (see our website) if you need more than basic assistance via email.


Here's a quick rehash and guideline, which may be helpful to gel all the other reading you just did.

  1. Add all domains that you own into the interface. Yes ALL of them. People sending fraudulent email making use of someone else's domain don't care if you think your domain is 'just used for web traffic'. Make sure to include any domains you registered for "defensive/parked" purposes. Even if you think you're going to work on some domains separately/before others, add them all - aside from the improved overall picture of your environment this helps our source rules more correctly classify your traffic if there is any crossed usage.
    1. www.mydomain.com is not your domain, don't add it unless you're completely certain that you have email traffic using that in the From header of messages. If subdomains are detected to be in use in From headers of email on the internet, DMARC reporting will cause them to show up in your views.
    2. gmail.com etc is not your domain. Only add domains that you or your company own and can modify DNS records for.
  2. Add or update DMARC records for all of those domains, such that they report data to your dmarcian account. See the 'Add DMARC Record' area in the application for the correct record to use.
    1. we've occasionally heard folks say "I want to add DKIM/SPF before publishing DMARC." This is absolutely the wrong approach. If you already have DKIM and/or SPF, that is fine. But one of the largest purposes of deploying DMARC is so that you can gain information about whether your existing DKIM/SPF usages are correct, and how to fix (or how to initially deploy) them. Add DMARC reporting for all of your domains immediately.
    2. We have some customers that want to have DMARC reports only delivered to themselves, and then forward them on to their account's dmarcian address. This is fine, but we cannot help when things go wrong. Also if you're comfortable doing this, you probably don't need most of this guide. If you need help doing this, you probably shouldn't do it. Use the simple direct-to-dmarcian record suggested in the "Add DMARC Record" area in the application.
  3. Add alerting. See our 'Recommended alerts' article.
  4. If there are errors surfaced either in the interface or via alerting, address those problems. See our other articles for guides or solutions to the most commonly asked questions.
  5. Do not make any policy changes until you have at least 2 weeks of data. Conservatively you might even wait 6 weeks or more for a domain with complex usage. (this is our Deployment guide recommendation)
  6. Plenty of further reading. Maybe even "When should I make my policy stricter"