Answering Your Webinar Questions: What Do Most IT Teams Get Wrong About DMARC?

Our recent webinar, “What Do Most IT Teams Get Wrong About DMARC?,” sparked a lot of interest and generated more questions than we had time to answer live. From setup concerns to platform expectations, it’s clear that DMARC is still an area full of uncertainty for many IT and security teams. To make sure your questions don’t go unanswered, we’ve compiled some of the most common and insightful ones here, along with detailed answers from our experts.

Q&A From the Webinar

• Is it better to start your DMARC journey early, or long after the email has been in use?

The earlier, the better.”Ideally, SPF, DKIM, and DMARC should be set up before you start using the email. You can then adjust the setup by monitoring sending practices through DMARC reports.

• How might this tie in with ISO 27001?

When it comes to ISO 27001 certification, the standard’s requirements center on establishing an Information Security Management System (ISMS) to manage and mitigate risks. The certification process requires an organization to conduct a risk assessment, where threats like phishing and email spoofing are often identified. DMARC directly addresses this by providing a mechanism to prevent unauthorized use of your domain. Furthermore, DMARC’s reporting capabilities offer valuable threat intelligence, helping to satisfy Annex A controls related to communications security and monitoring. By including DMARC in your Statement of Applicability (SoA) and showing its active use during an audit, you can demonstrate that you are proactively managing a significant risk. In essence, while not explicitly mandated, DMARC’s implementation provides a clear, verifiable way to meet key ISO 27001 objectives.

• What holds me back from acting on red DMARC flags is that on domains where I have perfectly set DKIM and SPF records for both the webhosting provider and outlook.com, I still get DMARC warnings about *some* but not all emails being ‘misaligned’ for DMARC both on the webhosting provider and outlook. The messages mention there could be problems with ‘Return paths’ but are very vague and confusing, leading to a dead end. How can the same records sometimes look perfect to DMARC and sometimes not so much?

In case of ideal configurations, when both SPF and DKIM for your sending sources  are set up, the vast majority of your legitimate emails will pass DMARC checks. In minor cases, SPF might fail (e.g., for server-generated emails like OOO notifications or when emails are auto-forwarded), with DKIM acting as a backup since it survives in most cases. Even with a solid setup, a few emails might fail DMARC checks, which is generally acceptable. Make sure there are no misconfigurations on your end; the rest is beyond your control. Ultimately, the goal of your DMARC project is to gradually achieve the “p=reject” policy.

• DKIM Short Keys: Do you have a checker to test all of my settings and make recommendations?

Regarding DKIM short keys, such as 512-bit keys, it’s important to note that using such keys is not recommended, as they are easier to decrypt. It’s better to use at least 1024-bit DKIM keys, and the best practices for now are using even longer ones, 2048-bit DKIM keys. 

EasyDMARC can help you check the syntax, validity, and alignment of your DKIM records to ensure they are correctly published. In general, the EasyDMARC system can automatically detect validation failures for SPF, DKIM, DMARC, and more. Beyond auto-detection, it provides a comprehensive toolset to review your settings and resolve any misconfigurations. Additionally, our team of DMARC experts is available to guide you through any issues you may encounter with your sending practices.

• Protecting the subdomains: Do we create a new DMARC, DKIM and SPF records same as the original main domain name?

It’s worth noting that subdomains inherit the root domain’s DMARC policy by default, and DMARC reports for subdomains are sent to the root domain’s feedback addresses (RUA and RUF). If a subdomain needs a separate DMARC policy, this can be specified in the root domain’s DMARC record using the sp= tag. For SPF and DKIM, if a subdomain is used to send emails, you should publish SPF and DKIM records explicitly at the subdomain level to ensure those emails pass authentication checks.

• Non-compliant / threat unknown source results from aggregate reports – what is the best way to investigate where the sending sources are coming from?

The most effective way to identify the origin of sending sources is by checking their IP addresses. If a source IP has a PTR record (Reverse DNS), it can reveal the exact source or the company that owns the IP, as well as its geographical location. This information provides valuable insights when investigating whether the emails listed in the Non-compliant or Threat/Unknown sections were legitimately sent by the domain owners or originated from outside the organization. By analyzing the source IPs, you can better determine the legitimacy and origin of these messages.

• I had a client say this to me. Are they right?  “All of those technologies SPF/DMARC/DKIM have nothing to do with our ability to receive messages; those are systems relating to sending messages to other servers.”

The answer is essentially “Yes.” SPF, DKIM, and DMARC focus on authenticating outgoing email from your domain to ensure messages pass checks and are delivered successfully. They do not affect your domain’s ability to receive email. Incoming mail is handled by your mail server’s configuration, filtering, and security measures, which are outside the scope of DMARC.

• What about domains that simply redirect to a working domain? Do the recdirecting domains need to be set up with DMARC as well?

If a domain (e.g., example.help) is used only for web redirection, such as when entering the domain in a browser and being redirected to example.com, it generally does not need DMARC, SPF, or DKIM, because it isn’t sending email and is considered an inactive or parked domain. However, since any domain could potentially be used by attackers to send spoofed emails, you can still publish DMARC, SPF, and DKIM records to fully protect your inactive or redirecting domains from misuse.

For more details on setting up email authentication for domains that don’t send email, see our article: How to publish SPF, DKIM, and DMARC for inactive domains to prevent abuse.”

• I am not sure how to interpret the aggregate reports.

Specifically regarding EasyDMARC aggregate reports, we have a detailed guide on how to analyze them, which you can find at the link below: Analyzing DMARC aggregate reports.

• Is there a change that happens on receiving email servers for legitimate, DMARC-passing email when the policy goes from none to quarantine or reject? Or does it only impact email that fails DMARC?

DMARC policies apply only to emails that fail DMARC validation. When you enforce a “p=quarantine” or “p=reject” policy, only the failing emails will be quarantined as spam or rejected. Legitimate emails that pass DMARC checks are not affected by the policy and should be delivered to recipients’ inboxes as usual.

• Apart from the listed IP Addresses in SPF, why do I see other Ip’s too in RUA report?

DMARC aggregate reports include data on all emails sent or attempted to be sent on behalf of your domain. While your SPF record lists the authorized sending IP addresses, the reports will also show emails that may be illegitimate, sent from outside your organization. In addition, if you use services that authenticate via SPF on a subdomain level, those IPs will appear in your DMARC reports even if they are not listed in the root domain’s SPF record. Finally, you may also see IPs from legitimate sources that are used by your domain but not yet fully configured with SPF.

• How to configure DMARC with AWS SES and GoDaddy domain? Any consideration?

It’s important to note that Amazon SES supports SPF setup on a subdomain level. You can find the detailed steps for Amazon SES SPF and DKIM setup in our knowledge base article below: SPF and DKIM setup for Amazon SES

Final Thoughts

DMARC can feel complex at first, but most challenges boil down to common misconceptions, misconfigurations, or incomplete setups. By addressing these questions, we hope to clear up some of the confusion and help more organizations move toward effective enforcement.

If you’d like to go deeper, explore our knowledge base, take a free consultation with our team, or check out EasyDMARC’s tools to simplify and strengthen your email security journey.