Mitigating DMARC Failures Due to Third-Party Webhook Services

28 October 2026 · DMARC Engine · 10 min read

Introduction to Third-Party Webhook DMARC Failures

A common pattern is for organisations to use third-party webhook services, such as Zapier or Mailgun, to automate tasks or send emails. These services often require sending emails on behalf of the organisation, which can lead to DMARC failures if not properly configured. For example, a DMARC record with a strict policy, such as

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:aggregate@example.com; ruf=mailto:failure@example.com; fo=1"

may cause emails sent via a third-party webhook service to fail DMARC validation, resulting in rejection by receivers.

A hosted or managed setup may handle this by providing pre-configured DMARC records or automated tools for configuring webhook services. However, it is still important for organisations to understand the underlying configuration and potential issues.

# example python code using dnspython to query DMARC records
import dns.resolver

answers = dns.resolver.resolve('_dmarc.example.com', 'TXT')
for rdata in answers:
 for txt_string in rdata.strings:
 print(txt_string)

Note: organisations should ensure they publish DMARC records on domains they control, rather than relying on a hosting or email provider's own hostname.

Identifying Webhook-Related DMARC Failures in Aggregate Reports

To identify webhook-related DMARC failures, it is essential to analyse the aggregate reports received from receivers. The aggregate reports will show failures due to SPF, DKIM, or both. A common pattern is that the reports will indicate a mismatch between the domain in the From header and the domain authenticated by SPF or DKIM.

The reports will typically include the domain name, the IP address of the sender, and the authentication results for SPF and DKIM. For example, the following

<record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>10</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>fail</dkim>
 <spf>fail</spf>
 </policy_evaluated>
 </row>
 <identifiers>
 <header_from>example.com</header_from>
 </identifiers>
 <auth_results>
 <dkim>
 <domain>webhook-service.com</domain>
 <result>fail</result>
 </dkim>
 <spf>
 <domain>webhook-service.com</domain>
 <result>fail</result>
 </spf>
 </auth_results>
</record>

indicates that the domain example.com is experiencing DMARC failures due to a webhook service hosted on webhook-service.com.

The domain webhook-service.com is likely to be included in the SPF record of example.com to allow the webhook service to send emails on its behalf. However, if the SPF record is not correctly configured, or if the webhook service is not honouring the domain alignment, DMARC failures will occur.

example.com. IN TXT "v=spf1 include:webhook-service.com -all"

In a hosted or managed setup, the service provider may handle the configuration of SPF records, but it is still crucial to verify that the records are correctly set up to include the webhook service.

A list of common issues to look out for in the aggregate reports includes:

* SPF authentication failures due to missing or incorrect include statements
* DKIM authentication failures due to incorrect selector configuration or missing public keys
* Domain alignment issues between the From header and the authenticated domain

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"

Warning: when analysing aggregate reports, it is essential to consider the timing of the reports, as they may be delayed or batched, and to

Troubleshooting Webhook Services with Missing or Incorrect SPF Records

When troubleshooting webhook services that are causing DMARC failures, one common issue is missing or incorrect SPF records. A typical example of this is when a third-party webhook service sends emails on behalf of a domain, but the domain's SPF record does not include the webhook service's IP addresses.

v=spf1 include:_spf.example.com -all

This record would need to be updated to include the IP addresses of the webhook service. The updated record might look like this:

v=spf1 include:_spf.example.com include:webhook-service.com -all

A hosted or managed setup may handle this differently, often providing a dashboard or interface to manage SPF records and add new include statements.

> Tip: It is essential to ensure that the SPF record is correctly formatted and includes all the necessary IP addresses or include statements to avoid DMARC failures.

Receivers typically check the SPF record of the domain in the From header of the email, so it is crucial to ensure that the SPF record is correct for the domain being used. The aggregate reports will show which IP addresses are being used to send emails, allowing for the identification of missing or incorrect include statements in the SPF record.

v=spf1 ip4:192.0.2.1 include:example.com -all

DKIM Alignment Issues with Third-Party Webhooks

DKIM alignment issues are a common problem when using third-party webhook services, as the DKIM signature is typically generated by the webhook service, not the domain owner. This can lead to DMARC failures if the DKIM signature does not align with the domain's DMARC record. For example, if a domain example.com has a DMARC record with the following configuration:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; sp=none; adkim=s; aspf=s"

And a third-party webhook service generates a DKIM signature with a different domain, such as webhook-service.com, the DKIM alignment will fail, causing DMARC verification to fail.

A hosted or managed setup may handle this by allowing the domain owner to configure a custom DKIM selector for the webhook service, or by providing a predefined set of DKIM selectors that can be used with the service. However, this requires careful planning and configuration to ensure that the DKIM signatures align with the domain's DMARC record.

To mitigate DKIM alignment issues, it is recommended to use a separate DKIM selector for the webhook service, and to configure the DMARC record to allow for relaxed DKIM alignment. For example:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; sp=none; adkim=r; aspf=r"

This configuration allows for relaxed DKIM alignment, which can help to mitigate DMARC failures due to DKIM alignment issues with third-party webhook services.

Note: When using a separate DKIM selector for the webhook service, it is essential to ensure that the selector is correctly configured and aligned with the domain's DMARC record, to avoid DMARC verification failures.

The aggregate reports will show the DKIM alignment failures, which can be used to identify and troubleshoot the issue. By monitoring the aggregate reports and adjusting the DMARC configuration as needed, domain owners can help to mitigate DMARC failures due to DKIM alignment issues with third-party webhook services.

Implementing and Testing DMARC Records for Webhook Services

When implementing DMARC records for third-party webhook services, it is crucial to consider the specific requirements of each service. A common pattern is for webhook services to use subdomains or dedicated hostnames for their webhook endpoints. Receivers typically expect DMARC records to be published on the domain or subdomain that is used in the From header of the email.

To mitigate DMARC failures due to third-party webhook services, you should publish a DMARC record on the domain or subdomain used by the webhook service. For example, if a webhook service uses the domain webhooks.example.com, you should publish a DMARC record on that domain.

_dmarc.webhooks.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

A hosted or managed setup may handle this differently, so it is essential to check with your provider to determine the best approach. Some providers may require you to publish DMARC records on a specific subdomain or use a custom hostname.

When testing DMARC records for webhook services, you should verify that the records are correctly published and that the webhook service is authenticating correctly. The aggregate reports will show whether the DMARC record is being applied correctly and whether there are any authentication issues.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com"

You should also test the webhook service itself to ensure that it is sending emails with the correct From header and that the emails are being authenticated correctly.

Tip: when testing DMARC records, it is helpful to use a DMARC testing tool to verify that the records are correctly published and that the authentication is working as expected. This can help identify any issues before they cause problems with your email deliverability.

Lists of common webhook services and their recommended DMARC configurations are not typically available, as each service has its own specific requirements. However, some common patterns are:

* Using a subdomain for the webhook endpoint
* Requiring a specific DMARC policy, such as p=none or p=quarantine
* Using a custom hostname for the webhook service

import dns.resolver

def check_dmarc_record(domain):
 try:
 answers = dns.resolver.resolve(f"_dmarc.{domain}", "TXT")
 for answer in answers:
 for txt_record in answer.strings:
 if txt_record.startswith(b"v=DMARC1"):
 return True
 except dns.resolver.NoAnswer:
 pass
 return False

Operational Considerations for Webhook DMARC Configuration

When configuring DMARC for third-party webhook services, it is crucial to consider the operational implications. A common pattern is for webhook services to use a subdomain of the parent organisation, such as webhooks.example.com. In this case, the DMARC record should be published on the subdomain, not the parent domain.

_dmarc.webhooks.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

This approach allows for more granular control over DMARC policies and reporting. Receivers typically honour the DMARC record on the subdomain, if present, over the parent domain record.

Tip: when using a hosted or managed DMARC setup, ensure that the provider supports per-subdomain configuration, to avoid unintended policy application.

A key consideration is the alignment of SPF and DKIM records with the DMARC record. The aggregate reports will show authentication failures if these records are not correctly aligned. For example, if the webhook service uses a different mail server than the parent organisation, the SPF record on the subdomain should include the IP addresses of these mail servers.

webhooks.example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 -all"

Advanced DMARC Configuration for Complex Webhook Scenarios

When dealing with complex webhook scenarios, a standard DMARC configuration may not be sufficient. Receivers typically expect a simple alignment between the domain in the From header and the domain in the SPF or DKIM records. However, webhooks often involve multiple domains and subdomains, which can lead to alignment issues.

A common pattern is for webhooks to use a subdomain of the primary domain, such as webhook.example.com. In this case, the DMARC record for the primary domain may not apply to the subdomain. To mitigate this, it is recommended to publish a separate DMARC record for the subdomain, such as:

_dmarc.webhook.example.com. IN TXT "v=DMARC1; p=none; sp=none; adkim=r; aspf=r"

This record specifies that the subdomain webhook.example.com should be treated separately from the primary domain example.com.

When using a hosted or managed DMARC setup, it is essential to ensure that the configuration allows for custom DMARC records for subdomains. Some hosted setups may automatically generate DMARC records for subdomains, while others may require manual configuration.

Tip: When configuring DMARC records for subdomains, it is crucial to test the setup thoroughly to ensure that it works as expected. This can be done by sending test emails from the webhook service and verifying that they are correctly authenticated and reported in the DMARC aggregate reports.

In some cases, webhooks may use multiple domains or subdomains, which can lead to complex alignment issues. To address this, it is possible to use the spf and adkim tags in the DMARC record to specify the alignment mode for subdomains. For example:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; sp=s; adkim=s"

This record specifies that the DMARC policy should be applied to subdomains in strict mode, which means that the domain in the From header must exactly match the domain in the SPF or DKIM records.

The aggregate reports will show which domains and subdomains are being used by the webhook service, and which ones are causing alignment issues. By analysing these reports, it is possible to identify and address any configuration issues, and ensure that the DMARC setup is working correctly for all subdomains and domains used by the webhook service.

Check your own domain

• Free DMARC checker
• Hosted DMARC

Related reading