Why is DMARC Failing
In this article, we cover the reasons why does DMARC fail, and what you should do to investigate and overcome this issue.
Before we dive into more details, let’s talk about the key value of DMARC, which is Domain Alignment.
DMARC Alignment & Reasons for DMARC Failures
To know why does DMARC fail, let’s first learn what is Domain Alignment? Domain Alignment is the core concept of DMARC – That is, verifying that the email address in the From: header is the actual sender of the message. Practically, this means that the domain SPF check (which is based on Envelope From: or Return-Path address) and the DKIM signing domain (d=example.net) are in alignment with the message From: address.
See the screenshot below:
Now, let’s get back to DMARC Failures, and discuss different cases that can lead to this scenario, how you should investigate, recognize, and come to a solution.
DMARC Failure Cases
Case 1: If you don’t set up DKIM Signature, ESPs such as GSuite & Office365 sign all your outgoing emails with their default DKIM Signature Key. (e.g d=domain.gappssmtp.com for Google & d=domain.onmicrosoft.com for Office365) – The default signing is NOT your domain. That’s only achieved by making the right configurations and entries in your DNS Provider (like GoDaddy, Rackspace, Cloudflare). So, because of misalignment, there will be a DMARC failure if someone receives an email from example.com but it is signed with example.gappssmtp.com or example.onmicrosoft.com.
You can see the examples of this case with actual screenshots from the EasyDMARC dashboard.
A DMARC fail due to GSuite using default DKIM Signature, and not authorized in SPF Record
A DMARC Fail due to Office365 using default DKIM Signature, and not authorized in SPF Record
Case 2: If you use Third-Party service providers (like MailChimp, SendGrid, HubSpot, ZenDesk) for your marketing, transactional and helpdesk emails, you have to permit them to send emails on your domain’s behalf.
That is achieved by pointing DNS entries (SPF & DKIM) from your DNS Provider (like GoDaddy, Cloudflare, or Rackspace) to authorize and ‘whitelist’ the given servers.
These providers sign your emails with their domain name by default, and your recipients generally see “via sendgrid.net”, “via thirdpartyprovider.com” messages on your emails, thus leading to DMARC misalignment and DMARC failure.
Below you can see the examples of this case with screenshots from the EasyDMARC dashboard.
A DMARC fail due to emails sent through a SendGrid account not properly signed with DKIM and SPF for a unique domain.
A DMARC fail due to emails sent through ZenDesk account not properly signed with DKIM and SPF for a unique domain.
Case 4: You are a spoofing target – That is, cybercriminals are sending emails on your domain’s behalf. These are unauthorized sources, failing both SPF & DKIM Authentication results, thus leading to DMARC Failure, which is mainly visible under the ‘Threat/Unknown’ tab of your EasyDMARC dashboard.
So you have started your DMARC journey and been receiving reports in your EasyDMARC dashboard, and you might think “What to do next?” and “How would I enforce my DMARC Policy to Reject without any risks of blocking my legitimate sources?”
Let’s cover this process with simple steps to help you succeed in this journey:
Step 1: Start your DMARC journey with Monitoring mode (p=none)
Step 2: Analyze your email ecosystem for the first 3-4 weeks
Step 3: Detect all your legitimate sources and authenticate them with SPF & DKIM
In our Plus & Business packages, we identify Email Vendors and guide you with all the configuration steps.
Step 4: Make sure you properly authenticate all your legitimate servers with SPF & DKIM and reach DMARC Alignment and Compliance
Step 5: Enforce your DMARC Policy to higher levels (Quarantine and/or Reject) gradually
You can find more about DMARC in DMARC RFC.