Create an email security rule
Changed onCreates one enabled allow-list or deny-list rule. Requires EMAIL_SECURITY_WRITE. DMI_HEADER rules require header conditions and the ALLOW list. Deny and IP rules always use NONE authentication; DMI_HEADER uses AUTHENTICATED. Domain and email allow rules preserve the requested authentication requirement. IP ranges are canonicalized. Existing rules on either list cause a conflict. Returns the same rule representation as the list endpoint. Fields use snake_case.
Required permission: email_security:write
Request
- Base URLhttps://api.adaptivesecurity.com
- URLhttps://api.adaptivesecurity.com/v2/email-security/settings/rules
- AuthHTTP bearer
Request body
Example request
{
"auth_requirement": "AUTHENTICATED",
"header_rules": {
"operator": "AND",
"rules": [
{
"header": "X-Partner",
"value": "trusted",
"value_type": "STATIC"
}
]
},
"list_type": "ALLOW",
"name": "My custom rule",
"rule_type": "DOMAIN",
"value": "example.com"
}Response
Rule created
Example response
{
"auth_requirement": "AUTHENTICATED",
"created": "2026-09-22T14:00:00Z",
"header_rules": {
"operator": "AND",
"rules": [
{
"header": "X-Partner",
"value": "trusted",
"value_type": "STATIC"
}
]
},
"id": "a785a60e-a8ba-4750-8607-e9e977b9e0c4",
"list_type": "ALLOW",
"name": "My custom rule",
"rule_type": "DOMAIN",
"updated": "2026-09-23T15:00:00Z",
"value": "example.com"
}Changes
- breaking
the request property
became not nullable - breaking
added
subschema #2to theresponse propertyoneOflist for the response status - breaking
removed the required property
/from the response with the status - breaking
removed the required property
/from the response with the status - warning
removed the request property
/ - warning
removed the request property
/ - info
added
subschema #2to therequest propertyoneOflist
- breaking
- info
endpoint added
- info