DMARC, SPF, and DKIM compliance on root domains not used for sending email
Michael Ko
Co-founder & CEO, Suped
Published 17 Jul 2025
Updated 18 Aug 2025
8 min read
When you think about email authentication protocols like DMARC, SPF, and DKIM, your mind probably jumps to your active sending domains. Those domains you use daily for marketing, transactional emails, or internal communications definitely need robust configurations to ensure deliverability and protect against spam and phishing. But what about the domains you own that aren't actively sending email?
It’s a common misconception that if a root domain isn't sending emails, it doesn't require these critical DNS records. I've heard this question many times, and the answer is consistently clear: every domain you own should have appropriate DMARC, SPF, and DKIM records, even if they're not used for email transmission. This proactive measure is essential for comprehensive email security.
Neglecting these records on unused domains leaves a significant security vulnerability that malicious actors can exploit. By configuring your non-sending domains correctly, you establish a clear policy that tells the world, no email should originate from here, effectively shutting down a common avenue for spoofing and phishing attacks.
The primary reason to secure domains not used for sending email is to prevent domain spoofing. Attackers constantly scan for domains with weak or absent authentication records. If they find one, they can forge emails that appear to come from your domain, tricking recipients into believing they are legitimate. This can lead to serious security breaches, financial fraud, and significant damage to your brand's reputation.
Even if your root domain is only used for your website (like yourcompany.com) and all email originates from a subdomain (e.g., mail.yourcompany.com), the root domain is still a prime target for spoofing. An attacker can send an email pretending to be ceo@yourcompany.com to an employee, and without proper DMARC, SPF, and DKIM, that email could land in the inbox.
The risk of unauthenticated domains
Phishing attacks: Malicious actors can send emails impersonating your brand or executives, leading to credential theft, malware installation, or wire fraud.
Brand reputation damage: When your domain is used in phishing scams, customers and partners lose trust in your legitimate communications, impacting your brand's credibility.
Blocklisting risks: Even if you don't send email from a domain, excessive spoofing could lead to its inclusion on email blocklists (or blacklists), affecting other legitimate services or subdomains associated with it. You can learn more about this in our guide to what happens when your domain is on an email blacklist.
Think of it this way: your unused domains are like unlocked back doors into your email ecosystem. While you may have fortified your main entrance (your sending domains), these neglected points can still be breached. Implementing the correct DNS records closes these back doors, preventing unauthorized use.
The principle applies to all domains, including those purely for websites, parked domains, or domains acquired for future use. For an in-depth understanding of the best practices for setting up these records, check out our guide on how to configure DMARC, SPF, and DKIM.
Implementing SPF and DKIM for non-sending root domains
For domains that do not send email, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records still play a critical role, primarily in supporting your DMARC policy. The configuration for these records will be different from that of an active sending domain, as their purpose is to explicitly state that no legitimate email should originate from the domain.
For SPF, you should publish a null or v=spf1 -all record. This record declares that no server is authorized to send email on behalf of your domain, and any email claiming to be from it should be considered unauthorized. The -all mechanism explicitly tells receiving servers to hard fail any mail that appears to come from your domain.
SPF record for a non-sending domainDNS
v=spf1 -all
For DKIM, if your domain truly does not send any email, you don't necessarily need to publish a DKIM record. DKIM is used to cryptographically sign outgoing emails, proving their authenticity. If no emails are sent, no signatures are generated. However, some security postures or monitoring tools might benefit from an explicit null DKIM record. The most common approach for non-sending domains is to simply not publish any DKIM records, relying on the DMARC record to handle unauthenticated mail.
Remember, the goal is to provide clear signals to email receivers that no legitimate email should come from this domain. These SPF and (absence of) DKIM records, combined with a strong DMARC policy, form an impenetrable wall against spoofing attempts from your unused root domains. For more details on this, you can review this Cloudflare article on protecting domains without email.
The crucial role of DMARC
While SPF and DKIM provide foundational authentication, DMARC (Domain-based Message Authentication, Reporting & Conformance) is the linchpin that brings it all together, especially for non-sending domains. DMARC tells receiving mail servers what to do with emails that fail SPF or DKIM authentication, and importantly, it provides reporting on these failures.
For a domain that explicitly should not send email, the strongest DMARC policy, p=reject, is ideal. This policy instructs receiving servers to completely reject any email that claims to be from your root domain but fails DMARC checks (meaning it wasn't authorized by your SPF or DKIM records). This effectively prevents unauthorized emails from ever reaching an inbox. For more specific examples, you can look at DMARC record and policy examples.
While setting p=reject is the goal, I always recommend starting with p=none and enabling reporting (rua tag) to monitor any unexpected email activity. Even for domains you believe don't send mail, DMARC reports can reveal hidden legitimate email streams (e.g., system alerts, old services) or active spoofing attempts. Once you confirm no legitimate mail is being sent from the root domain, you can safely transition to set DMARC to reject.
Without DMARC on non-sending domain
Vulnerability: Domain is easily spoofed, allowing attackers to send fraudulent emails that appear legitimate.
Lack of visibility: No insight into who is sending email purporting to be from your domain, whether legitimate or malicious.
Trust Erosion: Customers and partners may become wary of emails from your brand due to past phishing incidents.
With DMARC on non-sending domain (p=reject)
Protection: Unauthorized emails are rejected by receiving servers, preventing them from reaching inboxes.
Reporting: DMARC reports provide continuous insight into email activity, even failed attempts, helping you detect ongoing spoofing.
Brand Integrity: Reinforces trust and protects your brand's reputation by preventing fraudulent email delivery.
Implementing DMARC on all your domains, regardless of their sending status, is a fundamental step towards a truly secure email environment. This approach is highly recommended by email security experts globally, including the DMARC.org working group.
Common considerations and best practices
Beyond simply publishing the records, it’s vital to adopt some best practices to ensure your non-sending domains are truly protected. First and foremost, never assume a domain isn't sending mail without verifying it through DMARC reports. I’ve seen countless times where low-volume system emails or forgotten services unexpectedly send mail from what was thought to be a non-sending domain.
Regularly reviewing DMARC aggregate reports (rua tag) for all your domains, even the non-sending ones, provides invaluable insight. These reports will show you if any email is attempting to originate from your domain, whether legitimate or malicious. It’s your early warning system for potential spoofing attacks. This ties into the general advice to monitor both top-level and DKIM subdomains.
Another crucial practice is to inventory all your domains, including legacy domains, parked domains, or acquisition-related domains. Each one represents a potential entry point for attackers. Establishing a clear, consistent policy for all of them minimizes your attack surface. It's a foundational element of a strong email security posture.
Proper configuration of DMARC, SPF, and DKIM on your root domains that do not send email is not just a recommendation; it's a security imperative in today's threat landscape. By implementing these measures, you protect your brand, safeguard your recipients, and maintain a robust email infrastructure.
Record Type
Recommended Value for Non-Sending Domains
Purpose
SPF (TXT Record)
v=spf1 -all
Declares that no email should be sent from this domain. Any mail attempting to do so will hard fail SPF.
DKIM (TXT Record)
None (do not publish DKIM records)
Since no emails are sent, no DKIM signatures are generated, so no records are needed. DMARC will then fail for DKIM.
Instructs receiving servers to reject emails that fail DMARC and provides reports on this activity to the specified address.
Views from the trenches
Best practices
Always publish a DMARC policy for all your domains, even those not used for sending email, to prevent spoofing.
Use a 'p=reject' policy for non-sending domains to ensure unauthorized emails are dropped, enhancing security.
Configure SPF with an '-all' mechanism on non-sending domains to explicitly state that no legitimate mail originates from them.
Set up DMARC reporting ('rua' tag) on all domains, including non-sending ones, to gain visibility into any unexpected email activity or spoofing attempts.
Common pitfalls
Assuming a domain doesn't need DMARC, SPF, or DKIM if it's not actively sending mail, leaving it vulnerable to spoofing.
Neglecting to monitor DMARC reports for non-sending domains, missing opportunities to detect hidden email streams or malicious activity.
Forgetting to inventory and secure all owned domains, including parked or legacy ones, which can become targets for abuse.
Using a 'p=none' DMARC policy long-term on non-sending domains, as it won't actively block spoofed emails from reaching inboxes.
Expert tips
For domains not used for email, a simple SPF record like 'v=spf1 -all' combined with a DMARC 'p=reject' policy effectively prevents unauthorized sending.
While DKIM records are not strictly necessary for non-sending domains, having a DMARC record that directs email receivers to reject unauthenticated mail is crucial.
Periodically review DNS configurations for all your domains to ensure SPF, DKIM, and DMARC records remain correctly configured and up-to-date.
Consider leveraging a DMARC monitoring tool to simplify the process of reviewing reports for all your domains, regardless of sending status.
Expert view
Expert from Email Geeks says that a DMARC record is essential for all domains, as any domain can be spoofed using tools like Swaks, regardless of whether it sends email.
2024-05-08 - Email Geeks
Expert view
Expert from Email Geeks advises caution when assuming an apex domain sends no mail without reviewing DMARC reports, as low-level system emails might still originate from it.
2024-05-08 - Email Geeks
Strengthening your email security perimeter
The message is clear: DMARC, SPF, and DKIM compliance isn't just for your active sending domains. It's for all your domains, including those not actively sending email. This comprehensive approach is a cornerstone of modern email security, protecting against the pervasive threat of domain spoofing and phishing.
By proactively implementing null SPF, minimal or absent DKIM, and a strict DMARC p=reject policy on your non-sending root domains, you are fortifying your entire email ecosystem. This not only enhances your security posture but also safeguards your brand reputation and contributes to a safer email environment for your customers and partners.
Make it a priority to audit all your domains and ensure these foundational authentication protocols are in place. Your proactive efforts now will pay dividends in preventing future security incidents and maintaining trust in your brand.
