The new advancedDmarcOptions feature allows you to configure your DMARC records with greater flexibility and precision. It supports tag overrides, tag removal, inheritance from root domain records, and adding missing tags. This feature ensures better management of DMARC configurations, allowing complex updates in a single request.

​
Pre-existing DMARC Record Validation

When configuring DMARC records, it’s important to ensure that the value field accurately reflects the desired final DMARC configuration. If the existing DMARC record is invalid, overrides cannot be applied effectively. For example, if a DMARC record is missing a required policy (p tag) and the user attempts to update the rua tag, the system will not be able to modify the invalid record. In such cases, the value provided in the request will be used as-is.

​
Feature Overview

The advancedDmarcOptions object can be included in your DMARC record configuration. This object supports the following keys:
  • inheritRootDmarc: Inherit the DMARC settings from the root domain for subdomains.
  • overrideTags: Override specific tags in the existing DMARC record or add them if they do not exist.
  • removeTags: Remove specific tags from the DMARC record.
  • addTagsIfNotExist: Add tags to the DMARC record only if they are not already present, ensuring certain tags are included without overriding existing values.

​
Example Payload

Here’s an example of a DMARC record using advancedDmarcOptions: 
{
  "type": "TXT",
  "host": "whatever_host",
  "value": "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com",
  "ttl": 300,
  "advancedDmarcOptions": {
    "inheritRootDmarc": true,
    "overrideTags": {
      "p": "none",
      "rua": "mailto:dmarc-reports@example.com",
      "sp": "reject"
    },
     "removeTags": ["pct"],
    "addTagsIfNotExist": {
      "rua": "mailto:dmarc_agg@vali.email"
    }
  }
}

​
Key Features

  • Root DMARC Inheritance: Allows subdomains to inherit DMARC policies from the root domain when inheritRootDmarc is set to true.
  • Override DMARC Tags: Use the overrideTags object to modify existing DMARC tags. For example, change the policy from none to quarantine or update reporting email addresses.
  • Remove DMARC Tags: Use removeTags to remove unwanted tags such as pct (percentage).
  • Add Tags If They Don’t Exist: The addTagsIfNotExist key ensures that specific tags are added only if they are missing from the DMARC record.

​
Example Use Cases

  1. Overriding Existing Tags
    • Scenario: Change the DMARC policy for a domain from none to quarantine.
    • Before: v=DMARC1; p=none; rua=mailto:reports@example.com
    • After: v=DMARC1; p=quarantine; rua=mailto:reports@example.com
    Payload: 
    {
  "domain": "example.com",
  "dnsRecords": [
    {
      "type": "TXT",
      "host": "_dmarc",
      "value": "v=DMARC1; p=none; rua=mailto:reports@example.com",
      "ttl": 3600,
      "advancedDmarcOptions": {
        "overrideTags": {
          "p": "quarantine"
        }
      }
    }
  ]
}
  2. Adding New Tags
    • Scenario: Add a pct=50 tag to an existing DMARC record.
    • Before: v=DMARC1; p=reject; rua=mailto:reports@example.com
    • After: v=DMARC1; p=reject; pct=50; rua=mailto:reports@example.com
    Payload: 
    {
  "domain": "example.com",
  "dnsRecords": [
    {
      "type": "TXT",
      "host": "_dmarc",
      "value": "v=DMARC1; p=reject; rua=mailto:reports@example.com",
      "ttl": 3600,
      "advancedDmarcOptions": {
        "addTagsIfNotExist": {
          "pct": "50"
        }
      }
    }
  ]
}
  3. Removing Tags
    • Scenario: Remove the rua (aggregate report) tag.
    • Before: v=DMARC1; p=quarantine; ruf=mailto: forensic@example.com rua=mailto:reports@example.com
    • After: v=DMARC1; p=quarantine; ruf=mailto:forensic@example.com
    Payload: 
    {
  "domain": "example.com",
  "dnsRecords": [
    {
      "type": "TXT",
      "host": "_dmarc",
      "value": "v=DMARC1; p=quarantine; rua=mailto:reports@example.com",
      "ttl": 3600,
      "advancedDmarcOptions": {
        "removeTags": ["rua"]
      }
    }
  ]
}
  4. Inheriting Root Domain Policy
    • Scenario: Apply the DMARC policy from a root domain to a subdomain.
    • Before: Subdomain has no DMARC policy.
    • After: Subdomain inherits the root domain’s policy.
    Payload: 
    {
  "domain": "sub.example.com",
  "dnsRecords": [
    {
      "type": "TXT",
      "host": "_dmarc",
      "value": "v=DMARC1; p=none",
      "ttl": 3600,
      "advancedDmarcOptions": {
        "inheritRootDmarc": true
      }
    }
  ]
}
  5. Add Tag Only if Not present
    • Scenario: Ensure that a domain has a specific DMARC tag set up, but only if it doesn’t already have one set. This example uses the rua tag, but the approach works for any DMARC tag.
    • Before (Case 1): v=DMARC1; p=none;
    • After (Case 1): v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
    • Before (Case 2): v=DMARC1; p=none; rua=mailto:existing-reports@example.com
    • After (Case 2): v=DMARC1; p=none; rua=mailto:existing-reports@example.com (unchanged)
    Payload: 
    {
  "domain": "example.com",
  "dnsRecords": [
    {
      "type": "TXT",
      "host": "_dmarc",
      "value": "v=DMARC1; p=none;",
      "ttl": 3600,
      "advancedDmarcOptions": {
        "addTagsIfNotExist": {
          "rua": "mailto:dmarc-reports@example.com"
        }
      }
    }
  ]
}
  6. Complex Configuration
    • Scenario: Multiple changes including policy update, email change, and tag addition.
    • Before: v=DMARC1; p=none; pct=100; adkim=s; rua=mailto:old@example.com
    • After: v=DMARC1; p=quarantine; pct=50; aspf=s; rua=mailto:new@example.com
    Payload: 
    {
  "domain": "example.com",
  "dnsRecords": [
    {
      "type": "TXT",
      "host": "_dmarc",
      "value": "v=DMARC1; p=none; pct=100; rua=mailto:old@example.com",
      "ttl": 3600,
      "advancedDmarcOptions": {
        "overrideTags": {
          "p": "quarantine",
          "rua": "mailto:new@example.com"
        },
        "addTagsIfNotExists": {
          "aspf": "s"
        },
        "removeTags": ["adkim"]
      }
    }
  ]
}