In our recent webinar, “Outsmarting Phishers: Maximize Your Domain Protection with DMARC,” Roger Grimes, Asem Abuelhija, and the EasyDMARC team discussed the critical importance of implementing email security measures to maximize your domain’s protection against phishing.
During the webinar, we received tons of insightful questions from attendees making this session even more engaging. Although we didn’t manage to cover them all in one go, we have prepared a blog article as promised.
In this article, explore detailed answers to each of your questions, along with additional insights and resources.
Answering Your Webinar Questions
I know the Gmail & Yahoo change affects companies that send 5000+ emails a day. Does it make sense to have DMARC for smaller companies that don’t send near that number?
Yes, it does. DMARC should be implemented by any organization, regardless of their size. By implementing DMARC with reporting, you will receive reports to analyze your outgoing email ecosystem. This helps in identifying email sources, authenticating & aligning them, enhancing email deliverability, and later enforcing protection against cybercriminals who may send spoofing emails on your domain’s behalf.
Is having a DMARC record enough, or does one need a monitoring service like EasyDMARC to monitor the flow of emails?
Having a DMARC record itself is not sufficient. As Yahoo reported in their sender guidelines, having a RUA tag is crucial. The RUA tag activates reporting mechanisms with DMARC, providing reports from receiving servers about your email authentication and alignment health. Utilizing tools like EasyDMARC is recommended as it translates complex reports into human-friendly data, aiding in DMARC investigation, SPF/DKIM configuration, and enforcement.
I support DMARC as always, but is it effective in flagging BEC emails from free webmailers?
DMARC operates on the domain level, protecting your specific domain from being exploited by hackers. However, it does not directly address hackers sending spoofing emails from freemail providers like @gmail or @yahoo. For such cases, mailbox providers are developing advanced algorithms to detect fraudulent activities.
Are DMARC aggregate reports sent only by Microsoft, or are they sent by all email providers?
Currently, DMARC aggregate reports are sent by major Mailbox Providers (MBPs) such as Google, Yahoo, and Microsoft, alongside numerous other MBPs that support DMARC reports.
What are the risks to an organization implementing DMARC?
The main risks involve implementing DMARC without reporting, depriving the organization of valuable data for analysis, and fixing authentication issues. Rushing into enforcement (p=reject) without proper expertise can also lead to legitimate emails being blocked, risking domain reputation and important communications failing to reach recipients.
Is there any restriction on 255 characters on both SPF & DKIM records?
The restriction of 255 characters per TXT record in DNS applies generally and isn’t specific to SPF or DKIM. Modern DNS systems have adapted to handle longer records seamlessly, often splitting them and enclosing them within double quotes when necessary.
I have my system setup on EasyDMARC and set to Reject. In my aggregate reports, I see several entries that fail SPF and are SPF unaligned, but the delivery status is Delivered. Should I be doing something with these entries? Is this the way it should work?
If you’ve set your policy to Reject and notice emails being delivered despite SPF being unaligned, it likely indicates that DKIM is implemented for the given source. This scenario is common with many bulk-sending ESPs. Some of these ESPs don’t support SPF alignment because they handle your bounces using their own domain in the Return-Path header. EasyDMARC includes this information in your report, so if you see “SPF non-capable,” you can safely ignore it.
Would adding a sender to SPF make DMARC succeed automatically? How would DMARC still fail if a sender was in SPF?
Adding a sender source to SPF alone may not guarantee DMARC success, especially with bulk email sending platforms. These platforms manage SPF through their own domains, and simply adding them to your SPF may not ensure DMARC alignment. Additionally, DKIM authentication is equally important for DMARC success and should be appropriately configured.
I know that Google and Yahoo are moving to enforcement. Have you heard whether or not Microsoft is considering doing this as well?
Yahoo domains (@yahoo, @aol, etc.) are already at an enforced level (p=reject). Google domains (@gmail) will eventually move to p=reject very soon. There are no official statements from Microsoft on when they will move their domains (@outlook, @live, etc.) to p=reject, but we hope to see that sometime soon.
Do you suggest using a subdomain to send your ESP emails? Is it easy to set up with EasyDMARC?
Regarding your email strategy, it is good to segment all your sending types at the subdomain level (marketing, transactional, etc.). For EasyDMARC, if you don’t have an explicit DMARC Record at your subdomain level, then your root domain will automatically gather reports for all subdomains. This is what we usually recommend to our customers, to have every report in a single dashboard.
If my domain has developed a bad reputation due to the prior lack of DMARC, what steps should we follow to restore our reputation?
Bad reputation is rarely solely attributed to the prior lack of DMARC. Domain reputation depends on thousands of data points, primarily your sending practices. You need to identify what went wrong, especially with spam complaints or bounce rates, in your previous campaigns. DMARC, SPF, and DKIM are just the initial steps to begin building a good reputation with Mailbox Providers (MBPs), but your overall sending practices are the primary determinant of your domain’s reputation.
I’m trying to decide if I need to sign up for a paid EasyDMARC account, but I don’t think my company fits the profile of EasyDMARC’s typical customer, which is much larger. I just want to confirm my thoughts on this, please. I run a small company (just three people) and I only have three sending sources: Google Business Email (customer communications), Klaviyo (marketing emails), and Shopify (transactional emails). All of my ESPs, Google, Klaviyo, and Shopify, handle DKIM and SPF for me automatically.
SPF and DKIM will always be handled by your ESPs. With EasyDMARC, you can analyze the outgoing email stream, define any authentication issues, fix them, and work on enforcing your DMARC policy to p=reject. We recommend EasyDMARC for every organization, regardless of its size. You will always be proactive with any changes within your organization, set appropriate alerts, check blacklists of the IP addresses in use with the ESPs, and always be ahead of the game.
Is Microsoft 365 expected to support BIMI any time in the near future?
We don’t have any information on this. We hope so soon.
Is it okay to stick with relaxed alignment, or should you aim for strict?
It’s totally okay to stick with relaxed alignment, and we usually recommend that to our customers. Many ESPs currently provide SPF and/or DKIM alignment at the subdomain level, and strict alignment may cause issues with that. You can fully rely on your DMARC policy (p=reject) to block any hackers who will try to send fraudulent emails on your domain’s behalf, rather than relying on strict or relaxed alignment.
As a business domain owner, do I need to register for lookalike domains to avoid abuse and reputational damages?
It is highly advisable for you to register all lookalike domains and implement a strict DMARC policy (p=reject) on them.
When should you use the “pct” setting in DMARC?
The “pct” (percentage) tag is usually recommended during the DMARC enforcement process. As you gradually enforce your DMARC policy, tracking how receivers treat your emails, the “pct” tag can be applied in that scenario. However, there are discussions that the “pct” tag will be removed with DMARCbis.
I have implemented DMARC but without “rua.” Am I in compliance with the new policy, or is “rua” mandatory?
If your email sources are SPF and/or DKIM aligned, passing authentication, and you have DMARC without ‘rua’, then yes, you are in compliance with the new policy. However, this scenario assumes an ideal situation. In reality, administrators often lack awareness of their SPF and/or DKIM alignment or authentication checks without any data in place. The best way to obtain reports on these is through DMARC RUA. Therefore, we should treat RUA as mandatory, even though it is not explicitly stated in the new sender guidelines.
Why is HubSpot not SPF capable?
SPF verifies the Return-Path address, not the From address domain. The Return-Path is used to handle bounces or failed email deliveries. HubSpot and other ESPs handle your email bounces on your behalf, thus they have their own domain in the Return-Path for this purpose. Other ESPs will provide you with CNAME mapping for SPF alignment and be capable of this.
Recently, someone sent phishing attacks using our domain, where SPF alignment was in place. In that case, if the attacker implements DKIM for the server where emails were sent, would he pass the DMARC policy?
By just reading the question (without actual email headers), it seems that the email’s SPF alignment was in place, but the authentication failed since the hacker sent an email using their own server. For the hacker to implement custom DKIM with your own domain, they would need access to your DNS zone to set up the Public key. So no, hackers can’t get DKIM aligned if they don’t have access to your DNS.
So with EasyDMARC, we don’t have to add a DNS record at the Hosting server, and that can be done from EasyDMARC’s platform?
With EasyDMARC Managed services (Managed DMARC, MTA-STS, EasySPF), you need to add a one-time TXT or CNAME record in your DNS for verification. After that, everything else will be managed directly from your EasyDMARC portal.
What happens on April 1 that emails without a DMARC record might get rejected?
First, it’s important to understand that it is not only for the DMARC record itself, but for the overall authentication and alignment of the email source in use. According to Google’s Sender Guideline FAQ, “Starting in April 2024, we’ll begin rejecting non-compliant traffic.” This means that non-compliant emails (failing both SPF and DKIM alignment) will begin getting rejected.
These were the most common questions we received during the webinar, and we hope that our responses provide you with valuable insights. For those who may have missed the webinar, the recording is available through the following link. Feel free to contact us if you have any further questions or require additional assistance with anything DMARC.