How should DMARC, SPF, and DKIM records be configured for domains that do not send email?
Matthew Whittaker
Co-founder & CTO, Suped
Published 26 May 2025
Updated 15 Aug 2025
8 min read
It might seem counterintuitive to configure email authentication records for domains that never send email, but it's a critical step in modern cybersecurity. Many domain owners focus solely on securing their sending domains, often overlooking the non-sending ones, such as parked domains, future project domains, or infrastructure-only domains. However, these seemingly dormant domains can become prime targets for malicious actors seeking to spoof your brand and launch phishing attacks.
The internet is rife with bad actors attempting to impersonate legitimate businesses. If a domain lacks proper email authentication, it creates an open invitation for spoofing. Spammers and phishers can easily send emails that appear to originate from your domain, tricking recipients and potentially damaging your brand's reputation. This is why establishing a robust defense, even for domains that are not actively used for email, is essential.
By correctly configuring DMARC, SPF, and DKIM records for these non-sending domains, you explicitly inform email receivers worldwide that no legitimate email should ever originate from them. This proactive measure significantly reduces the risk of your domain being exploited for nefarious purposes, protecting your brand and anyone who might otherwise fall victim to a spoofing attack. It's a foundational element of a strong overall email security posture.
Even for domains that do not send any email, establishing proper SPF (Sender Policy Framework) records is fundamental. SPF allows a domain owner to specify which mail servers are authorized to send email on behalf of their domain. For a domain that should never send email, the SPF record should explicitly state this fact.
The correct SPF record for a non-sending domain is simple yet powerful: v=spf1 -all. This record indicates that no server is authorized to send email for the domain. The -all mechanism specifies a hard fail, meaning any email originating from this domain that is not from a listed authorized server (and in this case, there are none) should be rejected. This is the strongest signal you can send to receiving mail servers, instructing them to discard any email pretending to be from your non-sending domain.
Publishing an SPF record like this is a core component in preventing email spoofing. Without it, a spammer could forge emails using your domain as the sender, potentially leading to your domain being added to a blacklist or blocklist. You can learn more about how SPF helps prevent outgoing email from being marked as spam.
SPF record for a non-sending domainDNS
yourdomain.com. IN TXT "v=spf1 -all"
DKIM for non-sending domains
DKIM (DomainKeys Identified Mail) works differently from SPF. It involves digital signatures applied to outgoing emails, which receiving servers then verify using a public key published in your domain's DNS. For domains that genuinely do not send email, the approach to DKIM is straightforward: you typically don't need to publish any DKIM records.
If a DKIM signature is present on an email claiming to be from your domain, but there is no corresponding public key published in your DNS, the DKIM authentication will automatically fail. This failure, especially when combined with a strong DMARC policy, contributes to the email being identified as illegitimate. Some might consider publishing an explicit invalid key or a wildcard DKIM record, such as *._domainkey.yourdomain.com TXT "v=DKIM1; p=", to signal that no valid keys exist. However, the consensus among many experts is that simply not publishing a DKIM record is sufficient and less prone to misinterpretation for non-sending domains.
The primary goal for non-sending domains is to prevent any email from passing authentication checks if it claims to originate from your domain. If an email claiming to be from your domain has a DKIM signature, and no key is found, it will fail DKIM authentication. This is precisely the desired outcome, as it helps prevent spoofing and protects your domain's reputation. So, for domains that definitely won't send email, you can usually skip DKIM record creation. The DMARC record will handle the enforcement.
Implementing DMARC for maximum protection
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the overarching policy that ties SPF and DKIM together. It tells receiving mail servers what to do with emails that fail SPF or DKIM checks and provides a mechanism for domain owners to receive reports on email authentication failures. For domains that do not send email, a DMARC policy of p=reject is the gold standard.
When you set p=reject, you are instructing receiving mail servers to outright reject any email that fails DMARC authentication for your domain. This means if a spammer tries to send an email from your non-sending domain, and it fails the SPF check (because your SPF record has -all) and/or the DKIM check (because no valid key exists), it will be rejected. This provides the strongest defense against unauthorized use of your domain.
Even though your domain doesn't send email, you can still monitor DMARC reports. By adding a rua tag to your DMARC record, you can receive aggregate reports from various mailbox providers, showing you how many emails claiming to be from your domain are being sent and where they are failing authentication. This insight can be invaluable for identifying ongoing spoofing attempts. You can generate a free DMARC record easily. For more information, Microsoft's guide to DMARC validation explains the DMARC validation elements.
DMARC record for a non-sending domainDNS
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:reports@yourdomain.com"
No DMARC, SPF, or DKIM configured
Vulnerability: Your domain is completely exposed to email spoofing and phishing attacks.
Brand reputation: Spammers can freely send emails appearing from your domain, harming trust.
Recipient risk: Email recipients are more likely to fall for fraudulent messages.
DMARC with p=reject and SPF -all
Strong protection: Emails claiming to be from your domain that fail authentication are rejected.
Enhanced reputation: Signals to mailbox providers that you take email security seriously.
Reduced risk: Significantly lowers the chances of your domain being blocklisted (blacklisted).
Maintaining domain security and reputation
Beyond the technical configurations, understanding the practical implications of these settings is crucial. Proper setup of DMARC, SPF, and DKIM helps ensure that even your non-sending domains contribute positively to your overall online security posture. It's about proactive defense rather than reactive damage control. A good approach to DMARC is to always get to p=reject. You can read more about how to safely transition to quarantine or reject here.
Remember, the internet's email ecosystem relies on these authentication protocols to filter out spam and phishing. By failing to configure your non-sending domains, you inadvertently make it easier for attackers to succeed. It's a small investment of time for a significant return in security and brand protection.
For domains that will never send mail, like parked domains or domains used solely for web hosting, the setup is often simpler than for domains actively sending emails. You're aiming for a definitive 'no' to email traffic, which SPF and DMARC handle effectively. This also prevents your domain from contributing to the global spam problem, inadvertently or otherwise. By taking these steps, you're not just protecting yourself, but also contributing to a safer email environment for everyone.
Maintaining a clean and secure domain portfolio, even for those parts that don't send emails, is a hallmark of good domain management. It ensures that your online presence is not only functional but also resilient against evolving cyber threats.
Views from the trenches
Best practices
Always publish an SPF record with `v=spf1 -all` for domains that should not send email, explicitly denying authorization.
Implement a DMARC policy of `p=reject` for maximum protection against spoofing on non-sending domains.
Consider including a `rua` tag in your DMARC record to receive aggregate reports, even if no legitimate mail is sent, to monitor for spoofing attempts.
Regularly review your DNS records to ensure they are up to date and accurately reflect your domain's email sending status.
Secure all subdomains of non-sending domains with appropriate DNS records to prevent sub-domain spoofing.
Common pitfalls
Neglecting to publish any DNS records for non-sending domains, leaving them vulnerable to spoofing.
Using a DMARC policy of `p=none` for non-sending domains, which only monitors and does not enforce rejection.
Adding an SPF record with `~all` (softfail) instead of `-all` (hardfail), which is less effective for non-sending domains.
Attempting to configure DKIM records for non-sending domains, which is often unnecessary and can cause confusion.
Forgetting to update records after domain ownership changes or DNS provider migrations.
Expert tips
Think of your non-sending domains as digital 'no trespassing' signs for email. SPF and DMARC clearly communicate that.
A well-configured DMARC `p=reject` policy on a non-sending domain acts as a strong deterrent to phishers.
Even if you don't expect reports, setting up DMARC RUA can alert you to unexpected spoofing activity.
DNS records are like your domain's security instructions. Make sure they're clear, concise, and enforce your intent.
Consider using automated tools to monitor your DNS records and DMARC compliance across all your domains.
Marketer view
Marketer from Email Geeks says if you never plan to use a domain to send email, then there is no need for DMARC, SPF, or DKIM records. The implication is that if you don't send email, there's no need to pass DMARC checks.
2020-06-05 - Email Geeks
Expert view
Expert from Email Geeks says it is beneficial to notify the world that anything purporting to come from a non-sending domain is not legitimate. This proactive step helps prevent spoofing and unauthorized use of the domain.
2020-06-05 - Email Geeks
Final thoughts
Properly configuring DMARC, SPF, and DKIM for domains that do not send email is not just a best practice, but a necessity for robust email security and brand reputation. By implementing a strict SPF record like v=spf1 -all, opting not to publish DKIM records, and enforcing a DMARC p=reject policy, you create a powerful defense against email spoofing. This setup clearly signals to mailbox providers that any email purporting to be from these domains is unauthorized and should be discarded.
Taking these proactive steps protects your domain from being exploited by malicious actors, safeguards your brand's integrity, and prevents your non-sending domains from being inadvertently associated with spam or phishing campaigns. It is a simple yet effective way to secure a often-overlooked part of your digital footprint, contributing to a more secure and trustworthy email ecosystem.
