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 thevalue 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
TheadvancedDmarcOptions 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 usingadvancedDmarcOptions:
Key Features
- Root DMARC Inheritance: Allows subdomains to inherit DMARC policies from the root domain when
inheritRootDmarcis set totrue. - Override DMARC Tags: Use the
overrideTagsobject to modify existing DMARC tags. For example, change the policy fromnonetoquarantineor update reporting email addresses. - Remove DMARC Tags: Use
removeTagsto remove unwanted tags such aspct(percentage). - Add Tags If They Don’t Exist: The
addTagsIfNotExistkey ensures that specific tags are added only if they are missing from the DMARC record.
Example Use Cases
-
Overriding Existing Tags
- Scenario: Change the DMARC policy for a domain from
nonetoquarantine. - Before:
v=DMARC1; p=none; rua=mailto:reports@example.com - After:
v=DMARC1; p=quarantine; rua=mailto:reports@example.com
- Scenario: Change the DMARC policy for a domain from
-
Adding New Tags
- Scenario: Add a
pct=50tag 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
- Scenario: Add a
-
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
- Scenario: Remove the
-
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.
-
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
ruatag, 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)
-
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
-
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

