The OnDMARC API is great for performing bulk or repetitive tasks that need to be performed quickly, often and without error – and you don’t need to be a developer or even know how to code to use it. Here, I will walk you through how to perform the common task of updating the subdomain policy of domains that are already in reject, using Red Sift’s Dynamic DMARC, the OnDMARC API, and Make (formerly known as Integromat). We are using Make in this example, but you could easily use any no-code automation tool like Zapier or Retool.
What are we doing, and why
When OnDMARC sets up a DMARC record for the first time on a domain that previously did not have a record, it will always create a policy of p=“none” (DMARC reporting only) and sp=none. This means that the subdomain policy is also set to reporting only. This means that if email coming from the domain or any of its subdomains that doesn’t have a specific policy fails DMARC, no (blocking) action should be taken by the receiver. The email should be delivered as normal, and a DMARC report sent back to us for analysis. That is, unless the subdomain has DMARC policy of its own, more on that in our helpful DMARC guide here.
This passive policy is great while a domain and its sending sources are being configured, but once that is done, or if the domain and its subdomains are non-sending, then the policy should swiftly be changed to p=reject. Here, email failing DMARC will get rejected by the receiver, blocking spoofing attempts.
In our example, we have 4 domains in an OnDMARC account. We have diligently changed 3 domains to p=reject but have forgotten to update the subdomain policy which remains at sp=none. One remaining domain is still at p=none because we are still working on it. So we need to go back and update the subdomain policy for 3 of the 4 domains to sp=reject. With the OnDMARC interface and Dynamic DMARC, this is actually quite easy and would take about 12 clicks. But what if instead of 3 out of 4 domains, we had 36 out of 73? That would be much less fun. Enter the OnDMARC API.
Step 1: Get an OnDMARC API key
First, we need to get an API key for OnDMARC. Head to Administration in the User and Account panel by clicking on the profile icon on the top right of the screen.
Then click on the OnDMARC tab and make sure to select the right instance from the instance selector. If you only have access to one OnDMARC instance, then you don’t need to worry about selecting the right instance.
Scroll down to the API key table at the bottom of the screen and click Add. Make sure to assign the Super Admin role to this key during the process. Copy the API key to a safe location. Your API Keys screen should now look like this:
Step 2: Let’s download our domain list from OnDMARC
On the My Domains screen, click on the export button highlighted below and download your domain list as a CSV.
Then, head to Google Sheets (or Microsoft Office 365) and upload it to a new sheet. Get rid of all columns except the domain column so we can focus on that. It should now look something like this:
Note, we could also have gotten the domain list from the API using the GET /domains API endpoint instead of the CSV method.
Step 3: Setting up Make
Now that we have our control sheet set up, let’s head to Make to set up our automation scenario. If you don’t already have an account, you can set one up here.
Now go to Scenarios and click on “Create a new scenario”. Add the first module and select the “Get Range Values” Google Sheets module. If it is your first time, Make will ask you to authenticate with Google Sheets before proceeding.
Once that is done, we set up the module so that it gets the right range of rows from our specific Google Sheets file and tab. It should look like this:
We can test this by right-clicking on the module and selecting “Run this module only” to check the output. 
As expected, we get one bundle per row, containing each domain. This allows us to iterate through each domain on the list in the subsequent steps.
Next, we will ping the OnDMARC API, first to check the current Dynamic DMARC settings, and then to update them if necessary. We check the current settings before updating them because we only want to update the subdomain policy to reject for domains where the top-level policy is in reject.
To get the existing Dynamic DMARC policy settings, we will use the GET domainDMARC endpoint. This retrieves the current Dynamic DMARC settings of a specific domain in the OnDMARC instance.
Step 4: Making our first OnDMARC API call
Create a new module, linking it to the first Google Sheets one, and select the HTTP app and the “Make a Basic Auth request” action as below:
In the URL field, type the base API URL for your locale, followed by the extension “/domain/{domain}/dmarc”. You can get the correct base URL from the top of the API documentation, it varies depending on your instance location (EU, UK or US). For the UK instance, it would look like this https://api.ondmarc.com/domain/{domain}/dmarc
Now replace {domain} with a reference to the domain column in the Google Sheet from the previous module as such:
Make sure you set the Method to GET, and then we can move to the next step of setting up this API call: Authorization. In order for the API call to work, it will need to be authorized using your API key. To do so we need to add an Authorization Header. 
Give item 1 in the Headers section the name “Authorization”, and in the value field, type Api-Key, followed by a space, followed by the API key you had saved in step 1. Be sure to follow these steps exactly as specified, they are case-sensitive. The end result should look like the screenshot above.
As a last step, set the Body type to Raw, the Content type to JSON (application/json), and set “Parse response” to yes, then click OK to save.
Now let’s run the whole scenario to test it. 
Great success. Analyzing the output, the API returns a data object that contains an Array called “entries”, the first item (item 1) contains the top-level policy and the third item (item 3) contains the subdomain policy. To save ourselves from array manipulation, we will make the safe assumption that the items will always come through in this order, and create simple mappings for our filters.
Back to our Google sheet, in the header of column B, type “p=” and in column C type “previous sp=”, in D let’s add “Update status code” and E “new sp=”. The result should look like this: 
Now let’s create our first writeback to Google Sheets to write back the current settings to our sheet for confirmation purposes. Add a Google Sheets “Update Row” module and set it up as follows:
Note the Row number reference to the first module, this ensures the results are appended to the right row. And in columns B and C we are referring to the values of items 1 and 3 of the “Entries” array that was returned from the OnDMARC API. If we now run the scenario, the results should look like this:
We can now see clearly that the domains in rows 2, 4 and 5 need their subdomain policy adjusted to reject, but not the one in row 3. Let’s continue to the next step.
Step 5: Filtering and making our update API call
Now let’s create a router module to create two possible paths for our scenario. Click the + sign next to the last module in the scenario and search for “Router”. In the first route, we will filter to let through only the rows where the p= policy is of the “reject” value, and in the second one, all other results.
Let’s set up the first filter by clicking on the 1st path after the router. Name the filter and set it up as follows:
This means that only items where the policy is p=reject will be let through this pass. On the second path, we set up the inverse filter: 
Note the “Not equal to” operator.
Let’s set up the second path first since it is the easiest. Here, we do not need to update the policy, we will simply write back to the row that no update was needed. Clone the Update row module and drag it to the second path, edit it to be set up like this:
Remember, column D is our “Update status code” field.
Now let’s turn our attention to the first path, where we will make an update call to the OnDMARC API. Instead of setting up a new HTTP module from scratch, clone and rename the first one, and then drag it to the path. The paths should look like this: 
Now we need to modify the API call because we no longer want to get the current settings, instead, we want to push new settings. We will use the same API endpoint but instead of a GET call, we will use a PATCH call, with some extra information in the body to specify the changed settings we want. Set it up as follows: 
Remember to change the Method to PATCH, keep the same Authorization headers, and include the following in the request content or body:
[{
"key": "sp",
"value": "reject"
}]This updates the subdomain policy of the domain in question, leaving everything else as is.
Now, let’s add a final confirmation writeback to Google Sheets. Clone, rename, and drag the Google Sheets “Update a Row” module from the path below, and set it up like this:
This will write the response status code back to column D, and if the status is successful (code of 200), then the updated value (“reject”) will be written in column E, or else it will be left blank.
The full scenario should look like this:
Let’s run it!
If everything is set up correctly, the domains in reject should go down route 1, and those not in reject are funneled down route 2. And here is the result in Google Sheets, perfect:
Conclusion
This is a great example of a real life use case for the OnDMARC API. We saw how anyone can make use of it with spreadsheet software like Google Sheets or Microsoft Office 365 as the control sheet, and Make or Zapier as an automation tool to make the API calls. In this example, we used the API to conditionally update the Dynamic DMARC settings for a series of domains, but any other action is also possible. To get some ideas, you can check out the OnDMARC API documentation or just remember that anything you can manually in the UI, you can also probably find a matching API endpoint where you can orchestrate it automatically.
