How DNS Configurations Impact Your Email Security: Answering Your Webinar Questions

During our latest webinar, “How DNS Configurations Impact Your Email Security,” we explored the vital role that DNS records play in protecting your email domain. With email remaining the top target for phishing attacks, proper configuration of SPF, DKIM, and DMARC has become essential for both email deliverability and security.

Our audience raised many insightful questions, and while we couldn’t address all of them live, we’ve compiled this blog post to cover the most important ones. Whether you’re enhancing your email security setup or fine-tuning your DNS management, these answers will provide valuable guidance. Let’s jump into the Q&A.

I am thinking about adding EasyDMARC to my clients’ domains for monitoring and quarantining, but I’m concerned about issues if it’s set up incorrectly. Could it disrupt email services or data storage?

Adding EasyDMARC to your clients’ domains for monitoring is a great way to enhance email security. While misconfiguration can cause issues, you’ll have solutions for every misstep. EasyDMARC provides user-friendly reports that make it easy to quickly identify what needs to be configured. Additionally, we offer detailed configuration guides for various sending sources. If you encounter any challenges, you can always open a support ticket, and our team will be happy to assist you.

Moreover, EasyDMARC won’t disrupt your data storage, as we handle the reports on your behalf, eliminating the need to add your email to the RUA and RUF tags.

Always begin with a DMARC policy set to ‘none,’ which serves as the monitoring phase to avoid any disruption. Once you’ve confirmed that all your legitimate sources are DMARC compliant, you can proceed to the enforcement stage. With the ‘quarantine’ policy, emails failing the DMARC check will end up in the recipient’s spam folder. With the ‘reject’ policy, emails failing the DMARC check will be outright rejected/blocked, which is our ultimate goal.

When setting up DMARC with Quarantine, could the same concerns about disrupting services apply? Are these realistic fears?

When setting up DMARC with a ‘quarantine’ policy, concerns about service disruption are valid but can be effectively managed. Legitimate emails could be marked as spam if DMARC isn’t properly configured, such as misaligned SPF and DKIM records.

You can mitigate this risk by starting with the monitoring phase, using the DMARC ‘none’ policy to identify any issues before enforcing quarantine. Regularly review DMARC aggregate reports to identify which legitimate senders are failing and why. Our easy-to-read reports make this process straightforward. Once all legitimate sources are DMARC compliant, you can gradually move to the ‘quarantine’ policy.

SPF and DKIM seem to do the job, so how does DMARC enforce the policies? Ultimately, isn’t it up to the receiving mail servers?

SPF and DKIM are essential components of email authentication, but DMARC provides an additional layer by specifying how receiving mail servers should handle messages that fail SPF and DKIM checks by checking the Alignment. Here’s how DMARC enforces policies:

1. SPF and DKIM Validation:

• SPF: Confirms whether the sender’s IP address is authorized to send emails on behalf of the domain.
• DKIM: Ensures that the email hasn’t been altered in transit and that it was indeed sent from an authorized domain using a digital signature.

2. DMARC Alignment:

• DMARC checks whether the domain used in the “From” header matches (or is aligned with) the domain used in SPF and/or DKIM.
• Even if SPF or DKIM passes individually, the email can fail DMARC if the alignment is incorrect.

3. DMARC Policy Enforcement:

• None: No action is taken, but reports are generated to monitor email traffic.
• Quarantine: Messages that fail DMARC will be delivered to the recipient’s spam folder.
• Reject: Messages that fail DMARC are blocked entirely.

DMARC is essential since even though SPF and DKIM help authenticate email, DMARC ensures that the email is using them correctly and that the domain owner has control over what happens if authentication fails. DMARC also provides feedback through aggregate and failure reports, which SPF and DKIM alone don’t offer.

If the email sender is [email protected], but the ‘send from’ address is [email protected], will DMARC create an issue? How does DMARC apply to shared mailboxes?

DMARC works on a domain level, just like SPF and DKIM. It checks the alignment of SPF and DKIM, in this case, for the domain test.com in the “From” field since DMARC is for outbound emails. If the alignment is correct and SPF and/or DKIM authentication passes, then the email will pass DMARC successfully. 

DMARC Alignment: DMARC checks the alignment between the domain in the “From” header ([email protected]) and the domains used by SPF and DKIM.

SPF Alignment: DMARC ensures the domain in the “Return-Path” (which typically represents the “Return-Path” address) aligns with the domain in the “From” header ([email protected]). If the “Return-Path” ([email protected]) doesn’t align with the “From” domain, this could cause DMARC to fail.

DKIM Alignment: DMARC checks whether the domain used in the DKIM signature aligns with the “From” domain. When the DKIM signing domain is (test.com) while the “From” domain is ([email protected]), the alignment would pass.

What if I have lots of SaaS applications sending emails and need to include 10+ entries in SPF?

EasyDMARC has the solution for this, which is the EasySPF. It is a dynamic platform that overcomes the limitations of the SPF by flattening the includes into IP addresses so that, going forward, you’ll avoid exceeding the DNS lookup limitation. You will also be able to manage your SPF record directly from EasySPF, and most importantly, you will have an overview of your SPF entries to see which entry is being used to send out emails and which is not. This will enable you to remove unnecessary or unused records from your SPF setup, maintaining optimal hygiene.

How do SPF and DMARC rules apply to group emails? I’ve noticed issues when sending on behalf of groups.

When you reach the enforcement level with DMARC, group email systems like LISTSERV will detect this. When LISTSERV receives a posting to a mailing list, it automatically queries DNS to check if the sending domain in the ‘From:’ address has a DMARC record with a policy of ‘p=reject’ or ‘p=quarantine’. This process is automatic; no additional configuration is required as LISTSERV handles this query by itself. 

If your DMARC policy is set to “none,” no action will be taken. However, when your DMARC policy is set to an enforcement level (quarantine or reject), LISTSERV will automatically modify the “From” address to theirs and use your From address as the display name to help prevent email delivery issues.

For organizations sending fewer than 5,000 emails per month, is it sufficient to have only SPF and DMARC, without DKIM?

While DMARC requires either SPF and/or DKIM to pass, auto-forwarded emails often present challenges. SPF typically fails for auto-forwarded emails because the return-path address changes. If DKIM is configured, the email will pass DMARC based on DKIM unless the recipient alters the header, which can also cause DKIM to fail. Therefore, DKIM is generally more reliable than SPF in these cases. We recommend configuring DKIM to ensure better email authentication and delivery.

Do we need DNS records (SPF, DKIM, DMARC) on both the root domain and the subdomain for email purposes? What’s the correct way to configure a subdomain?

When it comes to subdomains, if they are used to send out emails or if they are required by some ESPs, such as Amazon SES, which requires configuration at the subdomain level (creating a custom return path), then you definitely need to create SPF and DKIM records for those subdomains.

Regarding DMARC, it is not necessary to have a separate DMARC record for your subdomains, as the DMARC policy of the root domain will also apply to the subdomains. Of course, you do have the option to set a different policy for subdomains using the “sp” tag. While having a separate DMARC record for a subdomain is not incorrect, it is generally unnecessary.

Should I add a DKIM public key for every sending platform to my DNS, including my web server, if it uses PHPSendmail? If the website uses an SMTP account on an ESP like MS Exchange, do I still need to add the server’s DKIM public key? If not, where do I find the DKIM public key in the ESP?

DKIM is implemented separately for each sending platform. For example, if you use both Google and SendGrid, each will provide its own DKIM keys during configuration. You will need to add the public DKIM keys provided by each platform to your DNS zone to ensure proper email authentication.

This means that you should add a DKIM public key for every sending platform you use, including your web server, if it sends emails directly using PHP Sendmail. For an ESP like MS Exchange, add the DKIM public key provided by the ESP to your DNS records. To find the DKIM public key for an ESP, consult their documentation, check their admin console, or contact their support team. Proper DKIM configuration across all platforms ensures better email authentication and protects your domain’s reputation.

What if I add the MX mechanism of the sending ESP to my DNS records? Will that help with SPF?

Adding the MX record of the sending ESP to your SPF record is incorrect if the ESP does not explicitly provide it. For example, Google provides an include directive in SPF records because it covers thousands of shared IP addresses that need to be whitelisted for SPF to pass. Using just the MX record instead of the include directive will not encompass the same set of IP addresses and will likely include far fewer IPs, which can lead to SPF failures.

The purpose of the SPF records is to specify which servers are authorized to send emails on behalf of your domain, and its functionality is to help prevent unauthorized servers from sending emails that appear to come from your domain.

Most Email Service Providers (ESPs) offer either an include mechanism or a list of IPs that you can add to your DNS by combining them with your existing SPF record. If you don’t have an SPF record, you will need to create one and add it directly to your DNS.

How can I improve my domain’s reputation if I’m not using DMARC? Should I configure DMARC in my DNS and then wait?

Improving your domain’s reputation without using DMARC can be challenging, but configuring DMARC is an essential step in enhancing your email security and reputation.

Here’s a plan to help you improve your domain’s reputation:

1- Configure DMARC: Start with a none policy for monitoring, then move to quarantine or 

reject as you ensure all legitimate sources are compliant.

2- Ensure SPF and DKIM: Properly configure SPF and DKIM records to authenticate your emails.

3- Maintain List Hygiene: Clean your email lists regularly and monitor engagement to improve deliverability.

4- Avoid Blacklists and Spam Traps: Check for blacklisting and avoid sending emails to spam traps.

5- Improve Content and Practices: Send relevant, high-quality content and maintain consistent sending practices.

6- Monitor and Adjust: Continuously track your domain’s reputation and adjust your strategies based on performance data.

What is the significance of ‘ri=86400’ in the DMARC record? Why do some people use less or not at all?

The ri tag stands for the Reporting Interval which marks the frequency of received XML reports in seconds. The default is 86400 (once a day). Regardless of the set interval, in most cases, ESPs send the reports at different intervals (usually every 24 hours).

Can you recommend resources to learn more about DMARC, DKIM, and SPF?

You can check out our EasyDMARC Academy, Knowledge Base, and Blog to get more information about everything related to SPF, DKIM, and DMARC.

Conclusion: DNS Configurations and Email Security

We hope these responses have offered you valuable insights into how DNS configurations impact your email security and the steps you can take to strengthen your domain protection. Remember, email security requires ongoing attention – regularly reviewing your DNS settings and keeping your authentication records up-to-date is key to staying protected.

If you missed the live session, you can watch the webinar recording. And as always, feel free to get in touch if you have any additional questions or need support on your email security journey.